Magical stuff. Professor @supertestnet at it again.
Love people solving their own problems. If I understand it correctly this has wider implications. This could (if more widely implemented) drastically reduce the amount of file storage needed for images and potentially video. And speed-up page load times everywhere implemented. Any 'downsides' you've encountered besides the dependencies and required script? What happens in the event one chunk/note is not retrievable? Guess I will have to test the links below to find out...
reply
If I understand it correctly this has wider implications. This could (if more widely implemented) drastically reduce the amount of file storage needed for images and potentially video. And speed-up page load times everywhere implemented
I don't think so because it doesn't reduce the file size, which is a big bottleneck in download speed. In fact, it increases the file size, first by encoding it in base64 (which is already inefficient) and then serving that inside of a json object delivered by a nostr relay. The json object is essentially "packaging" which is discarded and just increases the file size, and nostr relays are not known for being particularly fast by web standards.
The main advantage of this is not faster downloads (they are slower) or reduced file sizes (they are bigger) but simply permissionlessness. Or closer to that, anyway. Any relay can simply block this data, so it's not fully permissionless, but nostr relays are also easier to self host than many alternative servers.
reply
So the opposite of what I said.
Thanks for the thorough explanation.
reply
isn't nostr.build doing the same?
reply
No, they are a traditional image hosting platform. They store images on an Amazon web server and they require users to obtain an api key to do so:
nostr.build provides a free API to publically facing nostr or bitcoin projects that offer their service for free. Please contact either nostr.build or fishcake if interested in using the API source
Nostr Image Host does not require any api key and the images are stored directly on nostr relays (though those are also usually hosted on some sort of Amazon web server so that's probably where your images are ending up anyways)
reply
Obviously, this is a forever hosting solution for devs only.
  • Do you see any other possibility to have a normie using something similar? for example:
  • if a nostr-client implement this little library, could it allow the user to upload any image from the Ui so that any other user using that client (or any other nostr-client that has implemented the library) could visualize that same image?
  • Could it be extended to video and other files? or it work only for images?
reply
Do you see any other possibility to have a normie using something similar?
Yes, I think it can be integrated into apps in a normie friendly way
if a nostr-client implement this little library, could it allow the user to upload any image from the Ui so that any other user using that client (or any other nostr-client that has implemented the library) could visualize that same image?
Yes
Could it be extended to video and other files? or it work only for images?
Yes but the smaller the file, the better. It takes several seconds to upload even small files, due to my efforts to not hit popular relay rate limits.
reply
This could replace my https://dropshare.app/ license (which I use to share public stuff) in combination with my own personal relay.
reply
if you host your own relay what is stopping you from hosting images on it?
reply
Nothing? If I understand you correctly or I'm not clear enough what I mean...? Uploading files (with events) which are signed with my own keys sound like a good use-case (for Nostr). But that's also where NIP-95 is aimed at (mentioned by @dtonon): https://github.com/nostr-protocol/nips/pull/345/files
reply
like your server could serve your jpeg files directly, over https. Instead of as base64 chunks over a websocket.
If your use case is just to sign your jpegs, this is a very convoluted way to go about doing it.
reply
100 sats \ 1 reply \ @dtonon 8 Jan
I have mixed feelings about this. From a obvious point of view it feels absolutely bad spamming relays with fat notes, but if the relay is my one, and I'm thinking about the Gossip model here, it could make absolutely sense to have a unique source of truth for notes and their assets, that uses a unique protocol. Images are an important chunk within an information piece, so I would not give them to a generic third part.
A client could also offer its users a relay/web server/CDN layer to improve the images reachability and the download performances.
There is a proposed NIP-95 that is quite similar: https://github.com/nostr-protocol/nips/pull/345
reply
From a obvious point of view it feels absolutely bad spamming relays with fat notes, but if the relay is my one, and I'm thinking about the Gossip model here, it could make absolutely sense
If I was running a nostr relay, I would consider it spam and I would block it, unless I uploaded it to my own relay, or charged some money for it. Anyone who runs a nostr relay and wants to do something like that can put a filter on kind number 57009, which is the kind I am using for this.
To me, that's the beauty of nostr: it's not up to me. Every nostr relay gets to pick and choose what they think is spam and/or what they want to charge for. Nostr puts the relay operator in control of their own relay. And this app abides by that by specifying the relay to use directly in the image id. That way whoever is using it can connect to a relay that you know has that data (or at least had it at one point).
reply
What of if the one of the relay that takes the small chunk of image goes offline when you want to turn the nostr image id is into image
reply
then it won't work
reply
reply
A good problem solving approach here
reply
Nostscriptions have joined the chat 🤣😂
reply
I would be very stocked to see Nostr clients support for downloading vids and pics over BitTorrent, or a similar protocol but where seeders are paid in satoshis 😃
This incentivizes those who have storage and bandwidth capacity but makes it cheap on mobile and capped data plans 🤔
reply
thanks, I hate it
reply
Is event kind 57009 already part of a NIP (draft)?
Just to be clear, only relays supporting this event kind can handle the events you broadcast with the client you've made right?
reply
Is event kind 57009 already part of a NIP (draft)?
No
Just to be clear, only relays supporting this event kind can handle the events you broadcast with the client you've made right?
Afaik, all relays support it. It's within the range 0 to 65,535, which is the standard range for nostr kinds, so it should be supported by all relays
reply
Thx for the clarification.
Any plans for adding event signing with your keys (optional)?
reply
No but you can certainly modify the code to add that if you want it
For simplicity I wanted a no login experience, so it generates random keys
reply
inscriptions on nostr ftw ✌
reply
deleted by author
reply