Against fragmentation: unifying dev discussions with forum federation

[email protected]

On a recent episode of the Dot Social podcast, John O'Nolan of Ghost said;

"For the size of the group [working on federating long form articles], which as you say is not large, man, we are spread across Mastodon DMs sometimes, an email thread other times, a Discord backchannel on the other hand, it's all over the place. We could get more organised here I think, but it's a start."

@[email protected], 2025

https://flipboard.video/w/g8BgnihyFkMsZ4fwGe3MZn

The fragmentation of dev discussions is something I hear about a lot lately. Forum federation could be a solution!

Imagine every federated software project has its own forum space. Smaller projects might be content with a dedicated category on a community-hosted dev forum. More well-resourced projects might host their own instance of Discourse or NodeBB or whatever suits them.

Cross-project forums like SocialHub can then have a dedicated category for each software they know about, and use forum federation to sync that with the home forum space preferred by that project.

Eg the Discourse category on SocialHub is synced with the ActivityPub tag on meta.discourse.org. Any post in that SH category appears on Meta with that tag, and vice-versa.

With enough careful plumbing, that solves the fragmentation of public dev discussion across forums. But a lot of potentially insightful chats start in micro-posting threads. Adding a limited ability to start a new forum topic, by mentioning the relevent category or tag actor (eg @[email protected]), could bring those in too.

However, most of the examples John gives are private chats (fedi DMs, email, Discord, etc). I encourage devs to gird their loins and apply the 'release early, release often' principle to dev chat. Make public the default for dev chatter, unless it really is sensitive.

That said, with some careful work, support could be added for federating private conversations between forums too. Ideally in a way where AP actors could be included, that automatically open the chat to trusted groups.

[email protected]

silverpill1:

SocialHub has been the most prominent place for cross-project collaboration for years

Indeed, but thanks to forum federation, we're reaching a point where we can maintain a unified source of truth without a central dev forum (which is a SPoF). In theory, any general-purpose fediverse dev portal could host all the same discussions. But I'm not sure how widely understood this is.

silverpill1:

the need to create an account there was a major barrier to entry, but this is no longer the case as the forum supports ActivityPub.

I'd say that's more an aspiration than a reality. SH does have 2-way syncing with Discourse and NodeBB dev spaces, which is a great PoC. But do any of the other projects with their own dev forum (eg FunkWhale) have federation relationships with SH?

As we explored in the recent thread about the.socialmusic.network, there's lots of ways to plumb different forums together. Which means there's a bunch of experimentation to be done, and probably UX improvements to be made in all participating software, to make the various options easier to understand and use.

silverpill1:

I wonder what they meant by this. There are lots of projects that support long form content.

You'd have to ask John to be sure. But I suspect that he's describing projects that can send and display formatted Articles; long form content with things like titles, summaries, headings, footnotes, and positioned images. Not just plaintext Notes without a character limit. Which shortens the list quite a bit.

John's comment might also reflect the fact that there are projects that do belong on that list, but which don't yet have devs in communication with the "longformers" group including John (Ghost), @pfefferle (WordPress), Matt (WriteFreely) and @devnull (NodeBB). All the more reason to get more of these discussions public, and defragmentated with federation.

[email protected]

@[email protected] said in Against fragmentation: unifying dev discussions with forum federation:
> I wonder what they meant by this. There are lots of projects that support long form content.

I think what @[email protected] was trying to say was that given the relative size of the ActivityPub developer community, it's a little (or a lot) surprising that our developer discussions are as fractured as they are.

That's probably why I push so hard for discussions about fedi to take place on fedi.

I do get the appeal of smaller back channels, but they shouldn't be where the main business is conducted if possible...

[email protected]

I think the nature of our grassroots ecosystem, where we are still pioneering at protocol level, trying to fill gaps and overcome protocol decay (cope with the 'reality on-the-wire') has led to a bit of an upside down approach to software development. Where first technical facilities are built, then the impact of federation assessed in production, and then trying to make it address people's needs in subsequent improvements.

What does it mean if someone says they "joined the fediverse" with their app? By itself this says no more than that some form of technical implementation of ActivityPub is present in the project. It is a pure technical observation.

Looking at needs. What is the need for SocialHub? Maybe something like..

Support the communication and cocreation of all participants in the ActivityPub ecosystem to help foster healthy growth and evolution of the Fediverse.

