Thread - Nostr Hypermedia

We have considered three scenarios: The first scenario is hosting images and videos used in chat rooms. These need to be end-to-end encrypted and stored for about one or two weeks. Users typically access them only once within the chat room. No separate interface is needed—configuration can be done in the chat settings. The second scenario is hosting images and videos for microblog posts. Since they are meant to be viewed by followers, encryption is not necessary, and the files should be stored for a long time. No separate interface is needed—configuration can be done in the microblog client, similar to setting a relay. The third scenario is backing up important files. These must be end-to-end encrypted, stored for a long time, and require a dedicated interface to display all saved files. For the third scenarios where files need to be end-to-end encrypted, our idea is to perform the encryption on the client side before uploading. We hope to see a Mini App like this, where users can log in using their own key pair and optionally pay with their wallet.

↑ Parent

Replies (2)

Nuh 7 months ago

You are under selling the need for ordered key value store or a filesystem interface. Without this consistency of an ordered yet e2e encrypted lists, plenty of apps are simply impossible, unless you fake it using a mutable file and embed an sqlite file in there, however this will suck ass to maintain AND Blossom doesnt have mutable files at all. Think; how do you build every app in Google suite or Proton Drive apps without this ability? Or think instead; why do we have filesystems and BtreeMaps if we can build apps with random immutable files? Finally; you can't slap privacy on top ... it is the HARDEST part, someone has to build this once for everyone and servers have to be involved.. think of all the access control and key management and defense in depth where servers don't give encrypted files to random people even if they can't decrypt it, because eventually they might be able to... etc. My point is, Blossom won't cut it. If you insist on using it because the availability bias... fine, but maybe check Peergos to get an idea on what can be done.

1 replies ↓

Nuh 7 months ago

Addressing files by their hashes only serves popular content so people can share it trustlessly ... user storage on the other hand will be shared by no one.. it is only going to be read by the user and those who get links to these files... so what Blossom does doesn't achieve anything but make most apps harder to implement... even WebDav was better. Even if you manage to build an interface on top of this, it will be horrendous, because you will have to deal with garbage collection on the client side. Because only the client know which blocks no longer needed for the latest version of the state of the filesystem, Blossom itself doesn't have this information... and leaving garbage collection/storage reclamation to applications is not a good idea.