#ThoughtProvoker  

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

http://coding.social/blog/shared-ownership/

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

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:

https://social.coop/@smallcircles/116109322688804011

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

To chain things together a bit on this fleety medium of ours, create a hyperweb 😜 I'll quote this toot to follow-up to

https://social.coop/@smallcircles/116110545919004233

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

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: https://discuss.coding.social/t/diagram-interoperability-in-practice/828

Or join the Social experience design chatroom at: https://matrix.to/#/#socialcoding-foundations:matrix.org

Also posted to #SocialHub at: https://socialhub.activitypub.rocks/t/activitypub-versus-fediverse-interoperability-in-practice/8498

@ben

#SX #SocialCoding #SocialWeb #ActivityPub #SolidProject #fediverse

https://social.coop/@smallcircles/116119514853649098

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 https://coding.social

@ben

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

How We Reimagine the Social Web

We find novel ways to collaborate and create value together.

Social coding commons

@smallcircles @ben 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

@david_megginson @ben

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.

@david_megginson @ben

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.

@david_megginson @ben

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.

https://delightful.coding.social

https://hollo.social/@fedify/019c8521-92ef-7d5f-be4d-c50eae575742

Delightful Lists

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

https://delightful.coding.social/delightful-fediverse-development/

@david_megginson @ben @nlnet

delightful fediverse development

Delightful curated lists of free software, open science and information sources.

@smallcircles Okay, we'll look into the list, and send pull requests!

@smallcircles @ben Unfortunately, the top-down approach often stalls under its own inertia and never develops into anything at all.

If you try for too much interoperability too fast, the costs aren't evenly distributed: some implementors will have to make very few changes (usually the ones who had the most power and influence during the standardisation process), while others will have to tear up a lot of stuff and start over.

In the business/government/aid world, that can have ripples far beyond the IT systems, right into the way they organise their operations; in the FOSS world, it can mean abandoning popular features, losing users, and even destroying the contributor culture.

An 800 lb gorilla like Walmart can force that level.of dirigisme on its suppliers, but in the open world, we can just ignore or fork if we think someone's getting too restrictive: note how most web syndicators stuck with RSS 2.0 even after Atom came along to "fix" its "problems," for example (and Atom wasn't even that bad). 🤷

@smallcircles
I remember this sentence from https://ufind.univie.ac.at/de/person.html?id=1001662, around 2013:
"Interoperability can only be proven after the fact."
@ben