Love people solving their own problems. If I understand it correctly this has wider implications. This could (if more widely implemented) drasticallyreduce 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...
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.
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)
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?
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.
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
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.
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).
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 🤔
I am right at the point in my super secret broken project where I want to enable users to upload images with their nostr posts. I was thinking of reducing their image file size before posting chunks of base64 text to the relay (that's the easy part) but I'm not sure how to make these images on nostr notes visible. Is this just an HTML thing? I have no idea how to make uploaded images visible in nostr clients.
57009already part of a NIP (draft)?