No, that’s not it. The hashing is about making the content addressable, which means that the *where* the data, the media, comes from, is non-important. Ok, that gives us the same thing relays give us on nostr, so what? The next piece of the puzzle is the pubkey, tying a blob’s hash to a pubkey allows you to easily retrieve the list of blossom servers that pubkey uses; so when you have a url from a pubkey pointing to server1 as the place to find file with hash1 When server1goes down/censors, you can ask nostr in the same way we use outbox model to find which is the new server for that same pubkey You now have a list of candidates servers that pubkey moved to and a hash; you can just ask for the hash to those servers and voila, maybe you’ll get your file. Since you also can talk about this blob by its hash you can use other tricks to find it or DVMs to go and do the searching for you in exchange for some sats. It really is extremely simple but it works and it’s super powerful.
Is it expected that Blossom servers scrape from other blossom servers for data redundancy?
no, it's not expected, but they can OR, for example, you could have a blossom server in your home that is backing up absolutely everything YOU publish; it doesn't need to do anything special, just listen from events from you and look for referenced blossom URLs. That's it. That's all it needs to do. Say one day your main server rugs you, you automatically have all your prior media fixed. Today we've been discussing the /mirror endpoint, which you can use to accomplish 👇 1. upload file1 to serverA 2. instruct serverB, serverC and serverD to fetch file1 from serverA and keep a copy this could all be done automatically, or not, from your client
To illustrate what this looks like in practice. Here is a demo of an article being rendered in Highlighter, the author used blossom to upload the image. The server went offline, hence the image was broken. “Was” being the key word, within a moment, the image is found using blossom and served from a different server. @note10h28g0x8s22xshtxfst3z7ak4zlhq8ynwke7s6s8ssx0k67g8s7s0engye
ah, i don’t think i was clear that it created a mapping from npub to the blob. that does help a lot, thanks for clarifying. fwiw, this discussion came up in private as i was working with a friend on exploring Highlighter’s long form blogging tool. looks like media is currently uploaded to nostr.build. is Blossom ready for a service like Highlighter to use or still need more development first?
No, it's ready for prime time; I'm working right now on replacing nostr.build with Blossom endpoints-only. It will default to Primal's blossom server but it will be easily configurable. In fact, this very screenshot was uploaded from Highlighter to the Satellite blossom instance, and if it were to go down, it would automagically heal. https://cdn.satellite.earth/eb65cf0b0b6a1ea90180a690661b62acd5429a7419d028bf29ab4174c080cd1d.png
Healing technology. 🌱 nostr:nevent1qqswcapdhcudvum8uf3v0g8k6gxwf5ur4lqtj7rqw970m88kcmqvsggpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgq3ql2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqxpqqqqqqzqatf3n
Not surprising. It's a property of organic things. As is blooming. #Bitcoin #nostr #Blossom 🌸 https://dergigi.com/2019/08/07/proof-of-life/
“Automagically” is the best word I’ve heard all year
Okay, let me get this straight. So this image is from a blossom server, but it is linked to directly from a webserver (cdn.satellite.com) So for this to automagically heal, you have to configure known blossom servers on your client so that it will identify missing images from a blossom server and redirect to other blossom servers in order to find the image?
I didn’t know it mapped to an npub either. That’s super cool.
It’s npubs all the way down lol… and that’s probably a good thing. I’ve heard @calle 👁️⚡👁️ noting about npubs to address cashu mints I was talking with someone recently about npubs to be website addresses and I think @PABLOF7z shared something like this today? and now we’re learning from @hzrd149 that Blossom addresses a piece of media with an npub where the underlying serving location can be re-mapped making the media serving more resilient maybe npubs are really about creating an abstraction/mapping layer when accessing any entity, be it person or service?
Yup. 100%. The addressability plus the layers of “how to find stuff related to me” that the protocol already does makes it like the universal join table for nostr data. I’ve been digging in on double ratchets and syncing big groups across devices and, wouldn’t you know, I think npubs are going to solve problems there.
yup; I made this meme like a year ago when I started to notice this https://cdn.satellite.earth/69e6be37f5431bfc57a8eae48931ea02a578593f1c4a52a472dba92ec944e87f.jpg
uncoupling a blob from a specific url, and making it locatable anywhere on the network is such a powerful idea
🤝 https://m.primal.net/IUqF.jpg
next youll make relays key addressable and add a dht, voila p2p
yes to making giving them a pubkey, I've been talking about for well over a year now hard no to adding a dht; dhts need not apply
whats the issue with dhts? a dht for relays would work very well as there is so few