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