If your idea of a federated Twitter is a bunch of mini-Twitters that sometimes exchange indirect replies or something, then the Fediverse fulfills that purpose completely. Mission accomplished, we can all go home now.
If your idea is that the replies to every post look the same to any user, anywhere, at any time, even the thing Mastodon merged half a year ago that supposedly fetches all replies if you remember to navigate to the topmost post, and wait up to 15 minutes for your view of the thread to coalesce, falls short.
And this is why hosting Mastodon is cheap, it fundamentally cannot provide the functionality BlueSky offers. Of course, you might think that such functionality is not desirable anyway, and that’s entirely fair. But if you’re looking for the immediacy that centralized Twitter gave users, I don’t see a way for Fedi to ever provide that, whereas there is a path to BlueSky decentralization. It’s a fact that your UX is diminished if all of your followers and followeds are not on the same instance.
If your idea is that the replies to every post look the same to any user, anywhere, at any time
This is only true of Bluesky because everyone is using Bluesky’s infrastructure at the moment. If Bluesky ever deindexes someone and they start posting to an alternative relay, you suddenly don’t have a guarantee of a full view of a post’s replies.
Content addressing means you can make your instance pull from both their relay and the bluesky relay and trivially merge threads and views without consistency issues, so that’s solvable.
The bigger issue is all those other regular users who doesn’t, and still get confused (unless they manage to pick a client app that does it for them)
I mean, this would become less trivial the more replays go into use, where to get a full view you’d have to pull from all the relays that exist.
ActivityPub’s solution to this is just IMO better, the original post has a replies collection attached to it that acts as the authority the replies the post has. This also allows creators to eject replies from the collection. There are issues with the way fedi software currently handles fetching from these reply collections, but the missing replies thing is very solvable in ActivityPub.
Doing it this way is why small instances gets hammered when a user’s post goes viral.
And as for moderation bluesky also carries information with the top post from the post author and allows hiding replies too, etc. This gets enforced on the appview side, so the posting user’s PDS is unscathed if it goes viral.
Bluesky is built to assume a handful of big relay (remember that a relay can merge in contents of another) and a bunch of appview and a ton of PDS servers, feed generators, moderation labelers, etc.
Realistically, the relay network will likely end up voluntarily adopting a tree topology - hobbyist communities would run small relays bundling all activity from members’ PDS servers, then a larger relay in front gathers everything from a ton of smaller relays and makes it available to appviews
Doing it this way is why small instances gets hammered when a user’s post goes viral.
Setting up caching in the reverse proxy layer would alleviate this a lot of this. Like, GoToSocial only recommends to set up caching for the key and webfinger endpoints, where having it set up to cache posts and profiles for like 60 seconds (or however long the Cache-Control header says, Mastodon defaults to 180s) would alleviate the strain on the server so much.
There are other thing you can do, like this post explains some other things for Misskey, but the defaults should be sensible so you don’t have to be a sysadmin expert to host an instance and they’re currently not. I host 2 Lemmy instances (ukfli.uk and sappho.social) from a £5/month VPS and they’re able to handle bursts of hundreds of requests without issue.
Bluesky is built to assume a handful of big relay (remember that a relay can merge in contents of another) and a bunch of appview and a ton of PDS servers, feed generators, moderation labelers, etc.
People are already building small, non-archival relays so this assumption seems mute. It’s also important to remember that relays are an optimisation, not a core part of the protocol.
If your idea of a federated Twitter is a bunch of mini-Twitters that sometimes exchange indirect replies or something, then the Fediverse fulfills that purpose completely. Mission accomplished, we can all go home now.
If your idea is that the replies to every post look the same to any user, anywhere, at any time, even the thing Mastodon merged half a year ago that supposedly fetches all replies if you remember to navigate to the topmost post, and wait up to 15 minutes for your view of the thread to coalesce, falls short.
And this is why hosting Mastodon is cheap, it fundamentally cannot provide the functionality BlueSky offers. Of course, you might think that such functionality is not desirable anyway, and that’s entirely fair. But if you’re looking for the immediacy that centralized Twitter gave users, I don’t see a way for Fedi to ever provide that, whereas there is a path to BlueSky decentralization. It’s a fact that your UX is diminished if all of your followers and followeds are not on the same instance.
But in the end, I think there is space for both.
This is only true of Bluesky because everyone is using Bluesky’s infrastructure at the moment. If Bluesky ever deindexes someone and they start posting to an alternative relay, you suddenly don’t have a guarantee of a full view of a post’s replies.
Content addressing means you can make your instance pull from both their relay and the bluesky relay and trivially merge threads and views without consistency issues, so that’s solvable.
The bigger issue is all those other regular users who doesn’t, and still get confused (unless they manage to pick a client app that does it for them)
I mean, this would become less trivial the more replays go into use, where to get a full view you’d have to pull from all the relays that exist.
ActivityPub’s solution to this is just IMO better, the original post has a replies collection attached to it that acts as the authority the replies the post has. This also allows creators to eject replies from the collection. There are issues with the way fedi software currently handles fetching from these reply collections, but the missing replies thing is very solvable in ActivityPub.
Doing it this way is why small instances gets hammered when a user’s post goes viral.
And as for moderation bluesky also carries information with the top post from the post author and allows hiding replies too, etc. This gets enforced on the appview side, so the posting user’s PDS is unscathed if it goes viral.
Bluesky is built to assume a handful of big relay (remember that a relay can merge in contents of another) and a bunch of appview and a ton of PDS servers, feed generators, moderation labelers, etc.
Realistically, the relay network will likely end up voluntarily adopting a tree topology - hobbyist communities would run small relays bundling all activity from members’ PDS servers, then a larger relay in front gathers everything from a ton of smaller relays and makes it available to appviews
Setting up caching in the reverse proxy layer would alleviate this a lot of this. Like, GoToSocial only recommends to set up caching for the key and webfinger endpoints, where having it set up to cache posts and profiles for like 60 seconds (or however long the
Cache-Controlheader says, Mastodon defaults to 180s) would alleviate the strain on the server so much.There are other thing you can do, like this post explains some other things for Misskey, but the defaults should be sensible so you don’t have to be a sysadmin expert to host an instance and they’re currently not. I host 2 Lemmy instances (ukfli.uk and sappho.social) from a £5/month VPS and they’re able to handle bursts of hundreds of requests without issue.
People are already building small, non-archival relays so this assumption seems mute. It’s also important to remember that relays are an optimisation, not a core part of the protocol.