I've finished writing part 1 of "OcapPub: Towards networks of consent", which is to say the "Conceptual Overview" section gitlab.com/spritely/ocappub/bl

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.

@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.

(1/2)

@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!

(2/2)

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!