@Gargron pull account number?

Add?

@thegibson Pull from where tho. Some central aggregating service, one of the few that exist right now. What if it's down? What if it's being slow?

Using total row count of accounts table might be more reliable and more in spirit.

@Gargron @thegibson Maybe have instances whisper information to one another about their user counts--and the user counts they know about--to other instances once a day or so? Two degrees of separation ought to be enough for m.s to estimate a rough head count, no?

Smaller instances, meanwhile, would see a much smaller observable aggregate count, but that'd be interesting too.

@saper @Gargron @thegibson It would avoid reliance on a single centralized service.

Not any more unmanageable than a game of whisper-down-the-alley. (Hence my use of the term.) Thus, not going to provide a painstakingly accurate sum—certainly not as observed from less connected instances—but when you're dealing with ~1.5 million horizon, long tail can fall off without losing significant digits.

"Here's my count, and counts of every server that polled me for toots today" hardly implies mess.

@saper @Gargron @thegibson Alternatively, a store-and-forward network a la Usenet could be used to share small instance-reported statistical packets, without the worry of losing the long tail.

This would eliminate the need for any given instance to reconcile the counts coming in over alternate routes—as the Usenet-esqe messages would self-reconcile on GUID. The trade-off is storage consumed by storing-for-forward those stats-packet messages.

@saper @Gargron @thegibson This is why I suggested only two degrees of separation. Anything beyond that becomes computationally expensive.

Granted, two-degrees of separation only work if there's enough interconnectivity across the fediverse as seen from m.s for that to be representative. If there's another sizeable Mastodon cluster that can only be reached from three or more degrees of follow linkages, the whisper approach would fail.