add B0 NIP for Blossom interaction

[fiatjaf]

This describes a tiny subset of possible Blossom capabilities, but arguably the most important from the point of view of a most basic Nostr client.

Other Blossom-related functionalities should be added here later if necessary.

Readable: https://github.com/nostr-protocol/nips/blob/19f671e8777f739537a9b5017a46f67c6169956a/b0.md

[fiatjaf]

@hzrd149 @pablof7z @dergigi @mikedilger

[pablof7z]

ACK

[vitorpamplona]

This is dumb. Lots of image servers end with sha256 and are not blossom.

Just do a blossom://sha256?server=<baseUrl> instead.

[pablof7z]

This is dumb. Lots of image servers end with sha256 and are not blossom.

Just do a blossom://sha256?server=<baseUrl> instead.

That would require explicit blossom support on clients.

[vitorpamplona]

Yep. Force it.

[hzrd149]

Just do a blossom://sha256?server=<baseUrl> instead.

HTTP isn't broken and works very well for serving files. the only important part is to include sha256 so it can be found when the link breaks

[vitorpamplona]

I didn't say it was broken. It's just ambiguous. And because it works as is, no one will ever code this. If you force it, you might get some actual traction on decentralizing media.

[1l0]

related? hzrd149/blossom#31

[fiatjaf]

I have argued in the past that Blossom URLs should be a little more explicit than just including 64-char hex strings, and we could probably still do that, but not break HTTP. The genius of Blossom is that it works for everybody as it is and the other stuff can be added later.

In any case it's not a big deal, what if you try a Blossom server with a URL that looks like a hash but isn't? Doesn't matter, it will fail just like it will fail if the file had never been there. Also if a Nostr user has a list of Blossom servers and their URLs look like hashes then the odds of them being hashes is really high, so we're probably good.

In any case I think these discussions should probably be held on the Blossom repo or on the group at groups.hzrd149.com'0a3991, not here, because here I'm just documenting what is standard Blossom as of now.

[vitorpamplona]

In any case it's not a big deal, what if you try a Blossom server with a URL that looks like a hash but isn't? Doesn't matter, it will fail just like it will fail if the file had never been there.

It's not nothing. When servers go offline, lots of pictures and videos stop functioning at the same time and that triggers lots of pings to other servers to see if we can find the file. This can happen when the server is busy and runs a timeout, when individual pictures get deleted, when the user is offline from part of the web (not uncommon in phones), when firewalls/VPN have errors or block content, and when the server goes bust, of course. Trying different servers is not cost-free and when the switch works, the UX flickering is not that great.

If we had a better way to figure out which links are blossom's, we could manage this thing a whole lot better, including with pre-caching systems way before information gets to the screen so that when it loads, it already has the complete image preloaded. We could even reuse the cached image if a different server with the same picture was used previously.

The issue is that with blossom, the chance that the hash matches is high. For most of the other servers, the chance of a hash matching is remote. So, we can't really trust caching by random SHA-256 hashes by default because the images are generally different.

We already have to do so much to parse and display nostr: uris, which is an absolute requirement right now, that adding a blossom: doesn't really change anything. It's just a different URI for the required parser to go through.

[fiatjaf]

I see your point now and I agree with the things you said.

But here is a list of many small and big things that are important as arguments for keeping things as they are:

