[WIP] MSC2301: server info endpoint

[ara4n]

We turn /versions into a more generic unauthed server /info endpoint, suitable for sharing branding information to clients before they login or register.

Open question on whether to use a server info room to store the bulk of the data or not.

Rendered

[aaronraimist]

So this is an alternate way to do #1929?

[grinapo]

Also #2063?

[turt2live]

Suggested change

	* `/_matrix/media/r0/config` tells you the capabilities of your media repository (unauthed)
	* `/_matrix/media/r0/config` tells you the capabilities of your media repository (authed)

[turt2live]

We call them server notices: https://matrix.org/docs/spec/client_server/r0.5.0#module-server-notices

Suggested change

	* System Alerts (as a way of sharing server updates with users)
	* Server Notices (as a way of sharing server updates with users)

[turt2live]

why are we not using objects for m.brand?

[turt2live]

what if my admin is an email address? what if there's many?

[turt2live]

Needs comparison to #1929 and #2063 (per comments)

[turt2live]

also https://matrix.org/docs/spec/client_server/r0.5.0#get-matrix-client-r0-voip-turnserver

[bwindels]

How would clients receive updates to the info data? Periodic polling of the endpoint?

[ara4n]

ugh, i tried to enumerate all the existing prior art in the 7 bullet points at the beginning of this, but apparently missed #1929 and #2063. sorry. what a mess.

[grinapo]

ugh, i tried to enumerate all the existing prior art in the 7 bullet points at the beginning of this, but apparently missed #1929 and #2063. sorry. what a mess.

So, let's see what's in #2063 (API):

• - whether server supports (open) registrations
• - number of registered accounts
• - number of active accounts (with events) in last week/month/6moths
• - server uptime

As in #1929 (well-known):

• server admins (matrixid, email, role) (proposal m.server_admin can't list multiple roles and contact methods)
• support webpage (url)

I would also add for this static well-known page:

• server name (m.brand.server_name)
• server description (m.brand.server_info)
• server home country
• server preferred countries

Possibly all of those are optional.

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)

1929 is actually implemented by some sites already. ;-)

[jaywink]

It would be great to have all the necessary info in one endpoint, ie server metadata type info and usage info, to avoid consumers needing to poll several endpoints. Server metadata is no more static than usage information, so any site building a list of for example available Matrix sites would still have to consume both.

<community hat>
I tried to model the necessary information in a new project called ServiceInfo, which was planned to be suitable for usage cross-platform. It's unfinished since there wasn't too much interest in it, a lot of the federated web (unfortunately) going with NodeInfo. But just pointing as an idea of what I'd personally like for Matrix to also export for consumers like the-federation.info.
</community hat>

[turt2live]

(please let's move to a thread before this becomes a longer conversation)

[ludwigbald]

We don't really need that here. A normal static endpoint should be just fine. It is probably only ever called once, when the user is trying to decide on which homeserver to register on.

[MTRNord]

Peekable rooms also would make this harder to access from the outside in my opinion.

[MTRNord]

Hi, I like this. I would love to have some additional fields however as I am working with some people on a mastodon alike server/community finder and some more metadata would be nice to have.

For us missing fields are:

• Link or text for server rules
• Registration Status. (While this can be taken from the server api itself it seems still reasonable to have it here. As it would make 2 states possible: Fully disabled, registration on invites, open registration.)
• The m.server_admin Should probably be an array as there might be more than one admin for a server.
• A list of categories. (While the above things above would be applying for more general stuff this mainly applies for usage with a serverlist as that allows the serverlist to easily determine the servers topics. This might also be useful for public roomlists however where clients use the serverlist as provider for servers in the roomlists. But this idea is something for another discussion)