Extensions To ActivityPub


#1

I think it is great that there’s a lot of interest in extending the base ActivityPub protocol into something more. It’s a philosophy I’ve mostly kept quiet about for the past year, and I wanted to take the time to share my knowledge:

ValueFlows (Economic)
ForgeFed (Source Code Forges)
LitePub (Security & Simplicity)
MoodleNet (Education)

The ones mentioned in this forum are:
FedEvents (Event Management)
Groups, possibly?
Maps, possibly?

The core problem is this: How do we centralize the knowledge of how to form a group to develop a specification, how to invite comments and conduct revisions of a specification, and how to publish a specification?

I think this forum is a great start. If people wanted to get formal, a centralized standards body could be developed that is empowered to manage these extensions and “bless” those that behave nicely. This would be repeating history, and suffers from all the trappings that centralized powers have:

  • Slow
  • High barrier to entry
  • Infighting politics

The main benefit a centralized authority has is in their “blessing” of extensions. But having a centralized authority doesn’t stop people from becoming disillusioned with the authority and developing an “unblessed” spec anyway. This is already primed to happen as right now not all the people working on the above extensions are represented in a single, central location. I doubt it would happen either, as at least one of the extension groups above is OK with rubbing elbows the wrong way. Since this is no longer a benefit there’s no real need to have a centralized authority on extensions.

So we are looking for a solution that has a centralization of knowledge but a decentralization of power.

Enter the Fediverse.

It’s already out there, we’re using it now as a centralized web of knowledge. However, authority is decentralized to each node.

I would like to seriously consider and get feedback on the idea of extending ActivityPub to contain the data for ActivityPub specifications.

Each instance is their own authority but only for the specifications they own. Centralized authorities have the problem that a spin-off “rogue” group’s default mindset is one of divisiveness, whereas decentralized self-forming authorities go in with the default mindset of interoperability and cooperation. Federation in this case means each instance could have a complete listing of all specifications, even those not owned.

Pros:

  • Low barrier to entry
  • Fast iteration and feedback
  • Interested specification co-authors to self-organize
  • Allows others to readily and exhaustively discover work-in-progress or completed specifications
  • Technical and non-technical folks have a very low barrier to communicate with specification authors
  • ???

Cons:

  • No guarantee of interoperability (is this really a guarantee with a centralized authority?)
  • ???

Would like feedback on these points, as thus far I have received only two pieces of feedback: from Dennis Schubert and from Alex Schroeder.


#2

I like the idea of there being a common place to facilitate discussions and capturing knowledge about these instance (or type) level extension specifications but not that there needs to be a centralized decision making authority that decides for everyone what will and will not be in a particular extension. It would be good if through a common discussion space we don’t end up with a dozen different extensions that do the exact same thing. Besides market dynamics is there a mechanism to limit such a fragmentation? If not do we care? With the market-driven method above a likely artifact is that the 1-3 largest projects will end up dominating the decision process. Is that artifact a problem? I think that answer depends on how much the various projects and app spaces decide to play nice. Even in a highly dysfunctional scenario where there is ultimately fragmentation (like three different specs for video sharing fediverse projects) it’s still good to have a central place to go to to discuss things, discover documentation for implementations, and discover who supports which spec and to what degree.

Having an easy central portal into data that’s coming from fediverse instances could be an interesting concept in terms of ensuring that the system is self documenting intrinsically so the information doesn’t go stale. Humans are bad at keeping stuff like that accurate and current, especially if a project is fast moving. A way for that to be a self publishing and harvested information would be really good.

I think I’m describing a lot of the same stuff you are stating but I’m raising some concerns that are coming up as I read this over and over again. Some of them may not be fully formed but I’m going to continue to crunch on the idea.


#3

Cited at https://www.loomio.org/d/WVfZM3UA/requirements-for-a-protocol-for-agent-centric-p2p-economic-networks/3