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: master
from

Conversation

Projects
None yet
8 participants
@Half-Shot
Copy link
Contributor

commented Mar 15, 2019

Half-Shot added some commits Mar 15, 2019

@uhoreg
Copy link
Member

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.

This comment has been minimized.

Copy link
@uhoreg

uhoreg Mar 15, 2019

Member

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.

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 15, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 16, 2019

Author Contributor

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.

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

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

This comment has been minimized.

Copy link
Contributor Author

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.

@KitsuneRal
Copy link
Member

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",

This comment has been minimized.

Copy link
@KitsuneRal

KitsuneRal Mar 16, 2019

Member

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.

This comment has been minimized.

Copy link
@KitsuneRal

KitsuneRal Mar 16, 2019

Member

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?

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 16, 2019

Author Contributor

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.

This comment has been minimized.

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

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 18, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 22, 2019

Author Contributor

@KitsuneRal thoughts?

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

## Security considerations

This comment has been minimized.

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

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 18, 2019

Author Contributor

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"
},

This comment has been minimized.

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

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 18, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@krombel

krombel Mar 18, 2019

Contributor

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

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Mar 22, 2019

Author Contributor

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.

Show resolved Hide resolved proposals/1929-admin-contact.md Outdated
@Half-Shot

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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?

Update proposals/1929-admin-contact.md
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"
},

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.