BUD-02: Should the URL in the blob descriptor contain the extension?

[laanwj]

While working on a blossom implementation I wondered the following: according to BUD-02:

url A public facing url this blob can retrieved from

To me this implies that it can be just any URL. However, Nostr clients (at least nostrudel) will paste this URL into the message after uploading, and then tend to use the extension to determine whether to show it as image or plain link.

So if the blossom server simply returns https://media.server/<sha256> then clients, if they don't add the extension themselves), will see it as a link instead of an inline image.

Returning https://media.server/<sha256>.jpg (depending on image's MIME type) works, but means that the server needs to do a MIME type to extension mapping.

I think it would make sense to specify this explicitly.

[hzrd149]

There is a line in BUD-01 requiring the GET /<sha256> endpoint to accept an optional extension https://github.com/hzrd149/blossom/blob/master/buds/01.md#get-sha256---get-blob

But it would be good to add a line to BUD-02 to make it clear servers can add an extension to the URL

[hzrd149]

created PR #26 let me know if that helps

[laanwj]

That's definitely an improvement, but wouldn't it set clearer expectations to resolve it either way? Either the server is required to add the extension, or shouldn't, and the onus is on the client to do this (if it needs an extension).

(E.g. from a user experience point of view it's currently best to add the extension server side, to make sure users can paste their images into nostr posts and it "just works", but the client could ostensibly handle this too)

[Sjors]

Is there any argument against making the extension mandatory? A client can't learn the mime type without downloading it first. And the mime type isn't part of the file itself, so if you obtain a file through some other means (like a torrent) you don't learn it.

My suggestion would be that case a server MAY serve requests without an extension, but they MUST serve request with an extention. And in bud-2 the return url MUST contain the extension.

Additionally a server MAY verify that the extension matches the filetype and reject the upload if it doesn't.

[0xtrr]

My suggestion would be that case a server MAY serve requests without an extension, but they MUST serve request with an extention.

I think I agree with you @Sjors but I'm not sure I understood this sentence. Are you saying that the server MAY accept requests without filetype at the end but MUST respond back with a filetype at the end?

[Sjors]

I'm not sure. I think it makes more sense if clients that upload MUST add an extension. Whereas clients that download SHOULD add an extension.

But then either my "server MAY serve requests without an extension" above needs to be MUST, or clients that download MUST add an extension.

In other words, mime types are just a nice extra on top of file extensions.

[laanwj]

FWIW, we're now adding extensions to the returned URL on upload in cherry-server (0xtrr/cherry-server#32). At least in nostrudel this is a large usability improvement.