I will have a look into these things later when I get around to it, but I just want to address a few things upfront:<p>&gt; you mention Tahoe-LAFS, yep!, we can (and will) build a cap system similar to it on top of raw ipfs objects (ideally actually collaborating with the excellent Tahoe-LAFS team directly).<p>The cap system that Tahoe-LAFS uses is great, <i>but</i> only serves a limited subset of usecases. It is not possible to revoke access, for example.<p>Depending on implementation it may be possible to accomplish this (to a degree) by having a separate mutable pointer for each person who has access to the data - and simply not updating their pointer to newer versions once their access has been revoked - but this still doesn&#x27;t cover the &quot;oops, accidentally gave them access, let&#x27;s hope they didn&#x27;t notice and revert it&quot; usecase.<p>(EDIT: It&#x27;s not even possible to delete files on demand in Tahoe-LAFS, at the moment.)<p>&gt; This looks a lot closer to the data models people use in apps today (think single page app models, {backbone, react, meteor, ...}. these are layered on top of APIs like REST, but can trivially layer over IPFS too)<p>That architecture has actually turned out to be flawed in quite a few ways - in many implementations, it has turned out to be <i>considerably</i> harder to build on top of them than on more &#x27;traditional&#x27; architectures. SPAs are common primarily due to hype, not because they are the superior technical solution.<p>They also come with some pretty serious (and in my view, unacceptable) trade-offs, like requiring JavaScript to be able to use it.