hpr-knowledge-base/hpr_transcripts/hpr3200.txt

Episode: 3200
Title: HPR3200: Better Social Media 17 - OcapPub
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3200/hpr3200.mp3
Transcribed: 2025-10-24 18:42:15

---

This is Hacker Public Radio Episode 3,200 for Friday 6 November 2020. Today's show is entitled
Better Social Media 17 Ocap Pub
and is part of the series Social Media. It is hosted by Ahuka
and is about 19 minutes long
and carries a clean flag. The summary is
how using object capabilities within activity pub could solve some problems
with social media.
This episode of HBR is brought to you by An Honesthost.com.
Get 15% discount on all shared hosting with the offer code
HBR15, that's HBR15.
Better web hosting that's Honest and Fair at An Honesthost.com
.
.
.
.
.
Hello, this is Ahuka, welcoming you to Hacker Public Radio
and another exciting episode. And this time I'm going to add something
to the social media area that I've been working on.
And I did a number of shows about different aspects of this.
I want to talk about something today called Ocap Pub
which is a bit of a mouthful. It's a combination of things.
It stands for object capabilities
and it's a proposed standard to integrate that into activity pub
which is the protocol for having federated media talk to each other.
And we've talked a lot about that.
So just give a little brief reminder here about activity pub.
And it's a quote from Dietrich Ayala of Mozilla.
Saying social websites first got us talking and sharing with our friends online
then turned into echo chamber content silos
and finally emerged in their mature state as surveillance capitalist juggernauts
powered by the effluent of our daily lives online.
The tale isn't just wagging the dog, it's strangling it.
However, there just might be a way forward that puts users back in the driver's seat.
A new set of specifications for decentralizing social activity on the web.
And that's what he said about activity pub.
So activity pub is a W3C standard
and I've got lots of links to these things in the show notes.
So a W3C standard, W3C is the worldwide web committee
and that sets a standard for how various social networks can communicate with each other.
Unlike the surveillance capitalist sites like Twitter and Facebook, it is open.
And because it is used on federated networks like mastodon, it is more secure.
The Twitter hack of July 2020, and that's when the accounts of famous people
appeared to offer links to Bitcoin scams.
Well, that hack could not happen on mastodon precisely because no one server can give you access to all of the major accounts.
That's what federated means. That's why decentralizing is important.
And without getting into all the technical details, federated social networks operate similarly to email.
As an example, I have my own domain for which I have email.
It's called swillnick.com.
And my address, my email address, is on that domain.
But I'm not limited to sending or receiving email only within my domain, which is good because I'm the only one here.
I can send anyone a message as long as I know their username and their email provider.
Put those together and you have an email address.
Username at signprovider.com.
We all know how that works.
But just a reminder that when we talk about federated networks, it's really nothing more than this.
Now, federated media, enabled by activity pub, operates the same way.
I have a username and I am on a server.
And if you know my username and which server I am on, you can send me a message.
So there's nothing radically strange about federated social networks.
But with activity pub, you can actually send messages between different networks.
That would be like posting in Twitter and having it go to Facebook automatically.
This is something most users of social media want, but which the owners of surveillance capitalist media frustrate because it does not fit their business model.
Twitter and Facebook are looking to make money at every opportunity, which federated media is not.
Now, that's not to say that there are not costs.
There are costs involved and the admin of the Mastodon server I'm on has been added to my Patreon monthly donation list.
I pay a buck a month, 12 bucks a year to help support my server admin.
I don't think it has to take huge amounts of money, but you have to stop up.
And as I always say, support free software, support free media, support the people that support you.
Now, activity pub follows something that is called the actor model, which says that everything is an actor.
In a way, it's kind of analogous to some degree with the idea from object-oriented programming that everything is an object.
Now, the actor model, according to Wikipedia, an actor is a computational entity that in response to a message it receives can concurrently send a finite number of messages to other actors, create a finite number of new actors, and designate the behavior to be used for the next message it receives.
Again, link in the show notes.
One thing you can get from this is that email also follows the actor model.
Again, nothing terribly radical about this. And the result has been nice.
My Mastodon feed is, and I'm going to quote Sarah Jung like Twitter without all the Nazis.
I'm connected to people I like and the conversation is civil.
And in fact, many of the people that I connect to on Mastodon are other HPR contributors.
You might recognize people like Claudio, Miranda, and Taj Sarah, and Ken Fallon, and Dave Morris, and so on.
Some of the others are people that I've gotten to know over the years through things like Ohio, Linux Fest, and different Penguicon, and stuff like that.
So, you know, it's a nice place.
So, activity pub and federated media are awesome in many ways, but everything can be improved.
And this is where Ocap pub comes in.
Now, there are things that can go wrong. If Mastodon is Twitter without all the Nazis, why is that?
There are mechanisms in place to help with that.
You can block someone from your feed, or even ask your cis admin to block them, or even block the entire server they come from.
But these are not ideal.
And the main reason it hasn't been such a problem is that Mastodon doesn't have as many users as Twitter.
Now, I've noted something on another federated platform, Diaspora, which we've also talked about here on HPR.
There's kind of a sign of things to come. I'm seeing the trolls show up, and people are posting the names of users they recommend to be added to your block list.
Now, the problem with this approach is that it privileges the sender over the receiver.
We're saying bad actors have the right to send us messages we don't want, and that is our problem to figure out how to stop them.
Every day, I have to go through my spam folder to make sure nothing important got sent there by mistake before I delete the messages.
And just how many times did something important get flagged by mistake? It does happen.
And while spam is merely an annoyance, harassment can cause trauma.
Do we really want more gamer gates?
The internet lynch mobs are already too powerful and people have died because of it.
You know, there are too many stories of people being bullied, you know, kids that are bullied and then commit suicide.
Block lists in the end do not work because trolls and Nazis just create new accounts for the laws, and you end up spending ever increasing amounts of time maintaining the block list.
It's a game of whack a mold that you cannot win.
So, maybe you want to go from a block list to an allow list.
That's the ticket, except who gets to be allowed?
The virtue of federation, the whole point of federation is to encourage a thousand flowers to bloom.
We want more people to set up their own servers. We want people to join with like-minded people.
But who will put all those servers on an allow list? Just maintaining that is daunting.
Ah, well, we'll just put a few top servers on the allow list.
Great. We have now replicated the centralized system we were trying to get away from.
So, how does OCAP Pub come into this?
Now, the first thing I have to say is this is a proposed standard.
It is proposed by Chris Weber, who is also the prime developer and maintainer of activity Pub.
And one of the people that you probably should follow if you ever get onto federated media.
He was also our tech guest of honor this year for PenguinCon.
Now, unfortunately, PenguinCon, as with most conventions, we had to cancel the in-person.
But we were able to do a number of things online to make up for it.
And Chris very graciously participated in a number of online sessions.
It's a great guy.
So, his proposal is to let the receiver set the rules for what is wanted.
I think it gets the balance right when it comes to free speech.
Since it assumes that free speech also means the freedom to filter.
Now, let me give you an example.
In England, they have a wonderful institution in Hyde Park called the Speakers Corner,
which permits pretty wide open speaking by almost everyone.
Not to say absolutely wide open.
If you are in decent or inciting riots or whatever, the police will probably lock you up.
But other than that, it's say whatever you want to say.
No one is ever forced to go there and listen.
Sometimes people stop and listen just because they want to be entertained by the craziness.
But the point is, you get to make that choice.
If you don't want to listen to that, you don't have to.
Well, how do we do this online?
OcapPub does this by building networks of consent using object capabilities.
First, what do we mean by networks of consent?
We're talking about establishing trust between parties.
Now, this is something we do all the time in our personal lives.
As an example, my wife and I have a good friend who has a key to our house.
We have a key to her house.
I just worked out great.
One time she was out of town and my wife was able to get a plumber in to fix a leaky pipe.
And that's exactly why we exchanged keys.
We each trust that the other won't do anything we don't approve of with those keys.
And of course, you don't give a key to your house to just anyone.
You have to build a relationship of trust first, and this is an example of a very high level of trust.
Now, there's a somewhat lower level of trust in something like joining a neighborhood watch program and so on down the line.
I have the absolute highest level of trust for my wife.
Only slightly less for other family than close friends and so on.
As Ringo famously said, I don't ask for much. I only want trust.
And that is essential to living in a society.
Access control lists, and this is probably something I'll do a show on because it's unpacking it is fascinating.
Access control lists is in contrast a fundamentally broken system.
And what we mean by that, access control lists is the unix thing that says,
if you want to have access to a resource, you have to have a username and a password and then we assign rights to that username.
That's an access control list.
And that's fundamentally broken because it allows us for such things as click-jacking, cross-site, request forgery attacks, and things like that.
So one aspect of the fundamental problem with access control lists is that they conflate two different things, authentication of identity, and authorization to perform a task.
Object capabilities come into it when we consider those house keys we exchanged.
Put simply, the key is an object which has the capability of opening a door.
A door lock opens for anyone who has the appropriate key.
That is inherent in the concept of lock and key.
And we don't use an access control list or ask for login credentials for anyone using a key.
Obviously, the fact that a key can do this makes it powerful, and it means we need to be careful about who we give them to.
But we have all managed to do this pretty well.
In my home life, for instance, I don't ask my wife to use a login and a password, let alone two-factor authentication, before she grabs the key to my car and uses it to drive.
I gave her a key when I bought the car. I trusted her to use it wisely.
The other day, I realized my car was not in the driveway and knew she had taken it.
And the reason is, my car has a bike rack on the back, and she wanted to go and visit her friend to do bike riding.
So that meant if I needed to go anywhere, I would use my copy of the key to her car.
And in fact, I did that just a little while later when she called and said, hey, meet me in the park. We'll go for a walk together.
Now, this example illustrates the point that there are different levels of trust, and we should take that into account in handing out capabilities to people.
And this brings us to something called the principle of least privilege.
I've also heard it referred to as the principle of least authority, which says that any user object, etc., should only have access to just the information and resources that are necessary to its legitimate purpose.
Now, access control lists do not follow this principle without a lot of workarounds at best.
OKPUB proposes to fix this by using the added capabilities of code to do several useful things that are more difficult in the real world.
Now, the first one is delegation. My wife could lend the key to my car to someone else.
And trusting her to only do that in a way that makes sense to both of us.
With ACLs, you would have to give someone else your login, so in a sense they are pretending to be you.
In fact, they are you as far as the system knows.
Atenuation.
In the state of Michigan in the United States, and this is pretty common here, we have a system for teenagers who are learning to drive, which is called a learners permit.
Which lets them operate a motor vehicle legally, but only under strict limits.
You know, generally it means you have to have a license driver in the car with you.
You're not allowed to be out after a certain hour, things like that.
Imagine if you could give a teenager a key that only works until 9 p.m. and won't let them drive too fast.
Now, in the world of code, we can design objects to have only the capabilities that they need to have, which is the principle of least privilege.
A revocation. Since these objects are code, we can build in switches to allow revocation.
So, if junior comes home late or gets into an accident or whatever, you take the key away, or perhaps more accurately, you flip a switch that makes it no longer operable.
And then finally, accountability.
Through logging, we can see who does what with the capabilities we have handed out.
If you find the scratch on the car door, junior can't say I didn't do it because logging will have determined when it happened and who was driving.
Now, with all of the tools we can create this way, we can begin to fix the problems which still exist in federated social media.
We could probably do much of the above using sufficiently complicated sets of rules at ACLs.
But to my mind, that is just layering fragile craft onto a fundamentally broken system.
What is broken is the idea that capabilities should be tied to a person, because then identity theft means you are one hack away from losing everything.
Devising objects with capabilities and respecting the principle of least privilege is a much better way to go.
And so, this is Huka for Hacker Public Radio signing off and reminding you as always to support free software.
Bye-bye!
You've been listening to Hacker Public Radio at HackerPublicRadio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contribute link to find out how easy it really is.
Hacker Public Radio was founded by the digital dog pound and the infonomicum computer club and is part of the binary revolution at binwreff.com.
If you have comments on today's show, please email the host directly, leave a comment on the website or record a follow-up episode yourself.
Unless otherwise stated, today's show is released on the creative comments, attribution, share a life, 3.0 license.