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.
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.
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 https://joinmastodon.org/servers
Even if you use your own client, like @elk, you receive different information based on what server you're logged into.
@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: https://github.com/mastodon/mastodon/issues/11339
@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
@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)
@stefandesu @ayo that would be great!
@ayo @TodePond I wonder why this same idea wouldn't work for other numbers... https://github.com/mastodon/mastodon/pull/4840
If follower/follows numbers are fetching correctly, why not fetch all the amounts? I don't get it.
@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 found another fitting issue
https://github.com/mastodon/mastodon/issues/21571
@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
@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 @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!
@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.
@TodePond @elk
The reasons why Tusky (mastodon client) does not have this feature:
https://github.com/tuskyapp/Tusky/issues/2539