The current fediverse is an evolutionary dead-end for 2 reasons:
1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay.
2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out.
Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with.
To avoid fedi to become less and less attractive to newcomers, we must now consider:
“Why do we want to grow the open social web, and for whom?” -- @ben
coding.social/blog/shared-owne…
Shared responsible social web ownership
We strive for an inclusive social web that is by the people and for the people. But how do we guarantee equity and shared ownership?Social coding commons
reshared this

🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •Quoting from another toot I just posted:
> What I am talking about is architecture and design, and all the things that allow people to easily form a clear mental picture on how things fit together, wrap their head around the fediverse.
> Never defining this well, and having the documentation be scattered all across the fediverse in 1,001 random locations doesn't help. Meanwhile the dev talk that is going on for years remains very inefficient due to endless Babylonian speech confusion.
Another quote has steps that would then be involved with solution design, and expand fedi's interoperable apps & services:
social.coop/@smallcircles/1161…
Without that, with app-centric protocol-decay-ensuring method we have:
0. Deteriorate your domain, reduce ambition
1. Hammer your design until it looks like a microblog, add warts for own features
2. Plug and pray that it works
3. Keep fixing based on daily fedi weather conditions
--
4. Discuss fixes in fire-and-forget fleety communication channels
@ben
🫧 socialcoding..
2026-02-21 15:27:43
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •To chain things together a bit on this fleety medium of ours, create a hyperweb 😜 I'll quote this toot to follow-up to
social.coop/@smallcircles/1161…
I remember about 2018 or so, when I joined my first #SocialCG meetup. It was when the CG was still strongly tied to #SocialHub community.
There were mundane items on the agenda, interesting to any #ActivityPub dev, and also the call to action was "whether you are technical or not at all, join the meetup, we are open and inclusive to all fedizens". Very friendly, good vibes.
However during the session the talk was not only CS expert level, but dealing with subject matter nowhere near the spec. It was 'wire reality' slang, and to learn it the guidance was either nowhere, or everywhere, dispersed. And this is still as it is today. To expertised AP developers their domain language sounds all natural, but it likely seems Martian to a dev newcomer.
Stark contrast to the W3C specs that leave folks with refreshing "Let's implement this" vibe.
@ben
🫧 socialcoding..
2026-02-21 20:38:48
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •I recreated an old diagram in Excalidraw that I spread about a couple years ago, and made it a bit more informative. Explanation can be found in the #AltText
See also and for discussion: discuss.coding.social/t/diagra…
Or join the Social experience design chatroom at: matrix.to/#/#socialcoding-foun…
Also posted to #SocialHub at: socialhub.activitypub.rocks/t/…
@ben
#SX #SocialCoding #SocialWeb #ActivityPub #SolidProject #fediverse
Diagram: Interoperability in Practice
Discuss Social Coding🫧 socialcoding.. reshared this.
David Megginson
in reply to 🫧 socialcoding.. • • •The interesting thing is that it's not really a trade-off at all.
The right side of the diagram almost never works in practice — unless there's a dominant player who can enforce strict compliance, like Walmart for a supply chain or the U.S. government for corporate filings — so it's typically a choice between messiness or failure, not between messiness or slow progress.
#standards
🫧 socialcoding..
in reply to David Megginson • • •@david_megginson
Yes, I agree. Though the diagram is too simple to capture it well, it is important to identify the forces that are at play, and the mechanics that drive them, and to subsequently monitor where you are and where you want to be in the future. So timely action can be taken to make corrective actions.
For the #SolidProject ecosystem for instance they might have identified a minimum set of standards to adopt, with which reasonably powerful "MVP's of the Semantic web" could be approximated with. And focus on strong library and tool support for that in multiple programming environments. Instead you enter a jungle of open stardards in various stages of completion, and good luck go figure it out. Also they might've focused on actual movement building. Far-reaching innovative standards - a new paradigm for the web - aren't adopted by the boardroom of a company, but are introduced by devs who get excited by what see and how they are empowered. And persuade management.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •@david_megginson
Though with regards to progress, there's a difference in both approaches.
At the #SolidProject side you have inertia by the slow standardization process. But should they figure things out in a good way, eventually the ecosystem catches up and the inertia can quickly decrease.
While at #ActivityPub side, since AS/AP remains stagnant, the ever increasing protocol decay and tech debt non-linearly increases inertia and progress. And on top of that, you are never done once you implemented the 'ad-hoc specs' of the installed base, and you have to account for continuous whack-a-mole development and maintenance burdens to fix #interoperability breakages.
The AS/AP based fediverse devolves into effectively no interoperability, and a situation that is more comporative to NPM dependency hell.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •@david_megginson
Btw, just found the v2 release announcement of @fedify and that is a prime example on how, on the grassroots environment end of the spectrum we can maneuvre into better territory.
Kudos to the #fedify developers. Handing people tools they need to focus on solutions, and build without getting thrown into deep on-the-wire impl detail reeds to worry about.
That is the positive side of the equation. There's not only a big uptick in interest for the #SocialAPI i.e. #ActivityPub client-to-server, which offers new opportunity to correct course. But also are there more #FOSS projects focused on robust tool and library support for the 'Solution developer' stakeholder.
In the revamp of the delightful commons initiative, made possible with support of @nlnet I emphasized all these projects, while I de-emphasized the apps that are already doing good for themself, but contribute to further divergence from open standards.
delightful.coding.social
hollo.social/@fedify/019c8521-…
Delightful Lists
delightful.coding.socialFedify: ActivityPub server framework
2026-02-22 11:34:57
Fitik likes this.
fedicat reshared this.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •@fedify @hongminhee I would be delighted if #fedify contributors would take a peek at the fediverse development curated list and propose a PR on how best to incorporate the changes to the project, now that the various #TypeScript packages have been modularized. That would be very helpful. And create an issue if the current list format is no good fit.
delightful.coding.social/delig…
@david_megginson @ben @nlnet
delightful fediverse development
delightful.coding.social洪 民憙 (Hong Minhee)
in reply to 🫧 socialcoding.. • • •🫧 socialcoding..
in reply to 洪 民憙 (Hong Minhee) • • •jon ⚝
in reply to 🫧 socialcoding.. • • •"Interoperability can only be proven after the fact."
@ben
u:find - Krzysztof Janowicz
ufind.univie.ac.at🫧 socialcoding.. reshared this.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •social.coop/@smallcircles/1161…
To get back to 'shared ownership' and @ben article that triggered my blog post.
The #fediverse is certainly not all cheerleaders, but the question is whether critical notes can be properly heard and addressed in any meaningful way. After all who are the ones who should hear them and act on them? It is "the herd", the crowd, the commons that happens to receive toots via their social graph, and to the extent these manage to penetrate bubbles and echo chambers. To make a strong argument, to reach people, the only strategy is social media influence marketing of sorts. You have to dare to rock the boat enough to be heard. And that's a very bad way to grow a healthy ecosystem I think.
It relates to the oft-heared criticism that on the app-centric #ActivityPub fediverse, it is the app devs who are de-facto in charge and decide what goes and what goes not.
The social dynamics are tricky but fascinating. I hope to be able to spend more time at coding.social
Joyful creation for the Social web
Social coding commons🫧 socialcoding..
2026-02-23 10:39:43
🫧 socialcoding.. reshared this.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •> It is "the herd", the crowd, the commons that happens to receive toots via their social graph
I should clarify that I refer specifically to the situation as it exists now, where the dev community basically chose microblogging as their prime communication medium.
🫧 socialcoding..
in reply to 🫧 socialcoding.. • • •What we need is the ability to support #ChaordicOrganization on the #ActivityPub #fediverse.
coding.social/blog/reimagine-s…
How We Reimagine the Social Web
Social coding commonsEmelia
in reply to 🫧 socialcoding.. • • •like this
Laurens Hof e 🫧 socialcoding.. like this.
🫧 socialcoding..
in reply to Emelia • • •@thisismissem
I sometimes feel that I must be crazy, and totally off the mark, as I - and luckily others with me - are saying these things for 7 years now. But it somehow hits a wall of inertia.
It is this inertia in itself, that has started fascinating me the last 2 years, and it is the reason why coding.social exists. We have to figure out how to deal with the grassroots social dynamics such that healthy long-term sustainable standards, ecosystems, and online environments emerge and further evolve.
Long ago I took notes on some major challenges that in my opinion hold back the fediverse from becoming The Future of Social Networking. These are all mostly social in nature, and are as relevant today as they were then. But this is also just imho. 😬
discuss.coding.social/t/major-…
Joyful creation for the Social web
Social coding commonsGeneral Discussion reshared this.
Emelia
in reply to 🫧 socialcoding.. • • •@smallcircles@social.coop oh definitely, and like, I think part of that is down to the fact that W3C received the first version of each of the specs and went "that's good enough for 10 years", when there were so many unaddressed and incomplete aspects of these specs. The fact that there wasn't actually authn/authz in the original specs should have kept the WG open until that was resolved. Without it, half the spec was basically pointless.
I really hope the activitypub ecosystem can escape the inertia of the existing network and architecture that is widely deployed today. I've said a few times that Mastodon's threat isn't Bluesky, no, it's the next generation ActivityPub app that does microblogging well but built with C2S. That's what will unseat Mastodon from it's dominant position, not a social app on a different protocol that has different features.
like this
Emsquared, J. J. Zepfanman @disc..., Internet Rando e 🫧 socialcoding.. like this.
🫧 socialcoding..
in reply to Emelia • • •And this time I am the one responding that I 100% wholeheartedly agree with that. Thank you.
(PS. I wouldn't describe it as "unseating" where it comes to the position of Mastodon. This would bring Mastodon in a better position too.. "uplifting"?)
General Discussion reshared this.
Emelia
in reply to 🫧 socialcoding.. • • •@smallcircles@social.coop I say unseating, as in, this sort of significant shift in architecture would like be appealing to people who want to use multiple social apps. The cracks would immediately be visible to everyone with the current social app vertical architecture of the fediverse.
Sure, it'd be more microblogging, which is good for Mastodon, but people on Mastodon wanting to use other apps would feel annoyed and want to migrate to gain access to more applications in the ecosystem — where as right now the choice is to migrate from one vertical platform to another vertical platform, which isn't really beneficial to most people.
I think @cheeaun@mastodon.social will likely be the person to build the first "killer" C2S app.
like this
Chee Aun 🤔, 🫧 socialcoding.. e jon ⚝ like this.
🫧 socialcoding..
in reply to Emelia • • •@thisismissem @cheeaun
Yes, I agree.
I think the important thing is that we get in a position where the ecosystem as a whole is able to make rational technology decisions that make the most sense and which fulfill clear objectives. But in order to be able to do that we first have to have a clear picture of where we are today, what we have established, where pain points are, and where we want to be tomorrow. Then work strategically along a shared (technnology) vision on ecosystem level, top-down. While individual developers drive experiment and introduce technology innnovations to be incorporated, bottom up.
Who dares imagine the fediverse of 5 years in the future. Or 10. Or ...
Who dares to #ReimagineSocialNetworking?
General Discussion reshared this.
Emelia
in reply to 🫧 socialcoding.. • • •@smallcircles@social.coop I think something that is going to be really interesting to explore is that with ActivityPub C2S, it may make sense for there to be aggregator services, which fulfil a role much like "relays" in AT Protocol — essentially a big fat pipe for applications to aggregate data from all their accounts from many individual data servers.
There may even be a need to have a way to have an application when writing an activity to the data server, to be able to say "also deliver this to the relay as a bcc/bto" (a relay could just be an inbox/outbox setup).
jon ⚝ likes this.
🫧 socialcoding..
in reply to Emelia • • •Yes, a whole range of new architecture patterns come within reach. The whole notion of services (and I don't mean as:Service actors) leads into new territories. A service-oriented fedi, or the fediverse of apps & services to not exclude anyone. Services that compose, orchestrate, and choreograph into solutions that serve people's needs. Consumed as social experiences that are entwined into the social web.
That is what Social experience design (SX) is targeting. The combination of:
1. Sustainable free software development
2. Of the future of the social web
3. Taking into account grassroots environment
And where the commons gradually build the foundation upon which it stands, and each of the 3 points above are continually improved.
The old book "SOA Design Patterns" from the good old XML days, still has a completely up-to-date pattern library to guide us along..
dzone.com/refcardz/soa-pattern…
General Discussion reshared this.
Chao-c'
in reply to 🫧 socialcoding.. • • •@thisismissem
🫧 socialcoding..
in reply to Chao-c' • • •@xChaos @thisismissem
I've been a long-time advocate for #HumaneTechnology. Social coding commons adds something to that to become "humane and harmonious technology". Humane by default. #Humanity is an intrinsic value of the movement. And harmonious by #SocialCoding. Coding is social, and first of all deals with people coordinating to find solutions that align with and satisfy stakeholder needs. Coding happens somewhere in the process, an impl detail.
A core principle of Social experience design is Sustainability, which is holistic in nature via the (adapted) Circles of Sustainability model. coding.social/blog/reimagine-s…
With this in place a #SX software solution will cycle through its Free software development lifecycle i.e. #FSDL, which drives a tailored development based on needs and lifecycle phase. coding.social/blog/reimagine-s…
Together this completely avoids a pure technology-driven development, ensuring Needs-driven development, and a natural NIMBY of inhumane technology and practices.
How We Reimagine the Social Web
Social coding commonsreshared this
🫧 socialcoding.. e General Discussion reshared this.
Chao-c'
in reply to 🫧 socialcoding.. • • •well, but what are "human needs"? I definitely like to avoid advertisements, but at the same time I am curious and I seek new things. And humans must be motivated to share news things... applause is great motivation, but is it enough? And we need real audience, not AI bot audience....
Maybe nerd needs are not exactly human needs, in the first place...
Also, some people tend to do thing just because they want to show they can.
And also you can optimize for as little technology as possible, or for as "optimal" technology as possible.
Currently, I am not so much concerned about future of ActivityPub, which is currently adequate, as it seems.
Running my own small instance is challenging, because resources are limited and I immediately see, that focusing on fundraising and controlling more resources is not the way.
I run state-of-the art Mastodon, maintained and updated by someone who is better admin, but I rather focus on tuning it. I play with tootctl statuses, found some undocumented features (this is not very human focused, to not document useful features).
Currently I would like to fine-tune lifetime of statuses in federated cache, which are without any interactions. Algorithm may be needed, because some accounts are automated and hyper active and flood the cache with tons of content (and someone on your instance is always going to follow them).
Domain-wide bans may or may not be the solution. What I am thinking about is domain-specific or even-account specific lifetime of statuses without interaction. This would save resources. Saving resources is in the end eco-centric.
Is my approach technology-centric or human-centric? Well, I want to compete for attention of humans with machines, designed to entertain them....
@thisismissem
reshared this
🫧 socialcoding.. e General Discussion reshared this.
🫧 socialcoding..
in reply to Chao-c' • • •@xChaos @thisismissem
Beyond basic needs, saying 'human needs' is a generalization. It's better to go from personal needs. #SX starts from individual needs and builds from there to take needs of all relevant stakeholders into account as they are identified during the lifecycle and evolution of a solution. Along the way there are perspective shifts, e.g. from personal needs to inter-personal relationships. See: coding.social/blog/reimagine-s…
If you start a software project, it is perfectly fine to consider yourself the only stakeholder. E.g. if you code just for you, as a hobby, and for the joy of coding.
If you make it #FOSS and publish to a code forge, you make a certain commitment to a new stakeholder, the FOSS developer, concering software freedoms. But not more than that, unless you explicitly commit yourself, and to the extent in which there is a mutual understanding what people can expect from you.
Then yes its human-centric. More importantly it aligns with needs, offers a solution.
How We Reimagine the Social Web
Social coding commonsGeneral Discussion reshared this.