MSC1929: Homeserver Admin Contact and Support page

[Half-Shot]

Rendered

Implementation: Supported by multiple servers through mdad

FCP tickyboxes

[uhoreg]

Looks pretty good. I tried to be not too bikeshed-y ;)

[ara4n]

i guess the problem with using .well-known is that the HS admin may not have permission to set well-known URLs (which is an eventuality we have to consider, i think). ie this effectively makes .well-known support compulsory.

However, the advantage of doing it out of band is that if the HS is dead you can still find the admin. Also, it’s nice that you can specify your actual mxid given that we don’t have aliases or decentralised/multiaccounts yet.

perhaps we should allow a TXT record too? and failing that, recommend @_admin:domain or something should route somewhere useful?

[Half-Shot]

Well, I don't think the contact details thing is compulsory, and I'm not convinced that you wouldn't have access to add your own details to the host. In that case, we could either do a TXT record or just have a .well-known endpoint on the homeserver host itself.

For the reasons given in the proposal, I'm still quite adverse to a localpart.

[KitsuneRal]

I don't think this would fly the way it's proposed (see the questions below).

[Half-Shot]

This proposal has been open for a while now, feedback welcome? Alternatively if the spec is bad then let me know if its a waste of time.

[krombel]

I think there are admins around which just setup a server and will pay attention to further development once in a while (which might be caused by some users complaining about missing feature support or issues)

Especially for those such interface would be helpful I think. Sadly I expect it to take some time to get widely adopted... (which does not count as con for this proposal)

The only question for me is the endpoint where this should be exposed.
Why not expose it via .well-known and federation-api (as I think this can be assumed "resolvable" from other servers)?

[Half-Shot]

Why not expose it via .well-known and federation-api (as I think this can be assumed "resolvable" from other servers)?

Isn't .well-known designed to be resolvable over federation though?

[grinapo]

In the course of MSC2063 (server info for automated lists) I have realised (w/ help of @Half-Shot ) that static server information would be much better to provide here, namely:

• server_name: human-readable server name
• server_description: a human-readable longer description, for example about speciality local rooms, local rules, restrictions
• server_country: the home country or the target country of the server, if any

This is all static, manually defined data about the server, which would be better situated in the static .well-known than dynamically generated by a matrix endpoint.

[turt2live]

As a support endpoint, I'm not sure this information is relevant here. Other MSCs, like 2063, are better suited for general server information, I think.

[grinapo]

As a support endpoint, I'm not sure this information is relevant here. Other MSCs, like 2063, are better suited for general server information, I think.