There is no Forum in there, there's no dependency on apps. Apps are only the implementation of the need. Including the federation support in those apps. Currently the fediverse is highly app-focused:

"I have an existing app, and I add ActivityPub support so my app can federate with other apps."

And we currently have one reasonably mature way to do that, which arose from federated microblogging, but became a sort of baseline interoperability level (unfortunately).

@strypey raises an interesting question. What is a Forum if it becomes fully federated? Is it still useful to think in apps, or better to think in services? A Forum server delivering Conversation Services perhaps.

For SocialHub given the need above it made perfect sense to make it part of the Fediverse, give inclusive access to all fedizens. But the mere technical connection into a microblogging communications network did not take the need fully in consideration. Federate, deal with consequences afterwards. That's how we do it now.

Downsides to the technical integration, and where improvements are needed, are context collapse, and a shift of dev community communications to microblogging style, which is more ephemeral and fragmented by nature. And there is cultural impact. Is there more or less "sense of community" now, for instance? A more elaborate assessment on the extent to which federating SocialHub helped or hurt might be interesting.

Even more interesting I think, and where @strypey indicated a use case, is to venture beyond all the technical considerations that dominate the discussions. What do we hold conceptually in our hands? Envision the paradigm shift the fediverse brings if we wielded the technology to its full potential.

[email protected]

But do any of the other projects with their own dev forum (eg FunkWhale) have federation relationships with SH?

I haven't seen any posts from them.

It is not necessary to have a forum, though. I post from my own server (which is not a forum) whenever possible, that works pretty well for conversations. The only missing feature is an ability to create new topics. Some forums support topic creation using @group mention (Lemmy, NodeBB? cc @julian), but not Discourse.

[email protected]

@[email protected] it should work, try mentioning the ActivityPub or testing ground category. Fingers crossed.

[email protected]

silverpill1:

The only missing feature is an ability to create new topics.

... as well as some limit on doing so. I'm not sure it would be useful on a dev forum to have just anyone creating new topics, by chucking forum actors into microposts. But it would definitely be useful if category mods could, and maybe other regular contributors in good standing.

Even better if there was a way to start a new topic with the post they're replying to as the first post. With subsequent posts pulled in as comments, even if they've already been posted (subject to mod actions, Mutes/Blocks on nuisance actors, etc). So a mod of the C2S category on SH could;

stumble on a thread from their social browser (ie micro-posting app), involving some insightful watercooler chat amongst devs about C2S
reply to the post where it started, with the actor for the C2S category
and thus pull the whole thread into a new topic on the C2S category on SH

This would enable us to leverage the spitballing that often starts spontaneously around the fediverse water cooler, and add its insights to the categorised, searchable knowledge base of SH (and potentially other dev portals).

It could be a way of having ...

julian:

discussions about fedi ... take place on fedi.

... while addressing the discussion fragmentation and consequent wheel reinvention that @aschrijver quite rightly laments.

Is this something that could be done with the @discourse AP plugin @angus ?

[email protected]

aschrijver:

For SocialHub given the need above it made perfect sense to make it part of the Fediverse, give inclusive access to all fedizens. But the mere technical connection into a microblogging communications network did not take the need fully in consideration.

I can't speak for you or anyone else, but my focus in advocating for Discourse to implement AP was not on enabling people to follow SH discussions (and maybe reply) from a micro-posting app. But rather enabling the forum<>forum connections I evangelise in the OP. Getting interop with other styles of fediverse interface is just something we got for free by using AP to do it.

At the time, Feneas had set up their own forum, leading to a typical Big Endian vs. Little Endian geek holy war about which one projects should use. Which stressed some devs out so much that they said "a plague on both your houses", and set up their own project forum. So dev discussions were fragmented between not just two competing cross-project forums, but a whole asteroid belt of them.

The Feneas forum was also running Discourse, as were many of the project forums. I can't remember who first suggested it, but getting federation between Discourse instances using AP seemed like a logical solution. So a bunch of us, including @aschrijver and me (and maybe @how?) joined meta.discourse.org as a delegation, to pitch and argue for the idea.

A few years, huge amounts of dev work, and the coining of "threadiverse" later, here we are. With functioning forum<>forum federation over AP, between not just Discourse instances but multiple threaded discussion apps. So my intent with the OP was to refocus on that goal of using forum federation to unify AP dev discussions, and what we can do to further realise it.

