Wiki: Vision for a Fedi Specification

Move your thoughts 💭 Ideas
, ,
#22

I think there are two aspects:

  1. Moving discussions that are not about what belongs into a Fedi Specification away from this thread is good policy. So most topics concerning ActivityPub and Mastodon should be moved elsewhere. I said above that defining a protocol in terms of properties is problematic. I hold a similar opinion to defining a protocol based on other protocols or applications using said protocol.
  2. On Mastodon controlling ActivityPub: I think one of the main reasons why I am here, is that ActivityPub creates a bad power dynamic. A specification should allow people to read it, and then decide if something is right or wrong. ActivityPub does not pass this bar. Instead one asks “Will it federate with Mastodon?” However, the details of the situation are unimportant. What matters is that we want to develop a new approach that allows one to avoid these type of situations.

Here new approach does not mean new new, but rather use what has worked in the past in similar situations and avoid what hasn’t worked for ActivityPub. See useful information above.

2 Likes
DX Requirement content format
#23

:robot:  Howdy folks… a gentle reminder to wiki summarize what’s important.

:robot:   Oh… and please describe your level of commitment to contributing.

1 Like
#24

:information_source: This vision needs a champion.

Another point to address in a vision is how to map social connections. As

describes ActivityPub has modeled the Publisher/Subscriber pattern with Follow. From a technical point of view Follow and actors forwarding activities should be enough. However, from an UX/SX perspective it’s awful.

Me subscribing to the account of my favorite farmers market merchant doesn’t make me their follower. Same for work colleagues or a fitness club.

2 Likes
#25

Quick insight drop-off to add to the wiki later: @erlend in Muni Town chatroom:

Thinking about ‘protocol as intent’.

Where I think there’s a need split between functionality that is added in upper layers of the protocol & tech stack, and for the protocol itself the Robustness NFR a key requirement to provide a solid enough base to also ‘design with intent’ and deliver said functionality. The functional must be able to stand upon the technical.

I just gave a long reaction to Christine Webber that argues for a more holistic approach to capture the intent of technology and ultimately our own day-to-day efforts in better ways. At the end of that thread I pointed to a proposal I posted today in relation to this effort.

See: https://social.coop/@smallcircles/113528415124633236

Please check out…

:rainbow:  Proposal: Start a fellowship to explore the Social Web

1 Like
#26

:information_source: This issue needs a champion. I’m mostly writing it up, because I think that it is important and I know how. However, I don’t personally have some of these issues, e.g. I’ve never looked at a single like count.

Vision / Concept

The federated / decentralized network can reach eventual consistency.

Functional requirements

  • [ ] After a week, if a conversation is shown on a server, it is complete, i.e. contains all replies, likes, shares, …

Non-functional requirements

  • [ ] Is cheap on cost for server admins
  • [ ] Respects privacy

For background:

and

#27

Christine Webber: “These are the missing parts of ActivityPub”

" Alright you’ve heard enough critiques of Bluesky for a bit and I SAID I was gonna critique the fediverse and I am a WOMAN OF MY WORD. So let’s get into it! "

:point_right:  Consider Christine’s thread MUST READ, preferably from the top, scrutinising Bluesky.
:point_right:  https://social.coop/@cwebber/113528750380675735
:point_right:  How decentralized is Bluesky really? -- Dustycloud Brainstorms

Correctiverse™ … what is fedi done right?

Cristine: Here is your recipe for making the “Correct Fediverse IMO ™”:

  • Integrate ocaps, which is possible because actor model + ocaps compose
  • Content addressed storage!
  • Decentralized identity (notice the y, I did not say DIDs) on top of ~mutable CAS storage
  • Petname system UX
  • Better anti-spam / anti-harassment using OCapPub ideas
  • Improved privacy with E2EE (“encrypted p2p” even a better goal)

Below I’ll highlight just a few bullet points from the thread …

  • Spritely aims for a for a socially collaborative revolution, is yet first focuses on a technical revolution.
  • It is too hard to build systems. We need stronger foundations (for ocaps, yet applies generally).
    • “It’s too hard to build massively, securely collaborative tools right now.” (that are full-ocaps).
  • “Conway’s Law flows in 2 directions”, technical system reflects social structure, and vice versa.
    • “The tech flows from goals. So too does the social structure flow from the tech.”
    • Important thought experiment: “In which ways are tech and social systems bidirectional?”
  • At minimum fedi installed base should adopt content addressed storage + decentralized identity.
    • Adoption of object capabilities is likely too big a step for most current implementers.
  • Support content addressing (see Christine’s demo), “content can live anywhere”.
  • Content can survive server shutdown (based on content addressing support).
  • OCapPub critiques anti-abuse features of AP as inadequate. Lead to “nation state’ification”.
  • OCaps to fill giant holes in AP specs wrt auth and authz. Proposed multiple times (here for Bluesky).
    • OCap adoption must be bottom-up. Real challenges backporting right designs to existing systems.
    • The ocap vision is critical to Christine’s bigger vision (which involves the PoC of the Fantasary).
    • Intent is, but time will tell, to see if we can retrofit Spritely onto ActivityPub.
  • Avoid getting accidental ACL’s that lead to confused deputies and ambient authority trouble.
    • More detail: Christine offered to advise Solid project on ACL dangers, but was ignored.
  • An actually decentralized network will have directed messaging, face challenges handling replies.
1 Like