Nostr Web Client

NIP96 clearly defines (and by the way, with the consensus of many people) the basics for any media server, what is the point of differentiation with blossom? I am seriously asking 😅😀 nostr:note1n22fhh0vyj35ajm4vn6c64uyzkejwfdf3vfhvl9f4pgv9l7d828sg0aupt

hzrd149 1y ago

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

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

server admins who can't make subdomains or rewrites are not very competent

but why does blossom not allow a path prefix?

hzrd149 1y ago

Simplicity, once you allow customizable paths then you need a document outlining it.

It also has the benefit that non-technical users can easily understand and manipulate the URL

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

and anyway like i say it's really not difficult to do that with http anyhow

Josua Schmid 1y ago

That‘s the kind of complexity-tear-down I like 👌

Laeserin 1y ago

Hey, can you give me a Blossom link that I can add to my Nostr spec registry?

Then we could list it right after the NIP-96 entry.

I was thinking of adding topic labels or something, anyway, but it would already help if we sort a bit by topic.

hzrd149 1y ago

The blossom spec lives here https://github.com/hzrd149/blossom

Also added a few wiki pages for it. but I need to add a lot more info

nostr:naddr1qvzqqqrcvgpzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qqrkymr0wdek7mgy65kuf

nostr:naddr1qvzqqqrcvgpzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qq9xk6twvsarzvpsxcestdhm6h

Shawn 1y ago

Why does the path need a “.ext”? The sha256 should be enough, right? Why confuse things with whether it’s a jpg, pdf, gif, etc as part of the path?

hzrd149 1y ago

Servers should serve the blob with and without the .ext

The .ext is just optional because its useful for clients and users to get an idea what type the blob is without downloading it first. a lot of web apps look for `.png` or `.jpg` on URLs before they show them as images

alex 1y ago

Is there some kind of metadata about the blob in blossom? If not, is it even possible as an extension on the protocol?

It is very useful for clients to understand the data before downloading the actual data. One good example would be image resolution so apps can prepare the layout properly before image is loaded. This helps with performance and cleaner ux.

hzrd149 1y ago

Servers can offer additional metadata on media or any other file type but none of the metadata is synced or stored on other servers.

You could store some metadata in k:1063 events or NIP-94 tags though

Shawn 1y ago

It would be awesome if Blossom would provide that info in the response header. That way apps could make an http request for just the header without downloading the whole thing.

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!

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