This is a draft of what I'll hopefully be submitting to Rebooting Web of Trust. If anyone would like to take a look, constructive feedback welcome:

@emacsen Hey, thanks for putting this all down on paper! some thoughts:

- I don't understand what ocap inboxes achieves over the current ability of moderators and users to block individual actors. how does this meaningfully improve spam-fighting abilities?

- You mention two methods for "Closing the Relay Hole", which both seem very similar to the discussion on You seem to gloss over the backwards-compatibility issues though—have you put thought into how you would implement this?


@nightpool @emacsen I share this confusion with ocap inboxes.

It seems like anyone can request a new preferred inbox from me at any time, and then if they do so and abuse it, I can stop looking at messages sent to that inbox (like a burner phone number). But then the attacker can just request another inbox from me, right? I don't know ahead of time which stranger to grant/deny an inbox to; if I did, spam and harassment wouldn't be an issue.

@nightpool @emacsen
burner phone numbers are useful because phones often have shitty blocking/filtering features and because we can't identify who is calling us because spoofing is so easy, and so handing out a unique burner number is a way to handle identification. But it seems like ActivityPub (and to some extent, email, through DKIM/SPF) *can* identify the sender of a message, and so I can block someone who sends me an unwanted message. But why use burner inboxes if I can client-side filter?

@npd @nightpool Let me rephrase the question slightly, "Why would I whitelist someone?"

Perhaps you'd do so because your default policy requires paying a nickle to message you. Perhaps because you want to be sure their messages get to you and aren't accidentally filtered into a spam folder, etc.

@npd @nightpool The second part of your question is "If I can use ACLs, why do I need OCAP?"

Two reasons. Firstly, because ACLs are hard to maintain. They're complex to use, complex to set up, complex to maintain computationally. You can get further with OCAP with less complexity.

Second reason is that OCAP allows for transferability. If I trust you to get ahold of me, I might also trust you to be responsible enough to give someone else my direct line. That's simply not possible with ACLs.

@emacsen I do like the transferability that capability URLs have, like Flickr's guest passes. Even if you don't have an account, or I didn't list you specifically but my friend trusts you, they can hand along a special URL which lets you read/see something. There's some extra UI for tracking/revoking those URLs, but it's not terribly burdensome. I haven't seen capability URLs used for write access as often.

Maybe it just doesn't seem to me that most of the problems with spam/harassment are people I know or friends-of-a-friend getting blocked. Is whitelisting of people I already follow/interact with a difficult challenge that I just haven't experienced?

@npd @nightpool I didn't have any vocabulary specified for requesting inboxes, only for offering them, so let me present an analogy:

You can look me up in the phone book and get my public number. That's the one that rings my secretary who screens my calls. He is a prickly fellow who doesn't like to bother me with crap.

But if I talk to someone, I can offer them a direct line to me- but those direct lines are (in your parlance) burner phones.

@emacsen @nightpool yeah, it's a different usage/analogy than burner phone numbers, as those are specifically given to people you *don't* trust, whereas you're talking about giving out capability URLs to people you do already trust.

At first glance, that seems less usable to me. Rather than recording in my client "I trust Person X" (whitelist), I give Person X a special URL, tell them to use it rather than my well-known name and make them promise not to accidentally make it public.

@npd @nightpool One of the things I think is missing in this discussion is that the UI I imagine and the wire protocol are very different.

A checkbox next to someone that says "trust them" or something is what I imagine would happen to send them preferredInboxes. The rest would happen under the hood.

And your client could have a button "Introduce" that would do the other part too.

A regular user wouldn't need to know the OCAP theory and all that jazz.

Sign in to participate in the conversation

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