@sri @jsalvador @ben @nlnet

It would be even better if on #fediverse as a whole the developer ecosystem were able to move beyond the app-centric development model that dominates. Basically the app-centric approach constitutes a "poor man's TAM", facilitating technology uptake on the basis of how #FOSS projects are typically developed where the individual devs are in charge and there's hardly need to coordinate and collaborate at ecosystem levels. Here the grassroots environment within our ecosystem failed miserably. Apparently we are too fiercely independent to be able collaborate at scale. When a big player joins you get app-by-app competition, and their product development process is likely to easily blow the FOSS project out of the water.

If we had a more service-oriented #ActivityPub fediverse, a fedi of apps and services, then - depending how this is designed - it might be much harder to 'win' the market, as the competition becomes more on quality of service than feature sets.

@sri @jsalvador @ben @nlnet

The fediverse has been weirdly stuck for many years, driven by app developers who attended first and foremost to their own app projects and only secondary to the technology base the entire app is built upon. There was also hardly funding to do anything else. It may be pragmatic approach, but its not smart, eventually weakening the entire ecosystem. And here we are today, with a mountain of protocol decay and tech debt holding us back.

For many years people, me included, have argued that we should focus on getting robust extensibility mechanisms in place, fill the #ActivityPub holes, and not handwave it to say "yeah it is #LinkedData this and that sorta kinda". #Interoperability requires way more rigour at the protocol level.

Nice effect that #ATProto had, was it opened people's eyes to the benefits of having a sound technology base. The ATProto ecosystems excites newcomers, whereas fedi only frustrates with its high barrier to entry and whack-a-mole dev.

@sri @jsalvador @ben @nlnet

Today we see a big uptake in interest in the #ActivityPub C2S part of the specs, to implement the Social API, and there is again an opportunity to reboot and give the ecosystem a big boost.

I'd say the most important projects in the #ActivityPub ecosystem are the ones where people focus on building reusable libraries, SDK's and developer tools that honor the original promise of the AS/AP specs: to allow heterogeneous decentralized social networking. The conceptual architecture of fedi of "addressible actors exchange activities with object payload" is ultra-powerful, a universal distributed message bus of sorts. And the easier it gets to model services on top of this model, the more excitement and new entrants we'll see in the ecosystem.

I am highly in favor that we not dogmatically focus on keeping compatibility at all cost to the existing installed base, where somehow this powerful architecture has devolved into "social media microblogging" galore.

@sri @jsalvador @ben @nlnet

What is interesting re:Technology adoption models is that #fediverse with its app-centric evolution de-facto follows the TAM that is typically practiced in the business world. The success of fedi depends on the individual product development of fedi apps. This while #FOSS is typically very bad at product development, and this partly due to the (social) dynamics being very different than in the biz world.

There exist very different TAM's that DO take the social dynamics within grassroots movements into account, aligning much better to our environment, for example taking Joy and Curiosity into account as motivators why people start FOSS projects. See: https://discuss.coding.social/t/challenge-fixing-the-fediverse-technology-adoption-lifecycle/38#alternative-adoption-models-4

At Social coding commons by means of Social experience design a new type of TAM is part of the research effort. One that is explicitly tailored to a grassroots ecosystem that develops the technology base on which it stands, and create positive feedback loops and flywheel effects.

@sri @jsalvador @ben @nlnet

In my opinion where it concerns social network innovation, when we continue to follow the app-centric model we have today we enter a dead-end street. Though it gives interesting applications it will not constitute the future of social networking.

To me it is really crazy that a new fedi app that, say, enters a Video domain would need to adopt Peertube namespaces in their #ActivityPub extension model. If you look at that model it is no different than taking on dependencies in regular #FOSS development. As soon as the Peertube namespace is in your project, then Peertube is in charge of that part of the design, an upstream dependency. But Peertube doesn't care about you. It is an end-user product doing their own product development.

And then things worsen when the new fedi app entry pushes their own extension properties into this ball of mud. It is a design approach that basically assures loss of interoperability and severe whack-a-mole pain to devs.

@smallcircles @sri @jsalvador @ben @nlnet whats the alternative then ? Feditube?

@virtualpierogi @sri @jsalvador @ben @nlnet

When it comes to #interoperability there is no way around having consensus on what you interoperate on, and there must be alignment on some kind of Video related domain model that is robust and consistent.

If there were a robust #ActivityPub extension mechanism as well as good development practices and processes for the creation of extension into new business and application domains, then this mechanism can still facilitate app-specific extension on top of such a Video domain specification. It is very common for protocol design to have all kinds of extension points, look e.g. at #ATProto or #CloudEvents.

And more specialized domain extensions can also facilitate further extension in their design. Look e.g. at #ForgeFed AP extension, which allows custom forge-specific metadata collections to be sent with a federated Issue or PR.

@virtualpierogi @sri @jsalvador @ben @nlnet

It needs concerted effort, as argued in my blog post, to set all of this up. Things can start small and pragmatic, and then gradually evolve and mature, but we should take care it evolves in the proper direction.

There are trade-offs to consider every step of the way. If there'd more capabilities to introspect the functionality that an #ActivityPub actor offers, it would diminish the need for an upfront design-by-consensus process, but it would increase the complexity of the specifications.

I drew this in a diagram a couple years ago, and transferred it to our social coding forum at: https://discuss.coding.social/t/wiki-grassroots-standardization-processes/672?u=aschrijver

Here you see the fediverse devolve into non-interoperable app-by-app whack-a-mole development, keeping track of all the moving-target #FOSS projects one took a dependency on. Versus the #SolidProject that tries to hammer out full-blown specs upfront, which became a huge package to deal with, with high complexity to implement.

@virtualpierogi @sri @jsalvador @ben

Unfortunately there's a new threat, and it was addressed in the #FOSDEM keynote speech by @michiel of @nlnet .. and that is the mad dash to incorporate #AI into everything and vibe-code stuff together in a heartbeat.

I think this is particular bad for the fediverse #SocialWeb still lacking its robust foundations. The #LLM's will have no problem figuring out how to mix'n mash the existing protocol decay and tech debt into new applications that are rushed into production. Finally non-protocol-experts are enable on the ecosystem and can onboard themselves without involving themselves in endless plumbing of the most low-level technical implemention details of #ActivityPub devs.

But the ecosystem will rot and decay as a result of it. Furthermore if a slew of AI-generated fedi apps are launched in quick succession and some of them find good uptake (until they break in unexpected ways), it will serve to attract unwanted corporate attention I'm afraid.

@virtualpierogi @sri @jsalvador @ben @michiel @nlnet

By their design #LLM's will always follow the old way of doing things here, and I really wonder how this is going to turn out. People should be very wary here. #AI application trends towards a point-of-no-return, where only the AI can still keep track of the generated code mess.

A good example here is this Microsoft distinguished engineer saying that their aim is for one dev employee creating 1 million lines of code in one month. Once you get there, you cannot ever go back without ditching all AI stuffz and starting over.

Btw, the talk by Michiel Leenaars is mentioned my blog post, but I'll drop it here too. A very interesting recommended watch:

https://fosdem.org/2026/schedule/event/FE7ULY-foss-in-times-of-war-scarcity-and-ai/

@smallcircles @sri @jsalvador @ben @michiel @nlnet
Ive seen that godot is passing through the same problems , the first solution that comes to mind is whitelisting the commits that come from real coders that contribute quality code. So you have to apply for a green card so to speak to commit your code.