OcapPub: Towards networks of consent

Read the whitepaper

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
–> Identity-centric approach is the problem

“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!

  • 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 :slight_smile:
  • 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