so this is just another http media server?
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.
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr 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
Discussion
Who remembers NIP-95? Blobs all the way! :)
I remember and still think blobs should be stored *not* in json encoded events. still think nostr:npub1xv6axulxcx6mce5mfvfzpsy89r4gee3zuknulm45cqqpmyw7680q5pxea6 ‘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).
👀
Some emoji images?
You have a typo, but yes, all men are into them big time!
Not me, I’m a newbie. What was in NIP-95?
#nostrdev
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft how does it compare/contrast to this:
https://github.com/michaelhall923/nostr-media-spec?tab=readme-ov-file#uploading-media
Seems similar. I really like some of the stuff in that one, particularly how the filename can be anything.