Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active users statistics from instances #874

Closed
jaywink opened this issue Apr 4, 2017 · 11 comments
Closed

Active users statistics from instances #874

jaywink opened this issue Apr 4, 2017 · 11 comments
Labels
api REST API, Streaming API, Web Push API

Comments

@jaywink
Copy link

jaywink commented Apr 4, 2017

Looking at the list at https://instances.mastodon.xyz/ it looks like Mastodon has some route to share statistics about the instances. It would be neat also to have active user statistics, for example last 30 days and last 6 months. This gives a much better view regarding activity than just user counts, and also allows neat graphs :)

See for example stats produced by a Diaspora server: https://iliketoast.net/nodeinfo/1.0

What would be even neater would be if Mastodon (and other compatible server stacks) implemented the same way to share node info as Diaspora, Friendica and Hubzilla. Currently that is NodeInfo as linked above. Though personally I would not suggest implementing it as it is (it's not very flexible), something compatible to all could be created, if wished. For example I made an example possibility NodeInfo2 which is designed to be more flexible.

@ashfurrow ashfurrow added api REST API, Streaming API, Web Push API enhancement labels Apr 22, 2017
@Flaburgan
Copy link

@jaywink the "real" NodeInfo 2.0 is going to be more flexible as you wished: jhass/nodeinfo#17 so I highly recommend mastodon to use NodeInfo, that's now the standard to provide information in the decentralized social world.

@jaywink
Copy link
Author

jaywink commented Apr 25, 2017

@Flaburgan services and protocols is still a locked list of strings. It is still IMHO over-engineered, and thus not really usable. To really provide information on any instance we need something that allows giving whatever information the server wants - it is the responsibility of the reader to understand it or not understand it. Locking the strings into the spec itself is just shooting yourself in the foot.

@jaywink
Copy link
Author

jaywink commented Apr 25, 2017

If Mastodon btw wants to consider an alternative to NodeInfo, I updated my alternative NodeInfo2 draft at https://github.com/jaywink/nodeinfo2 . It was created after giving feedback on NodeInfo that was not considered as necessary to fix. I will implement it in the-federation.info at least soon. Feedback welcome and since it isn't actually AFAIK implemented by anyone yet, there is time to tweak it into any direction to suit everyone.

The main change I made now was to add support for ActivityPub. Basically the idea is that ActivityPub Actor objects would have an URI to their NodeInfo2 document as property nodeInfo2Url. This cuts reliance on /.well-known URL's which while Mastodon does allow, ActivityPub in general doesn't base anything on.

@agateblue
Copy link

We are currently needing some ot these statistics in EliotBerriot/mnm#16. If we want to better understand the network behaviour, we cannot only rely on user count, which does not means anything in itself. We would like activity data to be available on one of the public API endpoints, either at /api/v1/instance or a more specific one, or somewhere else where we can easily fetch it.

More specifically, having the following metrics available would help us to spot dead or really active instances, and better understand how Mastodon users actually behave:

  • Publishing users: users who published a toot in the last N days
  • Sharing users: users who boosted or favorited a toot in the last N days
  • Active users: users with at least one of the previously mentioned activities
  • Inactive users: users without any of the previously mentioned activities

We will need of course to define the ideal amount for N, maybe we could have many (7 days, 30 days and 60 days, for example).

I'm also thinking that using an existing standard or best-practice such as NodeInfo, as mentioned in earlier comments would be a good way to streamline any stat-related effort or project. Having all these stats available at a single endpoint (json, xml or whatever) would be a plus, allowing caching and reducing the load on instances because anything could be fetched in a single HTTP request.

Now, I understand there are more urgent and critical issues. I may consider learning Ruby to actually implement this, but it will take some time ;)

@Flaburgan
Copy link

@EliotBerriot here are the stats actually provided by diaspora, friendica and hubzilla through NodeInfo:

  • Local users (nb of account on a node)
  • Local posts (nb of posts created locally on a node)
  • Local comments (nb of comments created locally on a node)
  • Active users halfyear (nb of users who logged at least once in the last 6 months)
  • Active users monthly (nb of users who logged at least once in the last 30 days).

With those data, @jaywink and I created https://the-federation.info.

@agateblue
Copy link

@Flaburgan thanks for the link, it's nice to know how other projects are handling this.

Regarding activity, what I find the more important (but I may be wrong) is how users engage with the community, which, imho, cannot be measured only with logins. To me, logging in and reading content is the very first level of engagement, followed by sharing / favoriting content and publishing new content on the platform.

Although, I understand it can be hard and performance-heavy to to provide this data in a structured way.

@Globulle
Copy link

Globulle commented May 4, 2017

Regarding activity, what I find the more important (but I may be wrong) is how users engage with the community, which, imho, cannot be measured only with logins.

I agree. A simple indicator could be the number of posts (and/or comments and/or likes and/or whatever depending on the detail we want) per user and per unit of time.

EDIT : I see this is available on https://the-federation.info (Posts per user and Comments per user), despite it is not said which time base is used (per day? per month?).

@Gargron
Copy link
Member

Gargron commented Feb 13, 2018

Implemented in #6125

@Gargron Gargron closed this as completed Feb 13, 2018
@Flaburgan
Copy link

So it looks like you didn't go the NodeInfo way, too bad. Thank you anyway for providing this, maybe I'll write a puller specific to mastodon only one day.

@Gargron
Copy link
Member

Gargron commented Feb 14, 2018

I forgot about this issue until 2 hours ago so it wasn't on my mind when implementing. Maybe we can add a nodeinfo document? It doesn't seem like a big deal. If anyone wants to submit a PR, go ahead.

@jaywink
Copy link
Author

jaywink commented Feb 14, 2018

@Gargron "active users in weekly buckets" <3 thanks!

Re NodeInfo. I believe it will not make a good choice not just because of some design issues with NodeInfo itself (which people can live with - all specs are awful in some way), but it's just not suitable for ActivityPub powered networks (@Flaburgan this is a fact, not personal opinion). NodeInfo relies on a .well-known route existing at the server root. ActivityPub doesn't restrict applications living at the server root.

Of course Mastodon could add it anyway, it certainly would not hurt anyone, but as a "permanent" solution for this kind of server metadata it would be nice to see something out of the SocialCG for example that has opinions put into it from a wider audience than one single protocol (which relies on server root to operate). Now if someone would have time/interest to start pushing for such a spec... :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api REST API, Streaming API, Web Push API
Projects
None yet
Development

No branches or pull requests

6 participants