The ap-next developer guide was removed from the https://activitypub.rocks website: https://github.com/swicg/activitypub.rocks/issues/63 (by the father of the Fediverse, no less).

The reason:

It's a fork outside the SocialCG.

This is utter nonsense. The guide refers to the original ActivityPub specification and even to SocialCG reports covering Webfinger and HTTP signatures. The other ap-next project is NomadPub - a collection of FEPs that significantly expand the capabilities of the protocol but don't diverge from the original spec.

However, since dissenting opinions about the present and the future of ActivityPub are now openly censored, a fork may indeed be necessary.

@silverpill it does seem weird they would use that justification to remove the link. thought at first they might be consolidating for W3C-only resources, but there are non-W3C guides under the `Documentation` section (which is where I would guess the `ap-next` guide would also fit).

outside of clarifying underspecified pieces of the protocol, and highlighting some useful FEPs, how is the `ap-next` guide a "fork"?

@elle This guide is just a summary of what I have learned while working on my ActivityPub project.

@silverpill @elle Yes, I had a read of the ap-next guide and don't see anything controversial in it!

You've just documented the current ways the AP is being used in the real world.

@rimu @elle I think the real reason is the association with another thing I am working on: nomadic identity. Some people don't like it, although it is not clear why. It is an optional protocol extension, and similar features in ATProto protocol don't cause any controversy.

@silverpill @rimu @elle

I agree that ap-next is not a fork, and might have stayed on that website. That said I don't think there's deeper politics to this removal, just that the links on the site are rather arbitrary and in need of good curation. E.g. fedify is nice to mention, but also just but one such project where there are multiple.

The entire online presence of SWICG/SocialCG including the AP.rocks website are a mess that almost seems designed to discourage ecosystem participants.

It saddens me as 3 years ago, when AP.rocks was still considered to be part of SocialHub, I had a whole initiative prepared to once and for all create a great developer portal at this domain name.

https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-from-standards-movement-to-grassroots-fedi/3577

In particular that top-level aggregator site would need to serve as an entry point to drill down into the entire grassroots ecosystem, help people find their way around..

https://socialhub.activitypub.rocks/t/ideating-organization-structure-for-the-grassroots-fediverse-wiki/3037

The SWICG took over that initiative without consultation, and then let it languish.

@silverpill @rimu @elle

As for authority. I think at this point there truly are no authoritative bodies driving the fediverse.

In the 3-stage bottom-up standardization process I discussed at the time at SocialHub, the level of authority was highest at the W3C, lowest at individual FOSS projects, with the FEP process inbetween as a place where good practices and protocol mechanisms bubble up from the ecosystem as good candidates for further standardization.

This process in reality doesn't exist. The connections aren't there. The SWICG operates alone, the FEP does too, and so do all the various independent developers when they invent new things.

In that setup I'd say the SWICG has the same level of authority as the FEP Process does, or any other focal point for collab between fedi devs (e.g. code forges, podcasts). Just another party at the grassroots level figuring out best practices.

https://socialhub.activitypub.rocks/t/3-stage-standards-process-guaranteeing-an-open-and-decentralized-ecosystem/3602/40?u=aschrijver

@smallcircles I probably already said that - I don't like the idea of 3-stage process. This proposal was accepted and now reflects how SocialWG operates in practice:

https://swicg.github.io/charters/stage-process

According to the document, FEPs are at the same level as blog posts. Even a successful and widely implemented FEP needs a "champion" who will sign CLA and will present the FEP to the community group, which will bikeshed it to death. Even if it passes the initial filter of the community group, the document still needs to be reviewed by the working group, which is invite-only.

This is a ridiculous amount of red tape.

Compare this to the promise of the FEP process: you publish a FEP -> you convince other developers -> it becomes a de-facto standard.

@rimu @elle

@silverpill @rimu @elle

Having looked in more detail at the #SWICG document. That's not the 3-stage process I advocated for at the time, and I agree with you: It will not work. Such top-down formal ceremony just does not fit a grassroots ecosystem.

Generally speaking I don't think #W3C as a standardization body is up to the task of being a good host for the ActivityPub specification. It is a) not organized for our environment, and b) only takes care of the technical aspects. Our social media landscape has a huge social component, and this is wholly underrepresented in our app-centric fediverse, where people are merely "users" and #FOSS culture is the only driving force.

Today I think SWICG should focus on the 'Protocol implementer' stakeholder: How can they offer compliant #ActivityPub protocol implementations.

Then #FEP can focus on the 'Solution developer', relieved from the plumbing: What interoperable designs do they use to serve the needs of participants on the social network.

@silverpill @rimu @elle

I wrote a comment in the open issue on the 3-stage process, in the SWICG charters repo..

https://github.com/swicg/charters/issues/33#issuecomment-5470092604

#ActivityPub #SocialWeb #fediverse

@smallcircles @rimu @elle

Today I think SWICG should focus on the 'Protocol implementer' stakeholder: How can they offer compliant #ActivityPub protocol implementations.

Do you mean they should develop testing tools?

@silverpill @rimu @elle

Not per se. But a full-blown compliance test suite to come along with the protocol specifications would still be a great thing to have.

@smallcircles @rimu @elle It won't be very useful because the specs are too vague and incomplete, you can have a perfectly compliant implementation that can't talk to any other fediverse software. I think such test suite should be aligned with real ActivityPub, as implemented in fediverse. However, the document describing real ActivityPub was just removed from the official ActivityPub website, that is all you need to know about their priorities.

I think the closest thing we had to a useful test suite was helge's funfedi project.

@jupiter_rowland @elle @smallcircles @rimu I think Mastodon is better steward for ActivityPub than W3C

@silverpill @jupiter_rowland @elle @rimu

Your perspective is "that what app / FOSS projects do, and works, is a good thing". And that is a very pragmatic, workable approach in this difficult grassroots ecoysystem we have.

It also leads to a fediverse that is wholly app-centric, evolving by FOSS culture. Fediverse is 'ruled' by app devs as it were, and a "user" can only hope that the app they chose will fit their needs. This is not an ideal social networking environment, and not very different than Web 2.0.

But I am the first to admit that it will be very hard to rise to a more non-technical solution-oriented fediverse evolution process, where fedizens have more say in how the social network evolves.