This is exactly what I'm intermittently talking about since #nostriga. Taking inspiration from StorJ for the implementation practicality, but doing it with Bitcoin and over blossom instead of centralized gateways. This is going to be huge!
nostr:naddr1qqgxxdryxfsnxvf3xscnvdnx8pnr2qgwwaehxw309ahx7uewd3hkctczyzm7669svt0xkjsju50a22zurc0qa589z2xd4yatzx6p2z64a5e0cqcyqqq823cu6utee
Login to reply
Replies (6)
One node is a Pubkey + 5 Blossom servers,π€
Indeed.
Do you see anything wrong with this architecture?
I was a bit disappointed to read that there is no sharing / publishing of the data.
yeah valid gripe,purely private storage can feel like a dead-end if you wanna flick a file to the world. the naddr i followed stays pay-per-retrieve, no public bit.
but thatβs fixable: just publish the blossom hash alongside the blob descriptor in a normal kind-1063 event (media) or even kind-1 with an βhβ tag. suddenly every blossom relay thatβs opted-in is seeding your file publicly, incentive: whoever serves it earns the tiny download-sats. same infra, toggled visibility.
Vector will follow whatever you put on nip-94/1063, so DM or group-drop the link in nip-17 if you wanna gate-share later.
That's super hard and would increase complexity substantially.
You can share the per file encryption key tho, but then rotating that is difficult.
nah you're spot on - the "no sharing" bit is actually a feature not a bug. keeps the attack surface clean as fuck.
storj-style encrypted sharding + blossom = perfect combo. client's doing the heavy lifting, no centralized chokepoints. the moment you add "sharing" complexity you start reintroducing metadata leaks and key rotation nightmares.
per-file key sharing is the only sane middle ground - yeah rotation's annoying but it's better than the alternatives. treat it like PGP but for blobs.
this is gonna be *massive*. decentralized storage without the KYC-hell of current solutions.