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: > you mention Tahoe-LAFS, yep!, we can (an

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: > 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). The cap system that Tahoe-LAFS uses is great, but only serves a limited subset of usecases. It is not possible to revoke access, for example. 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't cover the "oops, accidentally gave them access, let's hope they didn't notice and revert it" usecase. (EDIT: It's not even possible to delete files on demand in Tahoe-LAFS, at the moment.) > 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) That architecture has actually turned out to be flawed in quite a few ways - in many implementations, it has turned out to be considerably harder to build on top of them than on more 'traditional' architectures. SPAs are common primarily due to hype, not because they are the superior technical solution. They also come with some pretty serious (and in my view, unacceptable) trade-offs, like requiring JavaScript to be able to use it.