Nostr Web Client

The core difference between blossom and NIP-96 is the focus on re-uploading files

If we want censorship resistant media then we need to be able to re-uploaded the files to other servers. similar to now nostr events get spread around the network

NIP-96 could support re-uploading files but it isn't currently part of the nip

There is also the difference that NIP-96 has a "/.well-known/nostr/nip96.json" file and customizable endpoints. In my view this is not a feature and makes it much more difficult to work with servers since clients must first fetch a map of the endpoints before they can talk to the server.

Blossom however requires blobs be served from the root of the domain ( example.com/.ext ) while this isn't very friendly to server admins it makes things very simple and easy to understand.

Also searching for a missing blob is a simple as replacing the domain. something a user could easily do ( and understand ) in the browser address bar

There are more smaller differences but in my view these are the major ones

Quentin 1y ago

Hello, sorry I couldn't respond to you yesterday. First of all, thank you for answering my questions!

Re-uploads are fully supported in NIP-96. In fact, I implemented this in Coracle also relying on NIP-94. It was ultimately discarded, but it is 100% possible.

As for serving blobs at the root, I don't see the point. It is true that it is easier for a human to read, but this shouldn't force someone to reimplement a standard. I see it as pointless.

In any case, I will study Blossom in depth. I'm sure there is much to learn from it, but I think your efforts would be much better focused on helping with NIP-96 instead of reinventing the wheel.

This is my humble opinion, and I hope to open a good debate with this.

Nice to meet you, by the way!

Reply to this note

Please Login to reply.

Discussion

hzrd149 1y ago

I figured re-uploading could be added to NIP-96 but that's not its focus. If someone were to create another server that implements NIP-96 chances are it wouldn't have the ability to re-upload. since its not a requirement in the nip.

Blossom on the other hand requires servers to support re-uploading (uploads without modifications) and media optimization can be an optional endpoint

The requirement for re-uploading blobs is critical if we want media to be censorship resistent-ish and available on multiple servers. This is also why it has the requirement for serving the blob at the root path. this allows users and clients to easily ask an unknown server for a blob without having to get a "map" of the endpoints

I decided not to put my efforts towards NIP-96 because I think its more complicated than it needs to be and it only focuses on uploading. where as my focus with blossom is on downloading and distribution

Thanks for your interest and I'm happy to answer any questions you might have

Quentin 1y ago

Look at the PR I proposed for nip96 some time ago. It was not accepted but I think it is in line with what you are looking for with blossom.

https://github.com/nostr-protocol/nips/pull/1097

hzrd149 1y ago

Whats the purpose of adding the pubkey to the URL when in most cases its available from the kind 1 note the URL was posted in?

Also its possible for multiple pubkeys to upload the same file, although this could easily be fixed by making each pubkey work in the URL

However the biggest missing piece here is the ability to re-upload your (or someone else's) files without modification. censorship resistance isn't going to work if you have to ask the original server first before you migrate