Ah, thank you. I am not aware of any true spec forks in existence right now, nor plans to create them. and I agree with @eprodrom that they are confusing and generally undesirable. However, there is an enormous flexibility in interpreting the current specs and making implementations that aren’t really (or are really not) interoperable. That is a huge issue to tackle within the boundaries of current specs, and people are having many discussions and explorations on how to do so.
Some fabulous work I am aware of is FeatherPub by @hrefna, which - I must explicitly add - is NOT a fork, but an exploration of many of the implications and complexities for implementers that aren’t immediately obvious from the specification text, and offering a generalized solution that fits a large chunk of current fedi communications. See the draft docs for more info, Developing FeatherPub and FeatherPub Data Model. And I recommend following @hrefna@hachiderm.io to learn about rationale for the choices made and to give feedback.
And also @stevebate is doing similar explorations, very interested in true Linked Data supporting implementations and making those easier for other devs. Steve explored a ActivityPub Minimum Core as a foundation for writing interoperable AS/AP apps. I believe that such a core - which is an artifact that accompanies the full W3C spec - together with good guidance on writing extensions would come a long way to seeing a heterogenous Fediverse come about. Heterogenous meaning going well beyond Microblogging-shaped interop and having many different app types and services as building blocks of our social fabric. There was much discussion on this idea, see also: Initiative: ActivityPub "Step On Board" Integration Guide
Linked Data comes with its own issues wrt complexity, ecosystem support and uptake/adoption. In that light another discussion that took place was whether - without breaking backward/forward-compat - we might emphasize the JSON-first interpretation of the spec going forwards and position the Linked Data support as something extra for those devs who want to go the extra mile. This might allow maturing the LD trajectory separately, until it may become the default again in the future, and not turn off JSON-first devs who don’t see merit, or “don’t dig” this approach at all. See: ActivityPub: A Linked Data spec or JSON spec with Linked Data profile?
Further work to look at is by @helge on Bovine and personal codeberg account, where you’ll find a lot of small experiments (also see Steve’s Github account for this). Both @helge and @j12t received funding by NLnet independently to work on test suites, which is something direly needed in the ecosystem. @stevebate also did some good work here.
There’s much other cool work going on. I maintain 3 fediverse-related curated lists at Delightful Club and hope that in 2024 we’ll relaunch the ActivityPub Rocks Developer Portal with a large directory of other places to check out on the Grassroots Fediverse.
Lastly my recommendation on people who want to fork the specs:
- Strongly discourage them, and encourage to explore within the spec’s flexibilities. That’ll help general interop most of all.
- If they really want to fork, then a true fork it shall be. It is NOT part of this Standards Process proposed in this thread and on SocialCG mailing list.