[email protected]

@[email protected], with regard to your idea about pulling in topics by mentioning the group actor... I don't think it need be as complicated as that.

A simpler UX flow would be for a user to "cross-post" a topic to a local category. In fact NodeBB already allows for this, I regularly move microblog content into local categories for discussion purposes.

Now, granted, it's "moving" a topic, which isn't quite cross posting, but I'm hoping to distil the idea down to some actionable UX and activities so it can be done in a common manner across different implementations.

[email protected]

julian:

A simpler UX flow would be for a user to "cross-post" a topic to a local category. In fact NodeBB already allows for this, I regularly move microblog content into local categories for discussion purposes.

Can you explain the user workflow here in more detail? What the user does, what the software involved does in response, and what data is moved across AP and how, when it does. A link is fine so I can RTFN (Read The Fantastic Manual)

[email protected]

strypey:

I can’t speak for you or anyone else, but my focus in advocating for Discourse to implement AP was not on enabling people to follow SH discussions (and maybe reply) from a micro-posting app. But rather enabling the forum<>forum connections I evangelise in the OP. Getting interop with other styles of fediverse interface is just something we got for free by using AP to do it.

The goal for SocialHub was to help support the evolution of the ActivityPub ecosystem better. The goal for Discourse was to add AP federation support via the plugin. I am not sure the extent to which the implications of "becoming federated" have been looked at from a product development perspective at Discourse, in practice for SocialHub it resulted in pros and cons. Only when weighing these against each other can we really say whether the feature was "for free" or came at a cost, imo. Knowing the cons is input for improvement.

The externality I observe is more fragmentation in the dev community in part due to a shift in communications to the microbloggosphere. Discourse has the product tagline of "The online home for your community" and NodeBB describes itself as "Next generation community forum software". How federation impacts this concept of "community" is a worthy product management activity.

As an 'end user' I do not mind if an app calls itself a Forum software or something else, but I do know that each tool introduction introduces a high cost in crossing tool barriers, additional workflow steps, and maintenance tasks, that is often underestimated or even overlooked. For SocialHub a Forum tool is a means to an end: Healthy community that evolves the Fediverse.

In the past and in the context of Groups support I have advocated a lot for exploring what I called at the time "Community has no boundary" in more detail in order to support it well on the fediverse. See e.g. https://socialhub.activitypub.rocks/t/standardizing-on-a-common-community-domain-as-ap-extension/1353

Note that at the time, what became known as https://socialhub.activitypub.rocks/t/fep-8485-unbound-actor/2200 by @diogo was also under discussion (FEP is now retracted). This started as specifically targeting Group actors, make them independent of the server instance. This way the "community" can be spun up from groups, orgs and persons on any fedi software and still feel and act as a community. Now you can control the ways in which it can be accessed.

[email protected]

aschrijver:

more fragmentation in the dev community in part due to a shift in communications to the microbloggosphere

it's a multifaceted issue:

discovery of communications decreases, partly due to discussions being started in other venues and not federating back to SocialHub
- because people start those discussions outside of SocialHub, this doesn't always result in the creation of a topic here
- because people don't deliver to SocialHub and there is little-to-no proactive graph traversal after-the-fact, people's participation in those discussions doesn't always make it back to SocialHub
quality of discussions decreases, partly because other venues do not share the same social expectations as SocialHub
- because there is no conscious decision to include or exclude a given post from syndication to specific websites, posts not intended for SocialHub might show up on SocialHub anyway
- because even a conscious decision to include a post on SocialHub may result in an unwanted post on SocialHub (low relevance, spam, etc)
attention paid to this forum decreases, as a confluence of the above two factors

this is something that could be improved with a better information model and distribution model.

loosely, we want the posts that end up on SocialHub to be relevant/valuable/etc, and we don't want those posts to only exist on SocialHub

wrt the shortcomings of our current model in the fediverse, the biggest problem is that we lack explicit notions of locality within a certain space, of where our posts should show up. you are never posting to a space, you are just posting. the posts then end up wherever random consumers decide to show them.

