mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

373K
active users

Did you know? 💭

Favourite counts are nearly always wrong + different depending on what server you're on?

Here's the same post when viewed on four different instances.

It's not just favourites though!

Replies are nearly always wrong too.

Mastodon's strength should be that you can pick whatever server you want.

But currently, your server choice greatly affects the information that you see.

By the way, this isn't a case of servers being slow to catch up.

The post is from over a week ago.

Boost counts are also consistently wrong!

Let's look at another example.
We can see four completely different pieces of information.

And this post is from months ago!

It's not because of servers being 'behind'.

One server even has the whole instance banned, so you get even less information.

The banned instance is mastodon.social, which is the first one that users are referred to on joinmastodon.org/servers

Lu Wilson

Even if you use your own client, like @elk, you receive different information based on what server you're logged into.

@elk Why is it like this?

Back in 2019, @Gargron said it was a deliberate design decision.

Surely not?

(This comment refers to 'favourites' by the way. But the problem also affects boosts and replies.)

@elk @Gargron I've been trying to learn more about this problem, and I don't understand why it isn't a bigger deal.

The most recent discussion on it is from over 100 days ago.

Here's the issue by the way: github.com/mastodon/mastodon/i

@elk @Gargron I'm still trying to learn more about this problem, and I still don't understand why it isn't a bigger deal.

But what do you think though? Please let me know!
And if you know how to fix it, PLEASE let me know!!!!!

Boosts appreciated ❤️🐸

@elk @Gargron BONUS!

Guess which servers are showing these counts for this thread:

@TodePond Likes? I use them as a nod to the author, I don't care if they never went to other people.

I would like to see better boost counts, because on small servers you don't see how many people have boosted a post unless you open the post in new tab.

I understand why replies and boosts don't update, because ActivityPub is pub/sub model. If you don't follow a person, how would you get the boost count on your server?

They should add 'fetch' API if they wanted to get accurate boost counts.

@Ciantic I would like my client to fetch the correct favourite + boost counts for me. I end up manually 'fetching' the info by opening the original link anyway :)

@TodePond Yes that's right, it can be done in client side.

There are clients I believe that do it.

The bigger problem IMO is that you don't see all replies in other people's posts. It's the same thing, with pub/sub it doesn't send you replies when you click to open a thread, it only gives those that were sent to you by pub/sub... if you don't follow a person that's not tagged you don't see their replies as well.

@Ciantic I'd also love my client to retrieve those replies :D

@Ciantic @TodePond
Indeed, every instance seeing a different set of replies on a post is really not practical.

@karlo @Ciantic @TodePond By the nature of the Fediverse, different servers will always have different perspectives. But with likes Mastodon is deliberately making it even less consistent than it has to be.
@clacke likes do not exist as a feature in honk, so no problems here

@TodePond thanks for the thread! Definitely needs attention.

I think the problem is not straightforward to fix (but not impossible). The decentralized nature of mastodon makes it hard to have consistency since this requires a centralized mechanism to achieve, and people here are quite resistant to anything that resembles crawling/indexing

@TodePond the decentralized approach though, having contracts being checked constantly, like blockchain mining / authenticating transactions, is computationally intensive. And the ultimate question is who’s going to take the cost.

These are my thoughts on the problem. :)

@ayo Thanks! It would definitely be hard to do a 'clean fix', but at this point, I want a messy+imperfect fix that fetches automatically (instead of me having to 'manually fetch' each time by opening the original link of a post)

@TodePond @ayo I wonder if it would be enough if this was fixed client-side, i.e. having clients load the info about a post from its original server once a user opens the post details. 🤔

@TodePond @elk @Gargron This seems like a great opportunity to have a robust-first approach: get likes/replies/other roll-ups correct eventually, maybe through some sort of crawler that helps aggregate stats and then makes them available via an api.

@walpolea @elk @Gargron Yes! Eventual correctness is the key - and even then, being a little bit off would be fine :) And some slowness would also be absolutely fine!

@TodePond
I don't know the rationale for the design decision. But the reason is every server has only a limited visibility of the Fediverse - those that have Federated with due to a user's action. That is why there is an option to view a post on the original servers.
Akkoma, OTOH, dynamically pulls msgs from their orig servers. This should give correct count. You can try & confirm.
@elk @Gargron

