The core phrase of the blog post: “no one has done an especially good job explaining why the fediverse is better than centralized solutions”.
Feels to me that it’s all growing pains, we WOULD benefit for a federated auth system instead of an account on every service, and we need lots of bug fixing, i just wish all these social media shitstorms had happened a couple years later and not at this point…
‘Better’ is relative. To me its better because no one person or group owns or controls the software. There’s no central authority. Don’t like the instance you’re on? Just move to another. Cant find an instance you like? Host your own. Don’t like the path the developers are taking? Fork the code. As long as the very core remains standard (ActivityPub), all possibilities are on.
There needs to be a return to being patient. Most fedi software is not beyond beta yet. They will develop and they will mature but right now the fediverse is a toddler learning to walk. There are issues but with time they’ll get addressed. We’ve all got so addicted to shiny cool apps and services we’ve become prepared to sacrifice our privacy, our choices and our reason at the altar of a quick dopamine hit.
There’s no big money to throw at these issues and therefore no dedicated team. This means solutions come slower. But they will come and they will be motivated by usefulness not profit. The people developing these things have lives and day jobs. Give them time.
no one has done an especially good job explaining why the fediverse is better than centralized solutions
The default example people use for “a federated service” shouldn’t be Mastodon or Lemmy.
It should be email.
Why is it better that different companies, universities, and other organizations (and even hobbyists) can all set up their own email servers, rather than everyone just using (say) Hotmail?
- If Hotmail does something you don’t like, you can switch to Gmail or AOL instead, and you can still send emails to your friends on Hotmail.
- Different providers can specialize in different things, while remaining compatible. Maybe one provider doesn’t prioritize the features you need; but they can’t prevent a competing one from offering them.
- No one provider can impose censorship or other overextended control onto the whole system. No one provider can break the whole system when it has an outage: Hotmail going down does not prevent Gmail’s servers from exchanging messages with the University of Tübingen’s servers.
- Different servers can operate in different parts of the world, under different legal systems. Not everyone is ruled by California or Washington state; or the US. A hobbyist operating an email server in Alabama is not required to comply with Dutch or EU law, and a hobbyist operating an email server in Amsterdam is not required to comply with Alabama or US law. People get to live under the law of their own country; and yet the Alabama mail server and the Amsterdam one can talk to each other.
- The same infrastructure that supports federation also supports extension of the platform. Programmers can build services on top of email, and the medium is transparent to them. And, again, no one provider can tell them “no, you may not build that weird client program, bot, or mailing-list service.” To be honest, you don’t even get Hotmail if email is born as a centralized service. The whole emergence of webmail services could only happen because email is extensible and federated.
The primary benefit to federated services as I see it is that you can have a network of groups, all with their own policies on moderation and who they federate with. Some corners of the Fediverse block other corners of the Fediverse, but each corner has their own policies on what they block. It’s more democratized that way, and if you disagree with one instance’s moderation policies you can move to another while still interacting with the same communities. Alternatively, maybe you prefer a different interface or way of managing your online presence! There’s any number of reasons you would want to use a federated service.
It makes sense that someone who runs their own centralized service wouldn’t see the need for a federated service, because they can run their centralized service the way they want and don’t have to worry about whether the staff of their chosen service agree with them, because as operator they hold sway over that.
One of the other benefits of an open protocol like ActivityPub is that people can hook into it in the future. For example, Pixelfed may be the only software solution in its class at the moment, but if someone wanted they could make their own independent version and it could be interoperable if they used ActivityPub plus the same conventions that Pixelfed does. Sure a platform could always create their own open protocol, but better to use an established open protocol instead of reinventing the wheel for every new service. That’s even setting aside the possibility the some service will come along to unite all of the Fediverse under one app (Kbin is trying something like this I think).
Also they’re totally wrong about the Kbin situation. Kbin is 100% compatible with Lemmy, if a little glitchy at times (early days, after all). It’s only the main instance that’s not federating, and that’s because they are using Cloudflare to deal with the surge in popularity from Reddit. Under normal circumstances even the main instance can federate.
