@cwebber this (like all of your writing) is really, really great!
This question is maybe a bit boring (and from the outline it looks like maybe you'll cover it in part 2? so feel free to not answer or direct me elsewhere), but -
in a distributed ocap system, doesn't revoking caps require an ... ACL? (or in this case, a non-acl (blacklist)), to keep track of which caps have been given out that are no longer to be recognized as legit?
@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!