YSK: Subscriber count on communities only show the numbers of users subscribed from your specific instance. The real number might be much larger than you think.
YSK: Subscriber count on communities only show the numbers of users subscribed from your specific instance. The real number might be much larger than you think.
You can use https://lemmyverse.net/ to check actual subscriber numbers.
You're viewing a single thread.
What's the reason to show local counts anyways? Is there more to it than a "because we can, and it was easy to implement"?
I'm curious if there are any reasons which I don't see, and doubtful they outweigh the caused unclarity.
Most people only care about total numbers, I suppose.
I'd say that's pretty much it—querying the database locally for subscriber counts was probably a very simple feature to add, at least versus collating totals from other instances (perhaps would need more data sending over activitypub to facilitate it)
That and it helps pick communities to subscribe to, so there's value enough in the local count to be able to determine at a glance which communities are active, without having to go into each one.
I want to preface this by saying that I really don't know anything about Lemmy, but I can see where subscriptions are managed by the subscribers servers in a federated situation: the community's server might not even know who is subscribed to it since the subscribers server might be responsible for pulling data.
But any individual subscribers server would know about other users on that server that are subscribed to that community
Main reason for showing accurate user counts across instances is to give an idea of how active the communities are at a glance.
People will probably think twice about joining a community with low numbers, and it normally also causes those communities to be harder to find in the first place.
Not sure how lemmy implements this, but I suppose it's not a trivial task in such decentralized environment. Imagine 10 users from instance A subscribed to instance B and then instance A went permanently down. If B holds number of subscription requests it's now out of date. If B has to poll every instance it's federated with it's additional arguably unnecessary load. So yeah local subscriptions are a low hanging fruit. I guess one way to solve it is to have some independent authority that keeps track of sub counts in case those are (made) public and queryable