You draw a distinction between public and private, specifically: > IPFS probably isn't a good fit for private data, but public apps like a decentralized Twitte

You draw a distinction between public and private, specifically: > IPFS probably isn't a good fit for private data, but public apps like a decentralized Twitter will probably use it for all of their data. Encrypting private data and storing it with IPFS will sometimes make sense. This is actually a great example of where I can't see the IPFS model working, because not everything is black-and-white private-or-not. For Twitter, for example, you have private accounts - this doesn't mean that nobody can see it, it just means that you need to have permission to see it. How do you implement an access control system that: - Is mutable (ie. allowing new users to see your feed) - Is private (ie. there is no public list of who can see your feed) - Is revokable (ie. you can remove people's access to your feed) ... without having to re-encrypt everything using a secret set of keypairs every time the ACL changes, which is an unreasonable burden on resources? I understand that you build applications on a different kind of architecture, and I'm all for usable decentralized primitives, but there have to be explicit solutions for these kind of 'business requirements' (whether commercial or not), for it to ever be able to "take over".