Edit: After reading your comments, and testing some more, I must say that I’ve misunderstood how it all works.
I should’ve thought of Mastodon users like separate Lemmy communities…but not exactly. What confused me is the fact that you could look up a profile on a remote instance and see their posts, but they would be very delayed. On Lemmy, if your instance hasn’t “discovered” a community, you wouldn’t see it at all.
I followed a random user (whos posts were last synced many days ago), and it started syncing normally (it took ~1h for it to start, but it seems like it worked and now it’s syncing their posts “in real time”).
By accident I noticed that one instance had more japanese posts in the all feed than the other one. I thought maybe the other instance has certain languages filtered or they might be defederated from certain instances, but neither was the case. I found out that the other instance just fetches the posts from other instances much slower (days).
Then I decided to open 10+ (popular to fairly popular) instances and compare how quickly or slowly they sync with each other.
It’s really bad and really random. Some instances sync perfectly with each other, some take hours, some take days, some take months…
I do not use Mastodon but if I did, finding that out would just make me not want to use it.
It reminds me of that time when there was a bug in Lemmy which made the federation broken, and that was very annoying, but we knew that there was a bug and that it was being worked on, and it was fixed fairly quickly.
But on Mastodon, from what I’ve seen, it doesn’t even depend on the version the server is running, it truly just seems random.
It just seems odd to me that Mastodon (more popular and older software than Lemmy) would have such a glaring issue.
Wouldn’t that be the first priority of every federated platform? For federation to work properly, because if it doesn’t, then it can’t compete with the centralized ones at all.
Hi OP ! I’m writing a bit late to tell you could do your federation test using this !testfediverse@jlai.lu community. Enjoy :)
I’m not sure what it is you’re comparing. Instances don’t “sync” with each other. It’s all based on the follow graph of the individual users of each instance. So yes, sometimes a post from one instance won’t show up until days later on another because it just so happens that post may have been interacted with by some other user and only now it shows up on the instance.
FWIW, I operate multiple Mastodon accounts across multiple instances, and I’ve had no problem with seeing posts show up right away across instances.
To make this simple:
Lemmy: One user follows a community from another server, content federates from all users commenting and posting. It takes one follow to start that flow.
Mastadon: One user follows another, content federates for that one user. It takes a lot of follows to get significant content movement.
In addotion, it is much more likely that out of 10 servers, the same communities are followed vs the same people.
The federarion on mastodon is dodgy cos they dont have a central object to federate to/subscribe to like we have in the form of a community. Hence they have all sorts of weird issues of things only federating to instances that are involved in the operation or some shit i cant remeber exactly. End of the day federation favours large instances and suppresses smaller instances. I believe mastodon devs have said this isnt a bug and is intended as as such wont be fixed.
Whats that python flask based lemmy server i would like to take a look at seeing how hard it would be to implement mastodon routes into that and fix the issues.
Getting full Mastodon interop in PieFed is going to be a long road. I urge you to bite off a smaller piece to chew until you get comfortable - https://join.piefed.social
I don’t understand… is that just lemmy but not built by tankies?
Yes it primarily federates with Lemmy and Mbin so it has all the same content. See https://join.PieFed.social/features for a comparison.
People who get downvoted a lot end up with a ‘low reputation’ indicator next to their name. You’ll know it when you see it.
Hmmm, is that supposed to be karma?
Yeah there are multiple ignored GitHub issues about Mastodon’s federation of replies, going back many years. It’s never getting fixed. This realisation sent me on a multi-week quest to find a platform that does replies properly. Akkoma and Friendica seem better at replies but have other shortcomings.
It cannot be “fixed” unless you centralize into a single firehose like Xitter and Bluesky.
Those of us running smaller instances can choose to use relays and fetcher-tasks - and there is a PR to put one such fetcher into Mastodon - but if the goal is 100% of everybody always sees 100% of the content then no decentralized solution will ever offer that.
It can be, it just involves contacting the site that hosts the top-level post and having it forward the replies itself. It’d be a change to the distribution model, and not a simple one, but can absolutely be done.
That’s just replies to a post. It doesn’t solve not all posts reaching everybody.
I wouldn’t be quite so pessimistic. There’s a commit for #FetchAllReplies (by @jonny@neuromatch.social, I believe) that seems to be shaping up well, with a seemingly healthy debate going on. Just yesterday @Gargron@mastodon.social posted in agreement that it is a must-fix issue.
They’re moving slow, but their reasons for doing so doesn’t seem to boil down to an unwillingness to fix it.
Excellent news!
Servers not having the same content in their “all” feeds is not a bug, it’s by design. The design philosophy for Mastodon (and I’d say the fediverse as a whole) is to let the users curate their own feeds instead of showing them everything or algorithmically guessing what they might be interested in. Servers will only receive posts from accounts that at least one of this server’s accounts is subscribed to. Having every post federate to every server even if nobody there is interested in those posts would be a waste of resources.
Yes, that makes discovery of new content significantly harder but that’s the tradeoff for being able to host your own small instance without the need for a super powerful server. I can run my instance that serves just a couple of users on a 10-year-old server that runs a dozen other things at the same time. We see the stuff we’re interested in and don’t have to spend disk space, processing power and network bandwidth on content none of us will ever read and neither do we have to spend those resources on sending our posts to other instances where nobody will read them.
The ‘All’ feed really needs to be renamed, because, yeah, it’s not ‘All’, and it will never, ever be ‘All’, as no one AP-based website knows about the existence of any other without someone manually initiating contact between them.
There is no ‘All’. There is only 'Remote content someone locally has sought out and subscribed to". Projects gotta find a more appropriate term for it.
It’s “all” in the sense that it’s everything the instance knows about, in contrast to “this server” which is only content from users that are registered on this specific instance. Same concept as the “all” and “local” feeds on lemmy. I agree that a better name might reduce the confusion but I can’t think of a good one.
You’ve misidentified how a decentralized, federated network of content sharing works. Like many, many people, you seem to have conceptualized it as a hub-and-spoke model, with a centralized data store and remote terminals.
But it’s actually a subscription-based mesh network, where each update is only sent to places that have specifically requested it. Importantly, at the moment at least, things are not forwarded along to other servers due to secondary contact. If someone on my site (A) subscribes to you (B), and someone on a third website © comments on something you posted, if nobody on my website subscribes to C, C does not send that comment to my website, and your website does not forward it along, either.
There’s some buzz about forwarding replies and stuff like that possibly getting worked out. But even then, being on the fediverse means making peace with the idea that there’s no single source of truth for the whole network. You won’t see it all, ever. And it’s likely, and possibly even desirable, that the network splinters into loosely connected islands. But that can’t happen if what people keep demanding is a centralized service with a single benevolent dictator. And the single dictator will stop being benevolent at some point.
They always do.
- did you have a chance to test with any GoToSocial or snac2 based instances?
- there’s also moderation issues – a lot of people leaving Xitter are ending up on Bluesky because it has better moderation and onboarding
Bluesky has basically no moderation. What it has is really good user level blocking and the ability to share those block lists with others.
What’s different about the fediverse? There’s mute lists, block lists, keyword filters, they have a third party company plus a trust and safety team. They’ve taken down plenty of accounts. So again what’s no moderation? What’s better moderation and tooling on fedi? I’ve seen CSAM on Mastodon yet not on Bluesky
What’s different about the fediverse is that I can pick an instance and know that the admins who run it will ban bigots, rather than just leaving the bigots alone, and telling me to ignore them.
That’s a pretty important distinction to me.
Yeah, block list sharing is something that has to come to the fediverse, and it needs to be platform agnostic.
I’m curious what you mean by “better moderation”? Are you comparing to specific instances? Or do you mean consistency, because it’s more centralized?
user level moderation: blocking, muting, and filtering – and block lists, mute lists, and filter lists can all be shared and subscribed and updated
User-level moderation isn’t moderation. It’s a downloading of responsibilities onto the user, but it’s not moderation. It’s the opposite of moderation.
