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:
ForgeFed (Source Code Forges)
LitePub (Security & Simplicity)
The ones mentioned in this forum are:
FedEvents (Event Management)
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:
- 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.
- 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
- No guarantee of interoperability (is this really a guarantee with a centralized authority?)