If replication and distributed retrieval can be solved I'll be excited. Same problem nostr has in general. I think it's doable, but it hasn't been done.
does blossom do replication or distributed retrieval? I clicked through the link but couldn’t find any kind of spec.
That can be done out of band, doesn’t need to be on the spec; much like negentropy is useful but doesn’t need to be done via nostr nor speced within nostr. @hzrd149 talked about doing something similar to NIP-65 for blossom as well as the idea of creating a DVM market for “I want to find file with hash x and willing to pay y sats” which are two very useful building blocks of this system
so this is just another http media server?
Who remembers NIP-95? Blobs all the way! :)
I remember and still think blobs should be stored *not* in json encoded events. still think @nothenry ‘s original proposal from a year ago is fine. curious how blossom is different.
Now that some clients are putting base64 images directly inside the .content of kind 1s to go around the chinese firewall, NIP-95 is easy.
Which client?
I don't know. I just see the event with the massive base64 in it. It's becoming quite common.
I was just testing this yesterday, hoping to find that clients would render a data URL embedded in kind1 content. None of the clients I tested did, though. Storing file hashes and content in events makes sense to me. If there are clients that support it I’d love to see what they’ve implemented. I was thinking of experimenting with it this week(end).
👀
@PABLOF7z how does it compare/contrast to this: https://github.com/michaelhall923/nostr-media-spec?tab=readme-ov-file#uploading-media