You know I'm a committed user of the fediverse, perhaps this post will surprise
you. Still, at some point the truth has to be told, before lying leads to a
catastrophe.
I think I've been present in the fediverse (sometimes hosting a pod of some
software and sometimes not) since
Hard to say. The data model has certain limitations that make it difficult to be used for more advanced things and it is structured in a way that seems to encourage nosql style document databases and has a sort of viral influence on the development of new apps.†
However, it can get the job done with enough brute force – though if you are doing anything other than microblogging MastoPub apps likely won’t work with it even if you are AP compliant.
No, the W3C process is such that the committee is closed and only addon specs can be ratified by the Community Group. I don’t remember any specific decisions but I remember at least a few occasions where everyone voted and there was a clear majority but the masto devs threw a tantrum and threatened to take their ball and go home. The results were mixed. Sometimes it simply went unspecified to “keep the peace” and others the majority was just flat out ignored and the opposite was put in spec. Excuses were always made and had me feeling like the whole voting process was a sham.
Not increasingly. It has always been that way. They don’t federate with non-mastopub platforms and the platforms that aren’t microblogs have had to limit their features to be MastoPub compatible.
The ones that have continue to do so and I still believe it’s the best (only) way.
@rysiek@szmer.info says that such a strategy results in apps that can talk with friendica or hubzilla but not each other, but I say that’s the situation we still have, where advanced apps can talk to each other but not Mastodon.
There will always be fragmentation. If that fragmentation falls on the majority (Mastodon) being inconvenienced I think that is a better result than the freedom fighters and innovators being sabotaged and having no options at all.
– ** –
† Here I am referring to the problem when developing a new app where if you plan to support AP first and foremost, it is easiest to structure your whole app and data model around AP, and then you are kind of stuck in that mindset permanently. Whereas if you develop your app with an open mind, then go back and add AP support you won’t cripple yourself.
Edit: I just remembered a couple examples (sort of). One was there was talk of a discovery mechanism that didn’t depend on webfinger, but Mastodon rejected it because they wanted to maintain backwards compatibility with gnu social (so they could bootstrap their userbase that gave them their influence).
Another was they almost didn’t include sharedInbox in the spec because Mastodon didn’t want to use it and thought it was stupid or evil or something. Luckily it still made it in but the compromise was that it was optional, putting extra burden on all other servers to support sending separate copies to every single user’s inbox.
Thank you for the very detailed answer!
I’m not sure if it’s the same thing, but I recall a Gab developer justifying their removal of federation in 2019, one of the reasons being that malicious actors were spinning up fake instances with thousands of users to make a server send separate copies of a message to every single user’s inbox, slowing the site down. Would shared inboxes help to prevent this type of attack, or is it something else?
Indeed. Making sharedinbox a requirement would mean that a server could simply refuse to do it the other way and then be immune from that attack. But because it is optional, all servers must then be vulnerable to this attack.
It can be mitigated by batching, and delivering say only 5 copies to one server at a time, but that would have to be very carefully crafted to not cause queue backup for other messages.
The ultimate workaround is queueless delivery, but there will still always be some penalty of having to keep revisiting a particular server.
A malicious actor can also deliberately slowly respond to deliveries, forcing the sending server to keep many sockets open.
Thank you for all the context! Fully agreed on basically everything, esp. that there’s always going to be some fragmentation. Still happy that we were able to limit that substantially. 🙂
Some more context I just remembered (funny how things come in waves):
Notice that I always say Mastodon devs and don’t name particular people. Part of that is out of respect and to keep it from seeming personal, but another important thing is that there were several Mastodon devs involved in the committee.
So when I say that there was a clear majority that means several Mastodon devs had a vote and they still lost.
But what happens in committee is people are allowed to argue for or against motions. At times, there would only be one person willing to argue on one side while several Mastodon devs would argue on the other.
So even if there was a majority vote numerically, there was a larger perceived dissent that would prevent motions from passing.
One chair was more affected by this than the other but again out of respect I won’t say which.
This is important to understanding why standards committees sometimes have undesirable outcomes. It’s also one of the reasons why sometimes groups committee shop and prefer W3C or IEEE or any of the others.
Standards committees is actually one of
humanity’ssociety’s biggest unsolved problems. 🙃