you can get a lot of the squeeze of a centralized reddit-style service (in terms of low-friction user signup) without needing actual content federation. One ID can still let you post on multiple boards without needing to sign up in 27 places, and that doesn't need content federation.
It also significantly reduces the moderation problem because now you are letting {Google,Facebook,Apple} solve (or at least gate/significantly reduce) the spammers problem for you. That said, custom IDPs are inherently at odds with this value in spam filtering. If a spammer just needs to set up a custom domain, you don't get any signal as to user quality.
When it works it's magic and when broken might as well give up. A backup can always save you depending on the timestamp.
The only hitch is that one has to trust Apple as the key manager. Everyone that can get past that hurdle will be able to manage very sophisticated trust relationships.
Let's use Lemmy as an example. The current UI makes it clear at all times where the communities and the users are located. It's nice to provide such information, but in the end it should not matter, and thus it should not be wasting premium UI space. Same thing goes with the community list: the "subscribed" section works as expected, but "local" should never be the default view, because in the end, users shouldn't have to care where communities are hosted. Finally, the search feature should be much more explicit in describing the corpus of data being searched: "all known communities", "communities federated into this instance", "local communities". All new users think it's #1, but #1 doesn't exist, it's #2, and this leads these users to think they have to be on one of the big instances if they want to participate in a larger community.
It's almost like federation was an afterthought.
Of course it does, because otherwise you are dealing with a patchwork of different entities operating parts of the federated system. Those entities are most likely operating with different standards and different levels of professionalism. In the end, you are offloading tasks to the end users like figuring out the structure of it all, where to sign up, which instances to join, how to get access to the content you are looking for, what to do when things inevitably break. In a centralised system, most of these questions don't exist, and everything else is being taken care of by the operator who has a vested interest in things running as smoothly as possible.
What you are describing are mostly UI problems, but even if those had been solved, it would still a worse experience. The average user doesn't even know what "federated" means, the don't want to be thinking about local and remote instances, they just want things to work.
Indeed. This is why convenience means moving all things 'federation' to the background.
Remember eDonkey, eMule, and the ED2K network? It started as a federated network, and it added a second decentralized network later on. And it was successful, because users didn't have to care about the inner workings of the product. There were a bunch of external sites acting as link aggregators, but there was a builtin search feature too that worked well (until hash collisions catched up with the stagnant protocol).
To me, this is still a shining example of how to do federation right. There were multiple clients, standard communication protocols, and it was easy to take advantage of the full federated network, because it didn't take any effort to do so.
Just like Reddit.
Not quite the same thing.