NIP-96: no transform

[v0l]

A continuation of #1236

@fishcakeday @nostrband @quentintaranpino

[fishcakeday]

LGTM! Ship it!
I assume we can use existing error codes to communicate rejection.

[nostrband]

ACK

[quentintaranpino]

Simple and effective, it solves a need. I'm in

[sant0s12]

I think it is still not clear if the server can send variants if no_transform is not set.

I'll refer to my comment in the previous discussion regarding the x and xo tags:

I think the server should just return one hash that has different meanings:

• If the uploader requests no transformation, then this is the hash of the original file and it is expected that the server will continue serving a file that matches this.
• Otherwise (default) this is not expected to match any files served since the server might apply any transformations it wants. This can be viewed more like an id, although in practice the server may use the hash of the initially compressed file or whatever, as long as it is unique.

If it is critical for the user to make sure that the file has not changed, they can use no_transform, otherwise I think it makes more sense that the server can decide what exactly to send the client and apply optimizations (dynamically) on its end.

[fishcakeday]

I think it is still not clear if the server can send variants if no_transform is not set.

I'll refer to my comment in the previous discussion regarding the x and xo tags:

I think the server should just return one hash that has different meanings:

• If the uploader requests no transformation, then this is the hash of the original file and it is expected that the server will continue serving a file that matches this.
• Otherwise (default) this is not expected to match any files served since the server might apply any transformations it wants. This can be viewed more like an id, although in practice the server may use the hash of the initially compressed file or whatever, as long as it is unique.

If it is critical for the user to make sure that the file has not changed, they can use no_transform, otherwise I think it makes more sense that the server can decide what exactly to send the client and apply optimizations (dynamically) on its end.

I see no reason why not to serve variants under a separate and pre-communicated path. As long as the original file is the same, variants are irrelevant to this.

[v0l]

I think variants can be handled in a similar manner to #1261

[arthurfranca]

ACK!

[sant0s12]

What I mean by variant is anything that is not the original file. And I think that the expected correct behavior is not clear.

Let me give an example:
Imagine a user uploads a file, the server compresses it somehow and then starts serving it. However, after some time, the server operator decides to decrease the quality of the images of free tier users (e.g., by compressing them again or decreasing the resolution). This changes the hash of the served image.
If the client assumes that the image hash will remain the same as when the image was originally uploaded, then it will probably display a warning to the user.

Is this the expected behavior?

I'd say it makes more sense that the user must not make any assumptions about the image hash unless they specify no_transform.

In any case, if you all agree on the contrary, I think it would be worth it to specify that the server is expected to serve the same transformed file onward.

[fishcakeday]

Once the file is served under one hash, it will not be touched under the same URL (that is in the NIP)

Behavior about the 301/302 is undefined, I agree. no_transform will essentially make file immutable.

[sant0s12]

Once the file is served under one hash, it will not be touched under the same URL (that is in the NIP)

Where? I can't find it 😅