OcapPub: Towards networks of consent
ActivityPub Conference Unconf Session
find a read.only backup of the #OcapPub etherpad here :
[[ Notes starting 14:14 ]]
Adding friction:
-
maybe spam-assasin bayesian stuff
-
some secretary that’s forwarding the message
-
maybe attach two stamps
-
Make VERY explicit when given permission
-
example: “disabling comments for a post”
Q: Whats the main problem ?
A: Harrasment panic at mastodon devs:
blacklist, whitelist, whackamole, … it’s soo cheap to generate users, sockpuppet accounts
is becamejust as easy to spawn servers as it is to spawn users
NETWORK DEFEDERATES VERY FAST
–> Identity-centric approach is the problem
OCAP:
“Associating with identity it came from”
First interaction is high friction, then it turns into a low friction, based on giving out OCAP.
“SOUL”(?) Abstraction:
- forward to a more powerful object
SharedInbox is awful!
History:
- mastodon needed bulk send messages for scaling
- single message to server instead of to all users of server individually
- mistake: the receiving server is deciding who to forward it to,which BREAKs the actor model
- that’s where we need OCAP
“Too much detail in this discussion”…
-
OCAP in Mastodon/Pleroma basically means “abandon shared inbox”
-
OCAP is NOT a new standard it’s a new methodolgy
-
the hybrid systems are vulnerable in composition and they only improve it one level deep
-
polaris et al subdivide the authority one level, with OCAP, one mechanism takes you all the way
-
Distinction between multi-box and shared-inbox
-
OCAP is very very new to many people here (like learned about its existence TODAY)
-
currently compatible with existing infrastructure
-
Limits of OCAP?
- Can boosting be limited?
- Answer: yes and no
-
Problems with OCAP:
- they expose very clearly the problems of existing systems
- webfinger is dead
- ocap makes delegation easy
-
“why we want this” --> if we go OCAP, we can reduce the power of the server
-
what are the alternatives?
-
Adrian: real use case “healthcare” where this one can be applied directly
Wrap up messages and take aways:
- we need a way to continue this discussion
- users need to be able to understand it without having to understanding the ocap model first
- users ask “where is the extra security”
- concepts are easier to explain with an implementation
- show how easy it is with code
- seems like there is agreement on the problem
- ocapub seems like a terrible name
- we need guided demonstrations
- what do we get ontop of the friction of inbox case
See also
“ActivityPub: past, present, future” - Keynote by Christopher Lemmer Webber