Oddbean

not really a lot of difference, nip-98 is superior, scales better, can do more -- but it's nice to have more than one way of doing things we are all still learning -- most of this will get replaced in next generations, in any case.

one of the things i like about blossom is that it standardises CDN on nostr, while staying very simply. it end’s up being very much like how we interact with relays. in the future, i can also see how it would help us keep media in notes tamper-resistant.

This use case was always possible, and has already been standardized at the ietf in RFC 6920 for a decade. Blossom doesnt really standarize it, imho. It proposes an api which pollutes the namespace, and wont fly in certain deployment scenarios. But it is a system that works, and could perhaps be future-proofed with the use of reverse proxies. I wouldnt get too wedded to the system tho. There is sufficient technical debt that further iterations will be needed, imho.

Just because I'm curious: @hzrd149, is there any reason you didn't go with NIP-98 for the authorization part in #Blossom?

Well, seems like NIP-98 lacks some features needed for something like Blossom? Blossom wants to be server agnostic so it doesn't want to include the URL of the server it's uploading to in the auth event. Also, why does NIP-98 use the "created_at" field instead of the NIP-40 expiry tag for limiting the valdiity of the auth event? Would be nice if the two could be formed into one to keep things simple.

This is nostr! No features are lacked. You can do what you want. As I said in the issue, the URL can be relaxed for the URL agnostic use case, i wanted it SHOULD instead of must, for that reason. Wilful violation is fine. All events have created_at. I'm actually fine with 2 ways of doing things. Blossom having its own NIP-98 gives it the flexibiltiy it needs to move fast, without potentially breaking other things. It's good, nostr working as expected 😉