Positioning ActivityPub: De-Emphasize "Being Part of the Fediverse" as primary USP

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 :cry: "

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.

7 Likes

Lots of nice thoughts here. Just to speak briefly:

  • I still think advocating “the fediverse” without specifying a protocol is useful. It was useful before ActivityPub standardization even began, so I still see it as useful now.
  • I agree that seeing ActivityPub as merely a social network protocol is selling it short. It’s a communication system using linked data, yes… but what does that mean really?
  • Another way to put it, in more computer-science’y terms, is that one of the things that makes ActivityPub a powerful foundation is that it follows the Classic Actor Model, meaning a basis on asynchronous inbox delivery / message passing. It turns out this is a good design for social systems, but Erlang has shown how useful it is for general wide networked systems (Spritely Goblins takes the same approach).
  • This is useful for more than just social network protocols, but it’s easy to think about / map on top of social networks because it’s easy to think about inboxes and delivery… it’s a lot like how we get our own physical mail, or like e-mail (and ActivityPub is very e-mail like).
  • The choice to supply a vocabulary for social systems with ActivityStreams but use linked data as an extension mechanism was thus deliberate to open may other paths. This (especially combined with the above) does set apart ActivityPub from most other social network protocols in this space, afaict.
  • What ActivityPub did not do is set out the authority model. This has turned out to be mostly fine because roughly ActivityPub is currently used in a way akin to social networks or email. However, if we would like to fully take advantage of ActivityPub’s actor-model type nature, that’s where leveraging object capability security on top of the actor model comes into play. But if you’ve been following my work, that’s where Spritely is trying to advance things.

Those are my thoughts. Anyway, yes, ActivityPub has the potential to be useful for much more than just social networks. But getting the authority model right is key to success there IMO.

4 Likes

I agree with this in the sense that we shouldn’t be making sacrifices to make new features compatible with the existing microblogging servers. For example, I’ve seen a couple of times that someone offered to implement groups as accounts you mention and they then boost your post (this already exists). While this would indeed offer stellar compatibility with Mastodon et al, it would severely limit the user experience if you want to have groups as a fully-integrated feature.

But, it’s nice to have some kind of standard vocabularies and their usage for different domains. It’s nice to have intersecting feature sets of different software be compatible with each other without any additional effort. So, for example, if there are two projects that have forum-like functionality, they don’t invent the same thing in slightly different ways that make them incompatible with each other. I probably need to fix my email setup (I’m not receiving an account activation email from git.activitypub.dev, and I’ve already had problems like this, it’s about time I sort it out for good) and get working on that capability negotiation FEP.

The authority model is another tricky part, but it’s hard to have any consensus here. Since I’m modeling Smithereen after VK, I’m allowing the owner of the top-level post to delete any comments (replies) on that post. Mastodon doesn’t do that, it considers every toot a separate, self-contained entity, just like Twitter does. So, there are naturally bound to be conflicts like these where instances running different software would disagree over what’s in a reply thread.

3 Likes

Bonfire (renamed from CommonsPub) is adding the Valueflows economic networking vocabulary to their ActivityPub implementation.

As you can read at https://valueflo.ws/ it’s not intended for business-as-usual but for alternative-economy networks: eg cooperatives of cooperatives, DisCOs of DisCOs, Solawis of Solawis, etc.

https://gitlab.com/bashrc2/epicyon is also adding some economic features. I suspect for similar purposes…

2 Likes

FYI: I have described a use case for Discourse, named “Community has no boundary” that avoids talking about fediverse, and just looks at the interesting case as-if Discourse were built from the ground up with ActivityPub-based federation support. What do we get then? Well, we’ll get: Discourse-as-a-Fabric and no longer merely a stand-alone forum product, for a limited amount of people you manage to entice to sign up to it…

Want to boost this use case to the fedi? Here’s my toot about it.