Post #2346338

2026-05-07 08:27 UTC

@uriel@x.keinpfusch.net > In a heterogeneous federated ecosystem, being able to formally discover which features a remote server actually supports would greatly improve interoperability and robustness, while reducing the current dependence on conventions and reverse engineering OMG this! I suggested exactly the same thing on the SocialHub dev forum some time ago. @smallcircles@social.coop has often expressed similar frustrations about a perceived lack of clear direction of protocol evolution, phrased as "protocol decay".

Replies (2)

@strypey@mastodon.nzoss.nz 2026-05-07 08:34

I'd be really interested in what @evan@cosocial.ca, @cwebber@social.coop and @darius@social.tinysubversions.com have to say about what @uriel@x.keinpfusch.net has to say here; https://x.keinpfusch.net/@uriel/statuses/01KR0M8Z007JNFHJ80QGS7DGJX

Open ##2346339
@smallcircles@social.coop 2026-05-07 10:10

@strypey@mastodon.nzoss.nz @uriel@x.keinpfusch.net The diagram in my last blog post on Grassroots fediverse evolution directly relates to it.. https://coding.social/blog/grassroots-evolution TLDR it is unclear where protocol ends, and solutions built on top of it start. Post-facto interoperability drives evolution: First implementer has full freedom to either make a good design or a hack for any AP extension. Hacks prevail, as the own app has the primary focus. Fediverse is app-centric. The next implementer can either follow suite, or reinvent, patching or mending, perhaps create a new flavor. You can say that the fediverse was vibe-coded by humans. In-the-large the participants in the ecosystem are involved in a huge Big Ball of Mud anti-pattern, where interoperability becomes ever harder and involving ever more whack-a-mole development and maintenance workload to assure by how each other app is able to break yours.

Open ##2346341