I've finished writing part 1 of "OcapPub: Towards networks of consent", which is to say the "Conceptual Overview" section https://gitlab.com/spritely/ocappub/blob/master/README.org
There's a lot there already, and we haven't even gotten to Part 2, the "How to Build It" section yet. I'll begin work on that tomorrow.
What's here already is more or less an explanation of *why* OcapPub is taking the particular direction it is taking, and why other approaches run into serious problems.
@doesntgolf I haven't covered that, but the answer is... no! You don't need an ACL for revocation (or for tracking abuse)! And here's how we can do it.
An ocap is an unforgeable reference right? (As in, if you don't know it, you don't have a way of faking it.)
So, what if we have the "real" object, and then what we actually hand the person is a "proxy" object that forwards messages? This proxy could attach information so we know "who's capability" is being used when they use it.
@doesntgolf Now, let's say we see that they're abusing our resource through that proxy. Here's the second part! Our proxy contains a flag that we can set, and then it *stops forwarding messages*! But we hold onto the capability to flip that bit... a "self-destruct button" if you will... and since they don't have that, we can disable it if necessary, that's our power.
So as you can see, we can get both accountability and revokeability!
Thanks @cjd ! Putting this on now.
@cwebber ahh, it's a brilliantly simple solution! I need to take some time to think about the implications of proxy objects, but I really love how simple that is. Thanks for explaining :-)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!