@TodePond @elk @Gargron It's not a bigger deal because it's a problem with no workable solution. If you naively trust remote instances to report counts, they can lie to you, on the other hand if you simply start emitting like activities:
- you're now betraying the expectations of users who believed those to be private
- this still doesn't make the numbers consistent

@TodePond @elk @Gargron I'd say the real problem here is that users do not understand what it means for the fediverse to be federated.

@niya @elk @Gargron Hey I would very much like my likes to be "public" if that's what you mean? :) You should be allowed to keep your likes private if that's what you want. User choice is great! ♥️

The like counts don't need to be perfect, but it would be great to make them more accurate than they currently are ♥️

@TodePond @niya @elk @Gargron A private like would be a Bookmark in Mastodon, no? Or would you like to be able to like something in a way that is only public to the author of the post? Given that likes are already semi-public, and adding yet another concept seems quite complex maybe the private usage could be covered by bookmarking and DMs?

@patak @niya @elk @Gargron Yes true! To be honest I'm a bit confused about people wanting their likes to be private. I always assumed that it's a public action :)

@patak @TodePond @elk @Gargron From my pov, I just use likes as an acknowledgement directed at the author of the post itself, so bookmarks aren't necessarily a 1:1 replacement, and I'd certainly like to be able to do this in a private way. In principle likes could have visibility levels like posts (since they're federated in activities just like posts), but I do wonder if that sort of option might just confuse users

@patak @TodePond @elk @Gargron I'd have to refresh my memory on what the specified semantic for likes is based on addressing, because I'm honestly not sure how fine-grained it can realistically be, but I wouldn't be at all against people having a toggle option to be able to change whether their likes are sent to their followers' inboxes in any case!

@niya @patak @elk @Gargron Currently, our likes are public to some servers and private to others, in a way that's not clearly explained or apparent. To most users, it will seem random. And it's something we have no control over.

I think it would be great to have more consistency on this :)

@TodePond @elk @Gargron This disproportionately affects those who are on tiny instances. My server only has 2 or 3 users, so every single post I see has zero favorites (or 1 if I'm favorited it). I have a second class experience because I chose to run my own instance just for me and mine. Seems like since Mastodon.social has the most users, it would have the most correct view of likes and such, and such is the "most first class" mastodon server. This mismatch incentivizes centralization.

@rezonant @elk @Gargron Thanks for putting it so clearly 👏

@rezonant @TodePond @elk @Gargron can confirm, but likes and boosts aren't really important to me, I judge toots based on the content.

The annoying things are missing replies and incorrect poll results.

@rezonant @TodePond @elk @Gargron I also feel like this sometimes because I use my own instance. However, I mostly stopped caring about counts at all and wouldn't mind if it is removed from interfaces.

@pim @rezonant @elk @Gargron We can do better! :)
We should be able to choose to receive accurate information.
And we should be able to choose to not retrieve that information at all.

@pim @TodePond @elk @Gargron It should be an option, not forced on me, as I *do* want to see like counts.

@TodePond @Gargron @elk Replies and likes are very different.

Replies don't reach you because nobody on your server follows the person who is replying.

Likes don't reach you because Mastodon deliberately doesn't send them to anyone except the server of the liked post. I only learned about this surprising behavior recently.

None of the other fedi implementations I've checked behave like this. I've checked GNU Social, Friendica, Pleroma and Misskey. They treat likes as normal posts and distribute them to the liking person's followers.

@TodePond @elk yep, the clients only fetch information from the instance of the user.

A reason for that is privacy, as you only have to connect to one server.

Another reason I can think of is, that you don't know if other instances speak the mastodon client protocol.

@joshix @elk I want my client to fetch all of the correct information from the original site

@joshix @elk that seems to be about populating a user's page, not retrieving replies/boosts/favourites, unless I'm misunderstanding?

@TodePond @elk oh, yes. But I think it's the same problem: missing data that the instance of the client doesn't have access to

@joshix @elk That's a real shame then. More and more I'm just tempted to make a browser extension that does it for me personally. But a widespread solution would be better

@TodePond @elk i think trying to add it to an existing client would be the better solution. Then you could see how difficult it really is and contribute your solution directly to the client