Decentralized encrypted storage is a very interesting direction. One question: how do you plan to handle forward secrecy? Right now the nsec acts as both identity and the root encryption capability. If that key ever leaks, every historical blob becomes readable. No blast radius control. If Garland is going to function as long term storage, it needs a way to break that link. Example: - per epoch encryption keys derived from a ratchet - or a delegated encryption key that rotates independently of identity - or a forward secure chain where old keys become unrecoverable Any of these would limit historical exposure while keeping the Blossom architecture. You just need a ratcheting key schedule or sealed envelope scheme tied into the manifest updates.