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 https://github.com/w3c/activitypub/issues/319. You seem to gloss over the backwards-compatibility issues though—have you put thought into how you would implement this?
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.
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?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!