Oddbean new post about login | logout interesting, but unless I’m missing a crucial detail this doesn’t sound new. is this an http server with a well known api for uploading content? that uses the content hash for later retrieval and deduplication? I love the idea but have seen this exact solution proposed many times. I even implemented a proposed spec for this almost a year ago. is there something new or is this just novel because it came out of sec-01?
nostr:note1xpzr5jnjw7d46ntcnjtk8wexsxlefvuyq2kf6x2wahvf739wy52qytwz7j
I was not aware of this spec but it looks similar to what I've written for blossom in that it uses the sha256 for the id of the file. however I think it has some issues 1. Its only focused on images and videos. if we want to solve the storage problem it needs to be generic 2. It relies on the "/.well-known/nostr.json" document for servers to describe themselves. this makes servers not interchangeable when it comes to retrieving files 3. It only focuses on uploading and retrieving the files. I think its also necessary for users to be able to list and delete the files they have on servers
is your spec/protocol documented somewhere I can read it? I think the issues you highlighted from the old spec are trivial… but that’s neither here nor there.
nostr:naddr1qqxkymr0wdek7mfdv3exjan9qgszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgrqsqqqa28e4v8zy
nothing happens when I click that link in damus 🤷
It's long form content, not sure how Damus handles that. https://njump.me/naddr1qqxkymr0wdek7mfdv3exjan9qgszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgrqsqqqa28e4v8zy
The naddr works for me on Damus. Maybe your relay is missing it @ben ?
hmm the single relay my damus connects to just fans out there REQs to 5 or 6 big public relays. maybe something about the naddr link doesn’t work 🤔
I know. Sometimes long form content exceeds default size limitations (on strfry for example) so the note won’t be ingested. Not sure if that’s the case here.
spec is documented here https://github.com/hzrd149/blossom
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
There is no deduplication.