I agree but there is an important difference: this MSC does not require the developers of the "servers" to agree, it can be implemented by admins, despite visible lack of interest from the mentioned people.
Also the suggested information is static, and related to the infos about admins. (When someone want to contact a "server" it's usually very useful to know where it is and what are its general purposes, this is backed up by experience now.)

(But in fact I just realised that I should actually create an external code to get #2063 done without synapse, using the database directly, or maybe using the API indirectly.)

[jaywink]

I'm personally of the opinion it would be much nicer for server information to come out of Synapse (or other servers) directly, via configuration. The reason: setting up and running a Matrix server is already quite complex, especially when using delegation. The more manual static file steps that are added, the more complex that becomes - and this would be the third well-known file should the server require delegation for a custom server name.

On a related note (and the reason I saw this proposal actually, thanks @grinapo ), I started work on a more generic federated server information document proposal, see here. It pretty much has almost all the parts here (and could have all of them).

Personally I would rather see Synapse export one endpoint for both contact, server metadata and metrics, which would cover this and MSC2063. So I'm wondering would it be an impossible thought to somehow align these together, by waiting on ServerInfo maturing and including an API endpoint in the Matrix spec referring to it?

[Half-Shot]

@jaywink Yeah, I'm starting to see that it might be a necessary compromise to have synapse output it. I kinda wish there was still a way to serve a static file purely for people who do want their information static and separate from their homeserver, but I do concur that if it involves manual steps... a lot of people won't bother.

In terms of merging the proposals, I still think the information in this proposal is logically separate from statistics but perhaps not enough to grant it a different endpoint. I would consider merging it if it's more likely to pass MSC.

[grinapo]

As far as I see homeserver does not serve .well-known/, only API, and these are "philosophically" (and technically) different entities with different purpose.

Briefly skimming through the registered welln-known services suggests me that the feature is designed to be a site-wide [uri-related] platform-independent metadata (similar to, surprise, nodeinfo and thus serverinfo).

In contrast to that the Matrix APIs are very matrix specific endpoints.

First, I would say platform independent standardised metadata shall be preferred to locally defined ones.

Second, I agree the sentiment that most people would not want to invest time to create separate metadata server; however this is a bit softened by the fact that we talk about admins creating public servers and not general users; I would guess majority of those won't be worried about installing yet another webserver or an additional well-known directory, and even if they would, it would only mean we would be exactly where we are now.

Other pro for a static well-known is that, well, it's statically served, with almost zero resource demand.

I would say that entering the data in homeserver.yaml is not much easier than entering them into well-known.admininfo.example.json. I do not really like static data to be served dynamically for resource conservation reasons.

I also would like both of the MSCs gain some traction, since they're required to be able to ease the load on the central matrix.org server by creating meaningful [automated] list of servers.

[aaronraimist]

Maybe it is covered by support_page but it would also be nice to have a link to a status page for the homeserver https://matrix.to/#/!tDRGDwZwQnlkowsjsm:matrix.org/$15699625956501VfBIC:matrix.org?via=matrix.org&via=riot.tenx.tech&via=kde.org

[michaelkaye]

As a replacement for a support_page in the top level, and merging the idea of a status page; could we provide URLs as another method of communication.

Your admins URL could be to a page with your server status, or to your server policies / an alternate forum for help.
Your security URL might be to a page describing how to securely report issues.

This may also be easier to manage in clients where you don't yet have a matrix ID because you haven't managed to sign up for one (thus wanting to find help) or if you don't have an email account you want to use baked in (redirecting to a mailto link doesn't always help when you use a web-only email service, for instance) - but pretty much everything able to access this file is going to be also able to access other sites on the internet.

[SISheogorath]

I definitely agree with @grinapo about this fitting better into the API than .well-known. Besides the issues that would be solved by putting it into the API, like discoverability in all setups, it would also prevent data duplication in .well-known. As @michaelkaye mentions, there could should be a security contact in such format. But .well-known already has that in form of the security.txt-standard. Which we would duplicate this way.

I think it tries to solve a very matrix specific problem and therefore doesn't belong to .well-known.

Also making it part of the client-to-server and server-to-server APIs, it would even allow to provide different contact addresses (which is reasonable within larger organisations) for the client-to-server API than for the server-to-server API. Making server admins taking care of federation issues with synapse, while you have your regular client/workstation administrators helping out when a client like Element acts up.

[MTRNord]

I am kind of wondering: Would it make sense to have a field "allows automatic reports"? As I am wanting to write a web interface for mjolnir and other moderation and having it also look for this would be helpful. However I just cant assume if an admin wants to be contacted or if an automated "User xy was banned in abc for spam" would be sufficient for an admin. Having a flag for this would be helpful so the admin can decide on this.

On the other hand this may actually even be a MSC building on top so it also can specify metadata in the event for further automation. Not quite sure currently

[grinapo]

As for myself I would probably create a room and join there, being able to fine-tune its notification parameters or automagic handling; and I would provide it there.

[turt2live]

Automated report handling is likely best discussed in another MSC. There's some plans being formed to figure out such systems, and it'd be best to not have this MSC get stuck in those conversations.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[turt2live]

Spec PR: matrix-org/matrix-spec#1733

[turt2live]

Merged 🎉