I write this topic based on this post I just created in the Discourse forum, due to the fact that Discourse sees no merit in implementing AP on short notice (see also Discourse [this] and ActivityPub).
Let me start by duplicating from that post the following:
ActivityPub versus Fediverse
I notice there is a broad misconception to what it means to have ActivityPub support in an application. Many people think that the reason to do so is to become ‘part of the Fediverse’. And here the thought immediately goes to federating with Mastodon instances i.e. implementing interop with (i.e. to join) the federated Microblogging domain.
Yes, this is a very attractive opportunity once having ActivityPub support, and many other applications like PixelFed (Insta alternative), PeerTube (YouTube alternative) and also Lemmy (Reddit alternative) are looking to do so. They make the Fediverse a more attractive place to participate in, and lotsa innovations are taking shape that make the fediverse future be really exciting.
BUT…
Arguably organizations targeting large user bases like Discourse might ask questions like: “Why would I want to integrate with the Fediverse with only about 4 million users?” or “Why would I integrate Microblogging into my software that is operating in an entirely different domain?”. And they would be right to state that, and forego ActivityPub implementation on that premise.
HOWEVER…
ActivityPub implementations are about much more than becoming part of the (Microblogging part of the) Fediverse. It makes perfect sense to implement a Linked Data vocabulary uniquely designed for your own business domain and have your own product instances federate together. Or all instances of your product and that of competitors in your industy who also adopt the same vocabulary, for that matter.
One example here is the ForgeFed project that aims to define interoperability standards for code forges (github, gitlab, gitea, sourcehut, etc.) to implement. Doing so makes tremendous sense, especially for the smaller code forge projects to provide an attractive alternative to Github (which has become all-too-dominant as a centralized, increasingly more walled-garden platform). If broadly adopted no longer will developers need to juggle a plethora of forge accounts on scattered servers across the internet to participate in interesting code project, file an issue, comment and submit PR’s.
(Note that - as indicated above - the same issue that people have with stand-alone code forges existing all-over-the-place, is what I and others also experience with our participation in a ton of Discourse communities.)
Opportunity: Discourse is uniquely positioned to take the lead in setting interoperability standards for forum software, and shape the standard in such way that it aligns perfectly with current Discourse feature set.
[… some more argumentation left out]
Misconception? Missed opportunity?
Most people when thinking of what the Fediverse entails - if they are fedizens, or have heard of fedi before, or take a first look - immediately think of a Microblogging social media platform a la Twitter, but decentralized (and also in other ways ‘better’). And this is understandable, since the Mastodon microblogging platform has laid the foundation of what fedi currently is. They were key to its success.
We have a great community of evangelists and advocates who spread the message “Join the Fediverse, the new social web by and for the people”. A great and inspirational message.
Part of this advocacy is that both AP and fedi promoters create posts and repo issues all over the place with the follow gist: “Implement ActivityPub to join the Fediverse”. Great too, and to be applauded.
Along with that come discussions of fedizens like “Does this app have AP support” and someone answering: "Yeah, but they do no federate yet, nor do I see that on their roadmap 
"
And here I think we as ‘ActivityPub community’ should pop our heads up, and realize that this whole notion of ActivityPub as the tool to become part of the Fediverse and advertising it accordingly is selling the power of this specification short. We’ll miss opportunities if we continue to pitch so narrowly!
Instead we should position as:
ActivityPub: A generic interoperability standard to facilitate decentralized applications in any business domain (based on Linked Data vocabularies).
Note that this definition does not have ‘social’ or ‘social media’ in it, nor does it have to. Take ForgeFed, for instance. Is a ForgeFed compliant forge a social media app? Yes, it is in a sense, but it is stretching the definition of what most people understand when hearing the term ‘social media’. There may be many other appliances where the link with this definition is even weaker.
Advocacy efforts
The rationale of implementing ActivityPub without the primary objective of ‘becoming part of the fediverse’ is just as strong a case to bring forward, and we should not make the mistake of failing to pitch things accordingly to any organization or project.
Integration with fedi might always come at a later stage, but regardless of that having more people involved with AP in whatever way, and especially in ways that involve entirely different and separated business domains, will be a great driver of ActivityPub evolution. Different perspectives will be taken into account and contributions that broaden the applicability of the specification.
In terms of advocacy we need to promote this more holistic mindset to our fellow fedizens, and also separate in our thoughts the idea that we have two forms of advocacy:
- Fediverse advocacy
- ActivityPub advocacy
They are very much complimentary, but also quite valid approaches to follow in their own right.