Sharded, encrypted storage between friends over Yggdrasil
peter_retief
26 points
9 comments
October 07, 2026
Related Discussions
Found 5 related stories in 81.0ms across 8,795 title embeddings via pgvector HNSW
- Neki is sharded Postgres by PlanetScale handfuloflight · 101 pts · September 10, 2026 · 48% similar
- Neki – Sharded Postgres simon_weber · 223 pts · September 10, 2026 · 47% similar
- Bookshelf – Self-hosted eBook library that runs on object storage arbayi · 72 pts · August 24, 2026 · 45% similar
- Show HN: Jotbus – a shared encrypted scratchpad for coding agents shake-n-fries · 25 pts · October 06, 2026 · 43% similar
- Show HN: Flashpaper – Self-destructing secret sharing with no database minpym · 25 pts · July 28, 2026 · 42% similar
Discussion Highlights (3 comments)
phr0k
Very interesting concept. This has also already been implemented in Tahoe LAFS (www.tahoe-lafs.org) but for some reason it was never really adapted for something that scales beyond local networks. I always thought that this would be an awesome idea since a lot of people already operate their own NAS, oftentimes with spare disk space that could be used as intended by this project, but don't want to pay additionally for some cloud provider for a decentralised backup.
soltanov
How do you prevent storage exhaustion attacks if a "friend" decides to dump encrypted garbage on your peer node?
myself248
> only lets the original writer delete a shard. That makes sense on the very surface, but eventually someone's going to lose their config, and all their orphaned storage is just occupied forever in the rest of the group. I'm pondering an "anti-challenge" primitive, whereby storing nodes can ask the original writer to confirm that it still has the stub file. (Because if that's lost, the data can't be decrypted anyway, there's no point to still saving it.) And if that fails for X months in a row, sorry, time to go. Or maybe raise it for manual review so the node operator can check in with the others before pushing the "reclaim storage" button.