(Yes, there’s a TL;DR below)
Some time ago I understood from @sl007 and @hellekin that you won’t be pursuing this Phase 1 in the short term, even with the NGI0 funding. As a fellow promoter of interop based on ActivityPub I too find that a pity, of course. But from the perspective of Discourse, the leading and most popular forum software, there’s tons of forces and other priorities to take into account and this business decision in that light probably makes a lot of sense:
Decision: This RFC as proposed just wasn’t attractive enough to be given priority and placed on the Roadmap.
The RFC took a MVP approach with “Let’s start by creating a Facebok-like aggregated content feed across forums” as proposed by @Falco. It is just one of many, many features that might result from having native ActivityPub support in some form or other. Arguably having such a timeline is sort of a sidestep of what you normally find in a forum, and to me doesn’t seem like a real core feature. More of a bolt-on extension and therefore a nice-to-have.
A different approach
With the need to come to a quick MVP of ActivityPub support out of the way, maybe we could follow the opposite process:
Ideation: Brainstorm interop use cases and gauge them for viability in terms of business benefit and USP’s.
I.e. which features would be truly attractive to have in Discourse? Or even: Where might Discourse miss the boat if not in the loop on what is possible?
In @Falco’s latest post above he mentions Lemmy which is built from the ground up upon a dedicated Linked Data vocabulary that matches their business domain. They have their MVP ready and in production, and are now looking into expanding ther feature set on top of their own domain. This may include federating with the other domain of Microblogging where Mastodon and Pleroma and others are very successful.
The approach to the ideation might be along this exercise:
Exercise: Let’s envision how Discourse might have looked like if it was similarly based from the start on their own ActivityPub-based business domain (defined as a Linked Data vocabulary).
Let’s go wild in this brainstorm session, and let our creativity run freely.
The list of use cases that result from all this may be interesting enough business-sense-wise to become part of the Roadmap, but if not they may still inspire the community to build plugins and components, and lay some of the groundwork to build upon in a later stage.
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.
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.
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.
There are some up-and-coming competitors in your industry, who are innovative, taking fresh approaches, and iterating fast on adding new features (you at Discourse know best who these are ). IMHO Discourse in feature-completeness still stands far above what their products have to offer. And you have a community like no other to help you evolve the product.
But the interop opportunity that exists now, might also become a threat. Either competitors might jump onto the opportunity first, or - maybe driven by the EU Digital Markets Act - the Big Tech platforms create something with overlap in forum software domain. In both cases it would be harder for Discourse to align with this standard and have the most authoritative voice in its specification design.
This has become a longer post than I intended. Sorry about that
In summary I am arguing that, given current stance on having ActivityPub support, it may be prudent to go from a short-term MVP-like focus, to a more broad evaluation of what ActivityPub interoperability could bring Discourse in terms of USP’s and positioning in the longer run. I.e. to elaborate the business case of ActivityPub adoption, starting with an ideation phase.
(How this is best set up - provided you are interested - I leave in the middle, but it may start simply with just a new AP topic having a summary wiki of collected use cases on top and people discussing use case ideas in the thread)