Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 1
Generated: 03:01:54
This could actually work. Some ideas were already discussed since SEC01 but this is the first time we have a comprehensive concept. 👏 1. I like the idea of only having commits on NOSTR and putting the metadata on blossom. The versioning we get through the commits would even allow to build a "timemachine" like backup solution. 2. The storage requirements seem to be pretty hefty. Let me know if I understood this correctly: Let's take 400 files, 2MB each: - 800MB (3091 chunks) + erasure coding (167%) = 1333MB (5152 chunks). Then we need to add 400 inodes (265KB padded) = 100MB So we have 1433MB in total (5552 chunks) that we upload to 5 servers, resulting in storage of 7165 MB. This might still be a good tradeoff for the privacy and decentralization gained, but needs to be considered in storage costs and upload times. 3. It's important that cleanup and deletion work well. In case of lost keys it would be good to be able to clean off all orphaned blobs from blossom servers. Expiration or storage limits based on payments might also help.
2025-12-07 17:16:00 from 1 relay(s) 1 replies ↓
Login to reply

Replies (1)

1. Yes, as long as old blobs and old inodes are still there, changes can be rolled back, and conflicts can be merged gracefully. 2. Yes, storage will be big, and it will be larger if we don't do erasure coding. The original idea was for super important small files, like wallet descriptors or password managers, not for your entire picture gallery. 3. Yes and that's tricky, with this design outside observers can't tell that two blobs belong to the same user. 402 fixes this.
2025-12-07 18:38:37 from 1 relay(s) ↑ Parent Reply