Against fragmentation: unifying dev discussions with forum federation

Fediversity
1

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.”

@johnonolan@mastodon.xyz, 2025

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 @discourse@socialhub.ActivityPub.rocks), 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.

3 Likes
2

SocialHub has been the most prominent place for cross-project collaboration for years. This is where the FEP process was born, after all. I suspect that 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.

Cross-project forums like SocialHub can then have a dedicated category for each software they know about

There is such category already: https://socialhub.activitypub.rocks/c/software/14

It appears to be not federated, though.

-----

Aside:

For the size of the group [working on federating long form articles], which as you say is not large

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

1 Like
3

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.

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.

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.

1 Like
4

@silverpill@mitra.social 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 @johnonolan@mastodon.xyz 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...

5

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.

1 Like
6

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.

1 Like
7

@silverpill@mitra.social it should work, try mentioning the ActivityPub or testing ground category. Fingers crossed.

8

… 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 …

… 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 ?

2 Likes
9

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 OP 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.

10

@strypey@socialhub.activitypub.rocks, 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.

3 Likes
11

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) :smile:

1 Like
12

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. Standardizing on a common Community domain as AP extension?

Note that at the time, what became known as FEP-8485: Unbound Actor 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.

13

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.

3 Likes
14

@strypey@socialhub.activitypub.rocks 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.

2 Likes