MSC2063: Add "server information" public API proposal

[grinapo]

rendered

[grinapo]

Mentioned in the text is #1929 .

[grinapo]

Signed-off-by: Peter Gervai [email protected]

[Atreatis]

I support this change because we need it!

[KitsuneRal]

That's a good idea; but to become a real proposal it needs elaboration. At the very least, please address comments below.

[KitsuneRal]

Nitpicking on one remaining thing, but otherwise this looks pretty good to me.

[KitsuneRal]

This is almost perfect; but it'd be probably better to further distinguish between statistics/status information (uptime and the number of users) and configuration/settings information (open registrations). I don't know if it's worth it to introduce a separate /server_config endpoint just for a single boolean value - probably overengineering here. It would be great to have other opinions on this.

[grinapo]

How about

{
 "server_data": {
  "settings": {
    "m.open_registrations": true
  },
  "statistics" : {
    "m.uptime": 63072000,
    "m.registered_users": 4
  }
 }
}

Processing a json and ignoring unnecessary fields is probably painless enough that it doesn't justify creating any more complexity.

I guess someone shall come up with a real justification to separate them even this way though, or maybe it's good for "visibility" or "mental separation"?

[KitsuneRal]

I'd rather use two separate endpoints. The reason is that open registrations may (I can imagine that in theory at least) be configurable using some administration API. What I mean to say is that generally configuration is, at least in theory, read/write depending on your access credentials, while statistics are produced by the servers and cannot be tweaked even in theory. But probably let's validate it in the Matrix room.

[Half-Shot]

Should be pointed out that open_registrations is not something federation should care about. It should be reported by a client API.

[turt2live]

tbh I think it's fine to expose health/metadata/metrics at the federation level for this, mostly because there's a discovery function that server lists can use to query the data.

[jaywink]

Syncing here comment on MSC1929 regarding this, that MSC and ServerInfo.

[jaywink]

I'm wondering what usefulness the uptime actually has? If it is small, it could be "they updated recently == good" or "they're in a crash loop doing constant OOM == bad". If it is big it could be either "it's stable" or "it's not being maintained". I don't know what would be better though, just wondering whether it is good to include numbers that don't really have any particular purpose. This feels more something that should live in the /metrics endpoint for prometheus.

[grinapo]

include numbers that don't really have any particular purpose.

If you do not need it doesn't mean nobody else does. I could describe how it's useful but really, I believe that "it is useful for some people" should be enough to justify.

This feels more something that should live in the /metrics endpoint for prometheus.

This is a public endpoint, in contrast to prometheus. The primary point is to provide data for automated public server lists.

[turt2live]

tbh the first thing I'd disable is uptime: there's no metric that can be pulled from it which helps users with anything. How does uptime apply to a worker or multi-process homeserver for instance?

[grinapo]

How does uptime apply to a worker or multi-process homeserver for instance?

From the users viewpoint a service is "UP" when it's working. :-)
(As a user I would not pick a server with a constant less than a few days uptime, since it's either keep restarting or crashing, but that's me.)

But maybe you're right that it should be externally measured [icmp/api calls] instead of relying on the server.

[grinapo]

The fediverse Aggregator site for example expects to display the following stats for nodes:

• users at node (that is in the proposal)
• active users in timeframe (last month and 6 months are in the stats)
• local posts / comments (this is probably irrelevant for an e.consistent network, and may leak unwanted data about local-only rooms - or maybe the opposite: would show which homeservers have a very active local community)

[richvdh]

@grinapo it looks like you've accidentally merged the wrong branch:

See also #3367

[turt2live]

@grinapo you'll need to hard reset to before the merge - a revert isn't going to work.

If you need help, visit #matrix-spec:matrix.org and we can figure it out there.