Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC1929: Homeserver Admin Contact and Support page #1929

Open
wants to merge 8 commits into
base: old_master
Choose a base branch
from

Conversation

@Half-Shot
Copy link
Contributor

@Half-Shot Half-Shot commented Mar 15, 2019

Rendered

Copy link
Member

@uhoreg uhoreg left a comment

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

`admins` is optional, but recommended.

`support_page` is a optional property to specify a affiliated page of the homserver to give users help
specific to their installation.
Copy link
Member

@uhoreg uhoreg Mar 15, 2019

Would this be used, for example, by clients to automatically show a link to users to help them find support? Are there other use cases that you're thinking of?

If it's mainly for clients to present the information to users, maybe it would be better to put this is .well-known/client, so that clients only need to fetch one .well-known file, rather than two.

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 15, 2019

Yeah I had imagined this would be presented to the client in case of failure, or for troubleshooting steps with logins. I'm not adverse to taking this out of ./support for now and making support pages be part of a separate proposal.

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 16, 2019

If it's mainly for clients to present the information to users

This is more server facing for admins to complain to other admins, but doubles as a local support mechanism too.

proposals/1929-admin-contact.md Outdated Show resolved Hide resolved
Copy link
Member

@ara4n 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?

@Half-Shot
Copy link
Contributor Author

@Half-Shot Half-Shot commented Mar 15, 2019

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.

Copy link
Member

@KitsuneRal KitsuneRal left a comment

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

