Button Button

Object Capabilities

We're hearing a lot about OCaps recently, mostly from @kaniini and @cwebber, and it's confusing because it doesn't always sound as if they are talking about the same thing. We're suspicious of technological solutions to social problems, and rightly so. I'm usually better at muddying the water than I am at making it clear, but maybe this'll be helpful anyways

First, the flip side of many social problems on the internet is that they are caused by technology. Sometimes there's a way out of the boxes that we build ourselves that actually makes things less worse. This is one of those rare situations. Let's try to make it less confusing so that we can get past our otherwise healthy suspicions

Chris Lemmer-Webber and kaniini often do mean different things when they talk about object capabilities, and that's not easy. OCaps can apply at any interface. Chris may be talking in general terms or he might be talking about a specific layer of interfaces depending on the context. On the other hand, kaniini almost always means that a server is going to use a mechanism called capability URLs to tell another ActivityPub server what it can do with an Object - Object Capabilities. If the details are overwhelming, you can think of one as more general and the other as having a narrower focus

How does this keep the fasc out of our shit?

OCaps are a more efficient way to find out whether someone should be allowed to interact with a post than what we're using now. In fact, the mechanisms currently used can't be applied to a number of situations because it would make it too easy for the fasc to keep us from our own, umm, stuff

When we want to keep things quiet currently and we get a request, we find out who's asking. Then we ask them to prove it by doing the secret handshake. Then we check whether they're allowed the thing. Then maybe we give it to them. Or not. Meanwhile, they're blocking the door. The whole process is interminable in computer time and there's always the risk that someone will come to the door to do an improvised Abbott and Costello sketch instead of actually doing business

To make things easier, we usually skip the intro and hand out the info to whoever comes to the door. As kaniini explains in a recent blog, information flows 2 hops in this situation. If you don't want to be a danger to others, block the fascie instances. If you don't want to be a danger to your own users, also block those who won't block the fasc. Some take it further - those who won't block the fasc are, themselves, a hazard. They're not wrong, but each needs to address the needs of their own communities. The real problem is that our negligence has created motivation to interfere with other communities' freedom of association

The OCaps implementation that was called LICE described a situation like two windows at a drive in. Each inbox in federation gets a unique, single purpose window. If you go to that window, that cashier knows what you want and that you can have it. It doesn't matter who you are, because they don't have to look it up

They still don't give you the thing, but they do give you a thing to say you've been to the window, which is good at the second window to do the thing you want

Okay. That bit's a little dodgy. Maybe that's been fixed in later (unpublished) versions. I wasn't told where that window could be found. Even that rough idea represents sufficient improvement over the status quo that access can be more consistently restricted to intentional contacts, if implemented

Implementation details

Over a network, Fediverse OCaps usually means capability URLs. Best practice is to limit them in time, usage, and ability. In the example above, it's one time use, limited time, and only gets a token that represents a single permission, like replying to a specific post

Other approaches could do the same thing, but using a capability URL instead of asymmetric cryptography is a huge computational savings. There's a trade-off between network and computational load to negotiate. Cryptography places more burden on the content host, which is why URLs are a better fit for a threat model that includes denial of service

The other OCaps

There are still objects in object oriented programming and object patterns in other types of languages that have interfaces at the functional level. Still fascinating, but important in the broader area of user safety for all software, not specific to the Fediverse