a concrete example: you never post to a profile or feed; profiles are implicitly constructed based on whatever the local instance is aware of. this means you can't exclude a post from your own profile view, because there is no real profile view. consider how you'd do a feature like youtube's "unlisted" (not to be confused with mastodon's "unlisted"). you don't have a collection of your own posts. even if you did, most current softwares would ignore it. (the outbox is the closest thing to that, but unless you consider the activities themselves to be the posts, you are going to have a hard time with getting any consistent state due to no consistency guarantees wrt side effects -- an edited post might result in an Update, or it might result in the Create being modified.)

so if anything, we should stop acting like it's okay to just sling data around and reconstruct it any which way, assuming that everyone else will reconstruct it just like we would. we need more formally defined concepts of a "forum", "thread", "post" instead of trying to squeeze everything into the AS2-shaped box, with clear semantics so that when two different softwares use the exact same term, they mean the exact same thing -- no fudging, no equivocation. we need clearly defined protocols that govern the interfaces into and out of the forum -- activitypub is not enough. and we need more intentionality in explicitly making use of those interfaces; conversations intended to end up on a forum need to keep that forum in the loop, ideally with something other than a mention, and ideally with an approval mechanism.

the challenge is that due to the complete lack of signaling of protocols (and the sheer volume of assumptions being made as a result), we can't cleanly break from existing practices. there is no "upgrade path". you can't even describe resources more fully, because providing that additional information trips up some existing processors when they encounter something with more than one @type or with additional @context. i don't really see a way forward without something breaking. otherwise, we just end up with a really restricted "lowest common denominator" outcome that holds back digital communication for as long as we continue to operate under that paradigm.

[email protected]

@[email protected] said in Against fragmentation: unifying dev discussions with forum federation:
> Can you explain the user workflow here in more detail? What the user does, what the software involved does in response, and what data is moved across AP and how when it does.

I don't have one yet, but I'm planning out an FEP for this once I have some implementors interested.

The UI would be a dedicated cross posting action. How that ends up looking is up to the implementation.

Mentioning a group actor doesn't work reliably because someone could mention the group actor in passing, and not mean to have the entire conversation imported.

[email protected]

trwnh:

loosely, we want the posts that end up on SocialHub to be relevant/valuable/etc, and we don’t want those posts to only exist on SocialHub

This! Imagine we could get to the point where SH is a display layer on top of a distributed data layer of dev discussions. So deleting stuff from SH didn't delete it from the underlying data layer. Then we could develop a process for pruning SH down to the strong wood. Akin to using git rebase to prune version history down to the key info.

OR we could keep SH as is, and use a federated forum at distillery.activitypub.rocks to create a more curated portal. If anyone disagreed with the curation approach, the underlying data is all still there, so they could fork the effort to demonstrate their approach on top of the same shared data layer.

Does this sound familiar? It should. It's exactly how existing fediverse moderation works.

julian:

Mentioning a group actor doesn't work reliably because someone could mention the group actor in passing, and not mean to have the entire conversation imported.

Fair point. This could be addressed by having action-specific Actor addresses (eg @[email protected]). In the longer term there could be a different character to denote actions (eg !crosspost@ @[email protected]), although that would need pan-fediverse buy-in.

On top of this, I mentioned the option of limiting crossposting permission to fediverse accounts with privileges on the receiving forum (eg forum and category admins/mods only). That could further reduce the likelihood of accidental misuse, as well as intentional flooding.

[email protected]

strypey:

trwnh:
loosely, we want the posts that end up on SocialHub to be relevant/valuable/etc, and we don’t want those posts to only exist on SocialHub
This! Imagine we could get to the point where SH is a display layer on top of a distributed data layer of dev discussions.

This is the more interesting discussion to me, and where a design-first approach can be very innovative and valuable. This is what I meant above when saying "what is a Forum once it becomes fully federated?". Adding federation support to any app changes the nature, characteristics, and audience of it in ways that should be well-known and anticipated.

This design focus at ecosystem level is almost entirely missing in fediverse evolution, and with its bottom-up processes the demand is often "I have this app feature, so I need that AP extension to support it". No matter how high-quality your own app is, for the ecosystem where your foundational technology evolves, this constitutes a Big Ball of Mud anti-pattern: A software system that lacks a perceivable architecture.

Now the tradeoff of the 3-stage bottom-up standardization process that we need in our decentralized grassroots environment is that we likely should allow this anti-pattern to an extent, as it stimulates bottom-up innovation of the fediverse by freeing devs to experiment with new things. The FEP Process allows for this by being non-normative and completely open to any participant to contribute to. And it has many overlapping mechanisms and good-practices that need to be reconciled later to assure the broad interoperability of the fediverse long-term.