```javascript
{
admins: [{
matrix_id: "@admin:domain.tld",
Copy link
Member

@KitsuneRal KitsuneRal Mar 16, 2019

I'm bikeshedding but if it's email (rather than email_address) it should be matrix, no?


Hardcode a given user localpart that should be used as an admin address.
- The account would need to either internally redirect messages intended for @admin:domain.tld to another account(s)
- OR require an admin to regularly sign into this special account to check for messages. Neither of which is useful.
Copy link
Member

@KitsuneRal KitsuneRal Mar 16, 2019

Neither is useful is a pretty strong statement that certainly needs clarification for the first part. I understand that redirection does have its shortcomings but the proposed primary solution has them too. Consider the case of two timeshifting admins, e.g. - does it mean that .well-known will have to be switched twice a day, and clients have to somehow discover that? And what if the support line involves load balancing across 10 people?

Quite frankly, I don't see how far the proposed solution is from hardcoding a certain user localpart. Once the user MXID is specified in .well-known, you effectively declare that (at this arbitrary period of time) this and only this Matrix user is supposed to receive all support requests, right? Now how many people would want to re-use their primary account for admin tasks? And if it's not primary, doesn't it force them into option 2 of regularly signing into the admin account?

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 16, 2019

Consider the case of two timeshifting admins, e.g. - does it mean that .well-known will have to be switched twice a day, and clients have to somehow discover that?

No, you would define both admins in the list. If we think it's useful, you could optionally define a timezone working hours .

This data is meant to be static, and rarely changed when staff shuffle (as in leave or join the org, not rotas or anything) around which I would expect to be uncommon. In the case of irregular support systems, there is the option of specifying a support page. I don't intend to spec a complete format for every type of support system people might use, but the most common one is just specifying a contact address of one or more admins.

And what if the support line involves load balancing across 10 people?

Then I would suggest listing one mxid in the entry list, and writing some sort of bot or ticketing system to handle it. That's certainly a uncommon option for the vast amount of homeservers out there, and not part of this proposal.

Quite frankly, I don't see how far the proposed solution is from hardcoding a certain user localpart

Fundamentally, you could specify @_admin:domain.tld in the entry list if you wanted and it would function the same way as a hardcode. The proposal gives the option to be smarter than that and list the actual admin, or an email address.

Hardcoding a support mxid means more work on the homeserver to direct messages to the right place (redirecting messages to other accounts is a whole proposal in itself), or for admins to now sign into two accounts everywhere to catch messages.

Now how many people would want to re-use their primary account for admin tasks?

The vast vast vast majority of homeserver admins out there run small homeservers and probably won't be getting a lot of admin queries. For the few that do have a large amount of support traffic, specify a second account. Personally speaking as a small server admin, I do not wish to sync two accounts if I can help it. I would say that most server admins out there (who also operate small servers, largely) would say much the same.

In general I don't see a reason why you cannot specify a config like:

{
    admins: [{ matrix_id: "@admin:domain.tld" }],
}

if you wanted to have a dedicated admin account, but the proposal doesn't force people into setting one up.

Copy link
Contributor

@grinapo grinapo Mar 18, 2019

Synapse (or general homeserver) at installation/configuration stage may ask for the admin id, or may set it to user#1 unless the admin's changed it? So a hardcoded address can redirect to user#1 by default, which would be changeable.

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 18, 2019

Yeah, it could do. I'd probably say that the operator needs to consciously elect a admin user, rather than it defaulting to a user to avoid us accidentally leaking lots of private userids.

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 22, 2019

@KitsuneRal thoughts?

- vCards would add bloat, as the vast majority of a vcards contents is not useful for contacting an admin.

## Security considerations

Copy link
Contributor

@grinapo grinapo Mar 18, 2019

Isn't it a security consideration that admin email is available publicly processable by automatic ("spambotty") means?
I don't know about matrix-targetting spambots but matrix-ids may be a valuable asset in the near future, when matrix start to dominate the communication of the world.

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 18, 2019

So this is a problem regardless of medium, although I admit that more people are going to attack email once they notice the new format become a standard.

Realistically I would expect the homeserver/email provider to do the usual spam checks/ reputation work to ensure that spam isn't making it's way to users.

Fundamentally we need to provide a way to allow users from any server to contact the admin of another server and the two ways of doing it are providing a standard address (e.g. @admin:domain.tld ) or allowing it to be custom as in this proposal. This proposal is not much better, but at least requires an ounce more effort of a spammer to go and find your address. My final point is that you could carry this style of attack out simply by joining a large public room, so I wouldn't say this proposal is making things any easier

Tl;Dr - I feel like the spam problem is going to happen whatever mechanism we provide, and I don't have a good answer other than other implementations adding sensible precautions.

matrix_id: "@admin:domain.tld",
email_address: "admin@domain.tld",
role: "admin" # If omitted, the default will be "admin"
},
Copy link
Contributor

@grinapo grinapo Mar 18, 2019

May it be useful to specify a room-id (which could be joined by multiple/all/varying admins)? They may (and probably should) use foreign servers to watch the room.

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 18, 2019

RoomId (possibly alias is better) is a good shout, though I don't know if we plan to have a general "landing" room in other places and this may be a duplication of effort. Will leave that question open to other reviewers.

Copy link
Contributor

@krombel krombel Mar 18, 2019

Although I think RoomID might be a possible solution I don't think this is sth. people will use in general as I think this contact will mainly be used to notify about updates, spam or security issues.
These are information I as an admin would not want to be shared with everybody.

As an alternative I think a group might fit here as well. This could then contain multiple users which take the admin role. This especially can better administered inside of matrix

Copy link
Contributor Author

@Half-Shot Half-Shot Mar 22, 2019

I'd love to specify a group, but I'd keep that in mind for a future extension when we have groups in the spec. And certainly the reason for the roles given in the proposal is to specify the sensitivity for an account, amongst other things.

proposals/1929-admin-contact.md Outdated Show resolved Hide resolved
@Half-Shot
Copy link
Contributor Author

@Half-Shot Half-Shot commented May 21, 2019

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
Copy link
Contributor

@krombel krombel commented May 24, 2019

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

@turt2live turt2live changed the title MSC1929 Homeserver Admin Contact and Support page MSC1929: Homeserver Admin Contact and Support page May 24, 2019
@Half-Shot
Copy link
Contributor Author

@Half-Shot Half-Shot commented Jun 2, 2019

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?

Co-Authored-By: Hubert Chathi <hubert@uhoreg.ca>
matrix_id: "@admin:domain.tld",
email_address: "admin@domain.tld",
role: "admin" # If omitted, the default will be "admin"
},
Copy link
Contributor

@grinapo grinapo Jun 3, 2019

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.

@jaywink
Copy link
Member

@jaywink jaywink commented Jul 20, 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?

@Half-Shot
Copy link
Contributor Author

@Half-Shot Half-Shot commented Jul 22, 2019

@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
Copy link
Contributor

@grinapo grinapo commented Jul 22, 2019

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.


```javascript
{
admins: [{
Copy link
Contributor

@grinapo grinapo Sep 9, 2019

It seems it would be better to quote all field names, too, as

{
     "admins": [{
        "email": "admin@example.com", 

@aaronraimist
Copy link
Contributor

@aaronraimist aaronraimist commented Oct 1, 2019

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

matrix.to Remove

Riot/iOS, matrix-ios-kit and matrix-ios-sdk discussion | https://itunes.apple.com/app/riot-open-source-collaboration/id1083446067 | TestFlight build: https://testflight.apple.com/join/lCeTuDKM

@michaelkaye
Copy link
Contributor

@michaelkaye michaelkaye commented Jan 24, 2020

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.


## Proposal

The proposal suggests adding a new endpoint: `.well-known/matrix/support`.
Copy link

@jomat jomat Jan 24, 2020

It should be made clear whether it is served on the main matrix domain or the delegated matrix server(s) or both.

Copy link
Contributor

@grinapo grinapo Jan 25, 2020

I would say on the same well-known as the .../server endpoint.

@SISheogorath
Copy link

@SISheogorath SISheogorath commented Mar 8, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet