Simplify email invite process

[turt2live]

This is annoying:

1. Receive email invite
2. Register with email (confirmation required)
3. Accept invite
4. Confirm email again
5. Finally in the room after staring at your inbox more than the client

[turt2live]

ftr this is all mandated by spec, so the fix here would be to "not do that", whatever that entails.

[richvdh]

seems closely related to element-hq/element-meta#1847 (and any number of other open issues on element-web)

[Yoric]

It would really, really, really be great if we could fix that.
It's a really nasty papercut.

[hex-m]

One problem with the current 3PID-invite is that it depends on having an IS which should be optional afaik.

A naïve proposal:

1. if there is a local user on the HS with a matching 3PID, send a normal invite using the MXID
2. otherwise send a mail inviting the user to register an account (on a homeserver chosen by the HS-admin or the inviting user)
3. tell the inviter that she should set the room to "knocking"
4. add the matrix://-link to the invite-mail so the invitee can knock

[kevincox]

1

This sounds like the homeserver is just another IS. I see no reason to bundle them together. (Although I agree that the user should be offered a default IS choice, whether that is by the homeserver or by the client (or both) I don't know what is better)

2

This sounds good. This would also be a nice use for password/token join rules. You can send the token in the email and the user can join with an existing account or create a new account and join.

3

If we use a token there is no need to knock.

4

If we go token it would be cool to include this in the link to skip the knock!

[hex-m]

I see no reason to bundle them (HS and IS) together.

There is the central one which is - you know - centralized. There is sydent which isn't supposed to be self-hosted and ma1sd which is not officially supported/endorsed. Also as the HS already has the information there is no reason to involve another system just for that functionality. For our use-case (internal chat in our organization) invite-colleague-by-mail is the only needed feature that depends on an IS.

This would also be a nice use for password/token join rules

Nice idea! I've searched around and found a spec issue and an element-web issue requesting this.

[kevincox]

Also as the HS already has the information there is no reason to involve another system just for that functionality

The HS doesn't necessarily know the users email. It is often asked (usually for account recovery) but is often not required. I'm not saying that the HS can't offer an identity server, but I don't see the need for another protocol and wouldn't want to require using the homeserver's identity server.

[hex-m]

In a corporate setup you usually have an external identity provider which also provides 3PIDs. This would not be another protocol. It would just mean adding a line to the spec which says if the 3PID is found in the local user directory, simply issue an invite for that user.

[kevincox]

I think we are talking past each other because I misunderstood what you meant:

if there is a local user on the HS with a matching 3PID, send a normal invite using the MXID

The HS doesn't know 3PIDs but I assume here you mean if the identity server doesn't return a 3PID right? In that case I think the rest of the flow makes sense. Basically instead of getting the IS to send the invite the homeserver just issues the invite directly. Is that what you meant?

[hex-m]

Sorry for the unclear wording.

I don't use an IS but can still set e-mail addresses for my account. So my HS knows which e-mail addresses are associated with my account. In our organization the SSO-attribute-mapping actually sets the e-mail for all accounts when they are created. So for every @myorg.tld address my HS could resolve the MXID without involving an IS.