Ferkv
* If you choose reddit you are choosing reddit's server.
* If you choose ycombinator, you are choosing ycombinator's server.
* If you choose facebook, you are choosing facebook's server.
Just because those are not federated doesn't mean the user doesn't have to deal with the bullshit of having to choose to create and manage an account in one (or more) of them. Or possibly having to look for other alternatives (like many are doing now apparently).
You can just enter lemmy.ml or mastodon.social in the browser, press "create an account" in each of them and you'd never even need to know or care whether those federate among themselves or not.
Federation is optional from a user perspective. You could still have separate accounts in beehaw.org, mastodon.org.uk, veganism.social and mastodon.social if you wanted. You are not forced to look for content outside your instance. The same as you can have an account in reddit, another one in facebook and another one in ycombinator without ever mixing them up.
The difference is that in the fediverse you can merge them if you want to. Even if all new users exclusively used mastodon.social resulting in more de-facto centralization, I still don't think that's a big deal, personally. Just the fact that federation is possible at all as an option still provides more software freedom than Twitter, even if you don't care for federation or even know what it is.
Do you think that email being federated makes it less attractive for the average user? do they find it more complicated? ...I don't think the average user cares at all, all they know is they have a gmail or hotmail account.
I mean, isn't any instance in the federation already offering a proxied cache of the content of all other instances you access through it?
You can just register/login in mastodon.social website the same way you can register/login in Twitter, and then access cached copies of content from the entire fediverse compatible with Mastodon.
If they are still allowing access to all forms of third party content through their own instance (even if they restrict the discoverability) then they are still risking being held responsible for that content. So imho, that would be a mistake.
Personally, if I were to host my own instance under such a protocol, I'd rather NOT allow any potentially illegal content that might come from an instance I don't trust to be distributed/hosted by my node.
The problem, imho, is in the way the content needs to be cached/proxied through the node of the user in order for the user to be able to consume it. This an issue in the design of how federation typically works.
I'd rather favor a more decentralized approach that uses standards to ensure a user identity can carry over across different nodes of content providers, whether those nodes directly federate among themselves or not.
There should be a separation between identity providers and content providers, in such a way that identity providers cannot be held responsible for what the content providers offer, and content providers can take care of moderation without necessarily having to worry about content from other content providers with maybe different moderation standards.
I'm not saying ATProto is that solution yet... but from what I've read it at least tries to come close.
I'd rather favor a more decentralized structure that allows the users to directly access content from any content provider that hosts it through the protocol (ie. without necessarily requiring another specific instance to index that content from their side.. if they index it great, but if they don't it should still be possible to access it using the same user account from a different index), with a common protocol that allows a separation between identity management and content provider.
From what I understood, ATProto is closer to that concept.
Which is why a new competing protocol is a good way to push for change.
You want Microsoft to become more open? Then start promoting Linux.
That's actually one of the things that bugs me about ActivityPub... unless I'm running my own one-single-user instance I won't have control over my own identity.
It's also very weird how even on a supposedly "federated" system the only way to ensure you can access content from all instances (even if they differ in philosophy or are on opposite sides of some "inter-instance-war") is to have separate accounts for each side... it kind of defeats the point of federation. There's even places like lemmy which instead of using blocklists use allowlists, so they will only federate with pre-approved instances.
"vi" being so common (ie. "lingua franca") is what gave it an advantage.
I took it to mean "so common that it's available almost anywhere" (which is consistent with the context of the comment).
I've found it extremely useful to rely in tools such as the ones you just listed. Specially because they are often present even in light vms were perl might not.