Summarizing you can say that both a bottom-up and a top-down standardization process are needed. They should meet and help realign and reinforce each other, and give direction to the ecosystem as a whole. Bottom up we absorb the technical reality and best-practices, and top-down we craft and chisel an open interoperable fediverse able to support the social experiences that people need.

---

Tangential. Social coding commons is a movement of people interested in exploring these more social sides of decentralized social networking environments and focuses on building solutions that serve people's needs: social experiences. For this we explore a methodology called Social experience design (SX) tailored to cocreating Sustainable open social systems (SOSS) with participants withing the commons, in order to deliver and evolve services for the social web. A fediverse that may result from these efforts goes "beyond the app" into app-free computing, towards the vision of a peopleverse. A place where online technology serves our daily lives.

For anyone interested, there is a Social experience design chatroom (social / sociosphere) and a Groundwork labs chatroom (technical / technosphere) to join.

[email protected]

strypey:

Cross-project forums like SocialHub can then have a dedicated category for each software they know about, and use forum federation to sync that with the home forum space preferred by that project.

Yes! This is the plan. Each category in #software or #programming is ready to be federated. So far, only a couple are: #software:discourse and #software:nodebb, maybe others. It's up to each software project to activate ActivityPub in their category and federate with their own channels on the Fediverse.

julian:

That's probably why I push so hard for discussions about fedi to take place on fedi.

Note that this discussion is taking place on fedi.

It took some time for own to eat our own dogfood, but there's no more barriers for this community to embrace the Fediverse fully. The #standards:fep and #fediversity discussions are federated. https://socialhub.activitypub.rocks/t/federated-socialhub-categories/4648/1 maintains the list, and we can federate more.

I guess what it missing is a directory of all Fediverse actors involved in the AP development processes, so they can follow each other. In this scenario, the SocialHub would simply become an aggregator of memory, enabling knowledge building from the scattered flow of discussions, where curators can pick and quote relevant parts into something actionable for everybody.

[email protected]

A good example of the fragmentation. In this toot I mention my regret that the great discussion on https://socialhub.activitypub.rocks/t/replacing-http-signatures-with-bearer-tokens-or-ocaps/5444/1 happened in fleety microblogging timelines.

[email protected]

SocialHub developer community: Reboot or Shutdown?

I used the #fediversity:fediverse-futures subcategory for a while, along with Fediverse futures on Lemmy

This is a good use case for forum federation. These two spaces could have been unified, reducing the overhead of maintaining both, while still making it easier for people to find and comment on the topics raised using accounts on Lemmy services (or similar) instead of SH accounts.

SocialHub developer community: Reboot or Shutdown?

It is nice to offer dedicated forum space, but most FOSS projects don’t use it. They prefer to just use their own primary project channels, and I can understand that. Btw, forum federation may become a great solution in this area.

As @how says;

how:

Yes! This is the plan. Each category in #software::category or #programming::category is ready to be federated. So far, only a couple are: #software:discourse and #software:nodebb, maybe others. It’s up to each software project to activate ActivityPub in their category and federate with their own channels on the Fediverse.

The obvious workflow to me is that new projects can be invited to use a category here, so they can have forum space without the overhead of setting up their own forum instance (or even the decision-making overhead of coming to consensus on what software/ service to use for it). If they don't survive to maturity, at least there is some record of their existence others can learn from.

If they do survive and mature, they may want to establish their own forum. We can then encourage them to have a category specifically for interop discussions, and federate that with their category here. Which is what we ought to be doing with existing AP projects that currently operate their own forum.

[email protected]

The technical specifics behind how forum federation works, and how it is accessible in other sites shouldn't be top of mind (or thought about at all) for anybody except those who are maintaining it.

For everybody else, it should just work.

[email protected]

This suggestion I just posted in Julian's topic about FediCon is relevant here;

Final thoughts re: FediCon 2025

One thing we could experiment with, if you’re keen, is a complete mirror of the existing SH using NodeBB. With full archives, and full federation so anything posted to one can be read on both. That way people can use their forum interface of choice to participate (as well as being able to use other apps via AP federation). It also ends the problem of the existing SH being a SPoF, and thus a source of tension and territorial conflict.

Darkscribes Community

Against fragmentation: unifying dev discussions with forum federation