Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
MSC1929: Homeserver Admin Contact and Support page #1929
referenced this pull request
Mar 15, 2019
ara4n left a comment
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?
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.
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.
referenced this pull request
May 31, 2019
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?
@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.
As far as I see homeserver does not serve
Briefly skimming through the registered
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
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.