MSC1929: Homeserver Admin Contact and Support page

[Half-Shot]

trafficstars

Rendered

[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.

[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?

[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.

[minecraftchest1]

I would like to see a way to have a list of alternate contacts. For instance, being able to have the matrix-id field be the primary contact, and matrix-id-alternative be an array of alternative addresses that the admin can be contacted at.

[Half-Shot]

assigns himself to triage the comments here

[minecraftchest1]

I just finished writing a basic proof of client implementation. It is not integrated into any existing clients (such as Element or Fluffychat), but does show off the basic usage, I plan to extend the script with some more features in the future. https://gitlab.com/-/snippets/2374686

[grinapo]

@minecraftchest1 a lot of servers are using the scheme for years now, you can try and test. I believe lot of servers in #alladmins:grin.hu have it implemented since 2019.

[minecraftchest1]

I know it has been done on the server side for a while. But as far as I know, their has been nothing on the client side, which my script intends to change.

Sent from my T-Mobile 4G LTE Device

-------- Original message -------- From: Peter Gervai @.> Date: 7/21/22 11:10 AM (GMT-06:00) To: matrix-org/matrix-spec-proposals @.> Cc: Minecraftchest1 @.>, Mention @.> Subject: Re: [matrix-org/matrix-spec-proposals] MSC1929: Homeserver Admin Contact and Support page (#1929)

@minecraftchest1https://github.com/minecraftchest1 a lot of servers are using the scheme for years now, you can try and test. I believe lot of servers in #alladmins:grin.hu have it implemented since 2019.

— Reply to this email directly, view it on GitHubhttps://github.com/matrix-org/matrix-spec-proposals/pull/1929#issuecomment-1191677089, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKIAII2NDPHI2FZN7M52YR3VVFY6VANCNFSM4G64G2JA. You are receiving this because you were mentioned.Message ID: @.***>

[grinapo]

I know it has been done on the server side for a while. But as far as I know, their has been nothing on the client side, which my script intends to change.

Ok. You may check this script which tries to gather info on a server.

[6543]

as for implementation, isn't it already implemented via matrix-docker-ansible-deploy: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/configuring-well-known.md#optional-introduction-to-homeserver-admin-contact-and-support-page ?

[PC-Admin]

This MSC seems better then nothing and getting something pushed through here seems like a high priority, as getting admins to coordinate together for abuse management is still quite difficult and requires a lot of manual coordination.

IMO it would be even better if a webmaster contact email or MXID was served up by Synapse's API, as we could make it mandatory for any server that has public registration enabled. (In the same way that Synapse requires you to now have email registration or captcha configured to enable public registration.)

[aine-etke]

Some notes about implementations:

https://github.com/spantaleev/matrix-docker-ansible-deploy supports serving that MSC (it deploys /.well-known/matrix/support file if configured by server owner)

https://gitlab.com/etke.cc/mrs/api/ (and the demo instance on https://matrixrooms.info ) supports that MSC by using the listed contacts to send automatic emails when a room is reported (if configured by instance owner)

[turt2live]

Sorry it's taken so long to move this MSC forward. Unfortunately, it looks like it got caught in an amount of bikeshed and scope creep, which put it on the agenda for conflict with MSC2063, MSC2300, MSC2301, and MSC3360. In practice, it's better (in my opinion) to keep this MSC's scope narrow to support details only while we determine a system for general information, uptime, etc about the server.

This may mean that the endpoint is rapidly deprecated, however waiting for something generic or more suitable feels like a classic case of perfect being the enemy of good. We're also considering changing how event reporting works in Matrix entirely, which may affect this endpoint in the future as well.

In the meantime, let's just get this landed: people are (trying to) use it, and it is able to sustain itself while other MSCs get worked on.

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• [ ] @dbkr
• [x] @uhoreg
• [x] @turt2live
• [x] @ara4n
• [ ] @anoadragon453
• [x] @richvdh
• [x] @erikjohnston
• [x] @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[TheArcaneBrony]

Additional field request: contact_all (boolean) Motivation: special cases where all admins/accounts are recommended to be contacted at once, rather than a single admin, for cases where individual contact may be futile. Examples:

• Single-user homeservers, where a user has accounts across multiple homeservers and may not check all accounts frequently
• Cases like rory.gay where all admins are part of one physical body and the a given admin may literally not be around for weeks, months or years (eg. @rory:rory.gay and @root:rory.gay have not been around for months)

[mscbot]

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

[mscbot]

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

[turt2live]

Spec PR: https://github.com/matrix-org/matrix-spec/pull/1733

[turt2live]

Merged 🎉