Against fragmentation: unifying dev discussions with forum federation
-
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.
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
@typeor 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. - discovery of communications decreases, partly due to discussions being started in other venues and not federating back to SocialHub
-
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] 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.
-
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.
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.
-
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.
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.
-
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.
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.
-
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.
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.
-
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.
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.
-
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.
-
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.
This suggestion I just posted in Julian's topic about FediCon is relevant here;
Final thoughts re: FediCon 2025One 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.
-
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.
Cross-referencing another fragmentation issue:
Update: I made more reference to this fragmentation issue, by necro-posting to this topic:
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login