• backwards-compatibility with existing clients
• ease of implementation for new apps -- just being able to get something that works easily is a good thing, HTTP images are relatively easy for new developers, having to learn about Blossom might be a showstopper if the developer is not heavily invested in Nostr already
• ease of implementation for apps of smaller scope (not all apps will implement everything, for example it's ok for some apps to just turn a nostr:naddr1... into a clickable link and not create a full-blown embeddable widget, for example), parsing blossom:// then fetching the author's relays then trying to get the image is probably a very simple thing for Amethyst but that's because you are already doing so much more and you have all these helper functions in hand already, but piling more and more stuff like that into a smaller app can be daunting
• if we're doing blossom:// URLs inside Nostr then what happens when I want to share a blossom URL outside Nostr?, then I'll have to come up with a new paradigm in my head and become aware of this other way to share a URL and it will be confusing and now I'll start using that inside Nostr too so in the end Nostr clients will have to support both use cases?
• in 99.9% of the cases the HTTP URL will work -- given that in most cases people will be adding URLs to tweets which are meant to be read at the time they're published, not an year later
• the UX flickering is better than not having the image in the first place -- and very tolerable if you're browsing old stuff when you would otherwise expect to see just broken links (as is the case with all social media platforms already)
• with the current method I can easily upload my stuff manually to a Blossom server and copy-paste the URL into my client and everything works and I still have the option to migrate to a new server later -- with the proposed method the UX will be more complex on every side
• with the current method I can easily copy a URL from someone else and use it in my tweets, with the proposed method that will not work unless I also upload it to my Blossom server (doable, and I should do that in any case, but now it's mandatory and it's more hidden complexity)

Also, I think your points you mention could be addressed by just having something to make blossom HTTP URLs more identifiable, like a /blossom/ in the URL path, I don't know. Then you just have to parse URLs that have that and go straight into the Blossom servers if you want, skip the raw HTTP URL entirely.

[vitorpamplona]

if we're doing blossom:// URLs inside Nostr then what happens when I want to share a blossom URL outside Nostr?

Same exact problem for nostr: uris. Yet, we seem to be doing just fine when copy-pasting those.

in 99.9% of the cases the HTTP URL will work

Only in the early days. All the servers we use today will likely go out of business in time. Older posts will always have broken URLs. Browsing the past will be very annoying, with lots of missing data, even if your relays are awesome.

blossom://

I like blossom:// mostly because it allows apps to be created that handle Blossom files completely separate from Nostr. Browser-based links will get in the way of developing tools/apps to try to figure out where the file is. But I am open to any other scheme. I just think Blossom can be a very large ecosystem in itself. And it would be extremely beneficial to that ecosystem to not be based on domain names.

[staab]

What about my-server.com/<hash>.png?protocol=blossom&pubkey=<pubkey>? This would work with http, and be easily identifiable. Building the pubkey into the url would be nice too so that we don't have to assume the person who pasted the url actually hosts it.

[fiatjaf]

Yet, we seem to be doing just fine when copy-pasting those.

It's not totally fine, no, it's annoying and painful. I just don't see any other way.

Browsing the past will be very annoying, with lots of missing data, even if your relays are awesome.

Yes, but people will be more tolerant when browsing the past, that was my point.

I just think Blossom can be a very large ecosystem in itself. And it would be extremely beneficial to that ecosystem to not be based on domain names.

What about an opt-in solution that is just https://.blossom/<hash>. It will fail for all clients that don't know about Blossom, it will trigger the Blossom fallback flow for all clients that support it, but for all clients that implement the native 100% Blossom flow you want they can just skip the first HTTP step and jump straight into Blossom.

[fiatjaf]

Building the pubkey into the url would be nice too so that we don't have to assume the person who pasted the url actually hosts it.

Now we'll have to assume that the person who hosts it is the person whose pubkey is in the URL and won't check other Blossom servers from people who might also be hosting it: people who shared it, people who liked, people who interacted, reposted, quoted, or people who have published some special kind that signals they're rehosting that blob.

[staab]

The pubkey should probably be considered a hint. Which means multiple hints could be included, and other servers could be consulted depending on other heuristics.

[mikedilger]

You guys are rehashing the URI vs URL argument. URIs were to be addresses to data that are ideally location independent, and URLs have the location hard-coded which might break. Spoiler alert: the world went with URLs even though they break because it was simpler. And now the WWW has plenty of broken links and no mechanism of fallback.

I don't support a blossom://... URI because it is yet another thing that everybody has to code or fail to utilize, whereas an https:// URL is something everybody already has. Of course that means it is a Locator not an Indicator and so the link can break, which is the point of this PR.

The alternate solution of putting something in the URL path to signal that this is blossom, so that the SHA256 could be tried elsewhere (by loading the author's current blossom servers) seems reasonable to me.

Comparing against someone's current 10063 event to see if the server matches is probably a bad idea as they may have removed an old dead blossom server from their list already. I don't think anybody mentioned that idea, but it came to my mind.

[vitorpamplona]

I just find it inconsistent that we have chosen nostr: uris instead of http://njump.me/<bech32> with fallbacks to search other njump-like sites and here we are choosing http://.../sha256 instead of a blossom:// URI.

To me, there is absolutely no difference between them and we are arbitrarily choosing opposing directions.

[staab]

it's only because nostr is not built on http, so an http:// url is impossible

[hzrd149]

I just find it inconsistent that we have chosen nostr: uris instead of http://njump.me/ with fallbacks to search other njump-like sites and here we are choosing http://.../sha256 instead of a blossom:// URI.

I understand your point, but I think of this differently. there is no such thing as a "blossom URL" and there never will be. there are only URLs that happen to have the hash of the resource they are serving in the path

Blossom servers are required to serve blobs from https://server.com/<sha256> but that does not define a "blossom URL", only the requirements for how blossom servers are supposed to operate

So I don't think it makes sense to have a blossom:// URI because there is no such thing as the "blossom" protocol. Its only HTTP and Blossom defines how a server should be implemented in order to serve crypto-graphically verifiable data

[vitorpamplona]

Ok, then maybe we should have an nblob1 NIP-19 entity for nostr posts where we store a sha256 of a file and a list of server hints that the file can be read from as well as the author's hex to get any server updates. It's not a Blossom thing, it's a Nostr thing.

Referencing files with fixed domain names on Nostr never made any sense to me. It's like building an entire decentralized protocol that only works with custodian wallets. It's completely dumb.

Then instead of solving the problem, this PR has to use a fallback hack that doesn't even guarantee it is ONLY applied to blossom URLs, triggering a bunch of unintended side effects.

[fiatjaf]

Referencing files with fixed domain names on Nostr never made any sense to me. It's like building an entire decentralized protocol that only works with custodian wallets. It's completely dumb.

Relays are domain names. It's the thing that makes Nostr work. The more we go towards p2p the shittier things get.

[vitorpamplona]

Relays are domain names. It's the thing that makes Nostr work. The more we go towards p2p the shittier things get.

Yes, but they are only hints. The whole point is that people can move events to a new relay and things still work, even with all the wrong hints.

Blobs deserve the same treatment.

[fiatjaf]

I think this can be merged because it is kinda the standard, right?

Future nblobs or anything else can be shoved in later if we decide.