You draw a distinction between public and private, specifically:<p>&gt; IPFS probably isn&#x27;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.<p>This is actually a great example of where I <i>can&#x27;t</i> see the IPFS model working, because not everything is black-and-white private-or-not.<p>For Twitter, for example, you have private accounts - this doesn&#x27;t mean that nobody can see it, it just means that you need to have <i>permission</i> to see it. How do you implement an access control system that:<p>- Is mutable (ie. allowing new users to see your feed)<p>- Is private (ie. there is no public list of <i>who</i> can see your feed)<p>- Is revokable (ie. you can remove people&#x27;s access to your feed)<p>... without having to re-encrypt everything using a secret set of keypairs every time the ACL changes, which is an unreasonable burden on resources?<p>I understand that you build applications on a different kind of architecture, and I&#x27;m all for <i>usable</i> decentralized primitives, but there <i>have</i> to be explicit solutions for these kind of &#x27;business requirements&#x27; (whether commercial or not), for it to ever be able to &quot;take over&quot;.