Good for you, but that is not what I am talking about, encrypting blobs is easy even on client side and a dumb server, but that is too far from an e2e encrypted filesystem where key management, access control and granting and revoking access is neatly packaged in an SDK. That is what I am talking about and it is the necessary (and sufficient) feature to build any cloud application where the user come with their own storage... I know that because every Google/Proton Drive provider immediately starts offering stuff like Docs and Sheets etc. Because they can. Now you can use blobs on Blossom to make up a Cryptree like Peergos, but Blossom is not smart enough to help you with access control (beyond encryption, which is imprtant), and not smart enough to handle the difficult key sharing story, and most importantly it is not smart enough to know what nodes in that tree needs to be deleted to reclaim storage. If you don't feel the need for an e2e2 key value store or filesystem... then you are not building the apps that do, my point was if we are going to build an open storage protocol, might as well build what is necessary and sufficient for any app that is analogous to native apps but with cloud storage instead of local storage, instead of building Blossom then realising it is not good enough later. As usual, I invite you and others to look at Peergos or just imagine what you would build if every user had a sovereign version of Proton Drive with open API.