Mastodon: Accurate Follower/Following Count in Web

[Auditoryproliferation]

While browsing I was surprised as to how almost all users didn't have more than a few followers. I was confused, but only now did I click on a person appearing in the web to have zero followers/following, and saw on the global public webpage the numbers that seemed more appropriate. Why does this happen? Wish I knew how to report this in a more technical way!

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• [N/A] This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[Gargron]

Origin server has full info, your server only has local info (= it can confirm)

[spinda]

The UI could be clearer here. A visible "on this instance" label somewhere, maybe?

[nightpool]

I think this is actually a useful feature—it allows me to see the people
from my instance who follow or are followed by the user. I use it a lot for
that purpose.

On Thu, May 25, 2017 at 4:47 PM Michael Smith [e-mail]
wrote:

The UI could be clearer here. A visible "on this instance" label
somewhere, maybe?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/3307#issuecomment-304119159,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV5wEvhXt_nPXHA6iHu80Rl0O3NHyks5r9ehOgaJpZM4NmZgx
.

[Gargron]

A visible "on this instance" label somewhere, maybe?

There is actually an asterisk next to the numbers, with a tooltip that says exactly that. I don't know how to make it any clearer - suggestions?

[nightpool]

@gargron Maybe renaming the columns "Local Followers" "Local Following"
when it's a remote account?

On Thu, May 25, 2017 at 5:51 PM Eugen Rochko [e-mail]
wrote:

A visible "on this instance" label somewhere, maybe?

There is actually an asterisk next to the numbers, with a tooltip that
says exactly that. I don't know how to make it any clearer - suggestions?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/3307#issuecomment-304134659,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV-X4GdgLUArsXny_crks1R5bdrGqks5r9ff8gaJpZM4NmZgx
.

[ghost]

The asterisks are pretty tiny. Maybe add a line above or below the numbers that says something like "locally known data only" (except better worded ^_^;)

The same thing goes for hashtag searches btw. The local instance's idea of what toots used a particular tag can be very different from other instances'. This is obvious for people who are familiar with how Mastodon and federation work, but I think it isn't for most regular users, and certainly not for most newcomers.

[averageunicorn]

Ah, I always wondered what the asterisks meant! I figured out that the followers were just the local ones, but not because of the asterisks. I never hovered above them long enough for tooltips to appear, because they looked clickable to me and not like something I should hover, but clicking just opens the follower/following list of course. So, imo something more visible would make sense.

[deutrino]

I'm tempted to suggest removing the public numbers entirely as a way of solving this and also reducing unfortunate user behavior related to public follower counts, but that's been (briefly) addressed and rejected in #1660.

Bad data is worse than no data. Bad data plus asterisks (which don't show up in clients) is not a good solution.

A couple ideas:

• Block on displaying the counts (on web and api) until the server has updated them (subject to reasonable caching and timeouts). Pros: accurate counts. Cons: whoever is unlucky enough to request the counts when cache is stale has the unhappy choice of slow loading or stale data depending on how this is implemented; small instances will have the unhappy choice more frequently due to their cache being more sparse.
• Put a throbber over the area and populate the counts as they become available with a client side javascript call. Pros: accurate counts. Cons: complexity; more round trips over the network; client-side calls don't update the server's cache if they go to the remote instance (which they could!); doesn't work for API clients.

I vastly prefer a delay to bad data, and I think a happy medium can be approached by speculative caching. I also think this is an issue which might group well with backloading of toots (see also #1037).

Suggested approach:

1. Update counts from the remote user's instance when a local user overtly displays interest (by requesting a profile, a toot, or by following) and also when likelihood of local user interest is signaled (by receipt of a toot, follow, or profile request from a remote user).
2. Cache the counts every time they are updated from remote.
3. Cached counts should carry an expiration time, I would suggest a day or two. Bad data is worse than slow data or no data.
4. Send fresh cached counts immediately upon request. If cached counts are nonexistent or expired, block for a short time (500ms?) while attempting to fetch them.
5. If counts can't be fetched within the timeout, display the profile in a way that makes as clear as possible that counts are not available. On the web UI this could be explicit (a question mark or small icon). For the API, compatibility may dictate displaying zero, which the user will likely interpret as being inaccurate, which it is.
6. If counts can't be fetched within the timeout, they still must be updated in the background!

I think the piece of this logic which will make accurate follow counts function most smoothly is the heuristic which says, if a remote user touches or is touched by the local instance in any way, it's likely that local users will be interested in that remote user, so make an effort to keep things up to date and thus avoid fetch delays.

Impacts on server load and the fediverse:

• an increase in jobs to fetch counts (blocking or nonblocking, there will be more jobs)
• an increase in network traffic, both fetching and responding to fetch requests
• an increase in server load due to a cache expiry check on most actions which involve a remote user (eg profile request, receiving or sending a follow, etc, see above). I don't believe this will be large increase in load - it certainly doesn't have to be.
• an increase in load on all instances due to responding to fetch requests

I believe a reasonable cache expiration period is key to balancing good UX with server and federation load. 1-2 days seems to me like a good balance.

It's also conceivable that code developed to handle this can be leveraged for backloading of toots (#1037, others).

[nightpool]

this was fixed by https://github.com/tootsuite/mastodon/pull/4840