Do a .well-known lookup on explicitly entered homeserver URL.

[aaronraimist]

Now that both Element Web and Android allow you to enter a server name into the homeserver URL field and have the client to a .well-known lookup, iOS should do the same thing otherwise it is very confusing.

[aaronraimist]

Related Element Web PR: matrix-org/matrix-react-sdk#5474

[ctsde-markus]

Same is valid for integration of a self hosted Jitsi server. I only get a 404 error message when i try to open a group meeting on a homeserver that defines it's own Jitsi Meet server via .well-known

[Johennes]

The well-known look-up seems to already be implemented. However, once you leave the HS text field, there is a race condition that causes a request to /_matrix/client/r0/login simultaneously to the well-known look-up (triggered here). Since that request cannot use the resolved HS URL, it'll error out with a 404.

[n0emis]

Would it be possible to get a fix for this bug? This would improve usability for inexperienced users a lot...

[NHAS]

Yes this has just bitten me as well. This is quite annoying

[ptman]

Who does triage for tickets? This needs priority etc. labels set

@RiotRobot @pixlwave ?

[hex-m]

@ptman Currently only the triage process for element-web is documented afaik. But there was some recent activity so it should be defined somewhere.

[olmari]

For FTUE and novice users (which is the "hardest" target to gain) suffers highly from this seemingly minor bug. It's major for user trying to use matrix first time :)

[aaronraimist]

Personally I wish this wasn't needed. In my ideal world we would teach users that their username is not their localpart but is actually their MXID (as in @user:server). Then they would always just type in their username and password to login. There would be no need to mess with homeserver URLs.

I wish the login screen on all clients never showed a homeserver URL field but since Element Android started doing this method and Element Web followed, then I believe iOS should do the same. But if designers are here reading this in preparation for #5151 / #5161, please consider strongly leaning in to teaching users to just use their username. Users would only have to learn and type in two things rather than three and it has the added benefit of starting to introduce the concept of federation.

[pixlwave]

@aaronraimist I'm a fairly heavy +1 on this comment, and will share it internally for you. That said, it is necessary to ask for the homeserver URL when a user is signing up, so the issue still stands in that regard.

[hex-m]

In my ideal world we would teach users that their username is not their localpart but is actually their MXID (as in @user:server). Then they would always just type in their username and password to login.

This does not play well with SSO. Our users have to specify the server, such that their client can redirect them. After that they actually do login with their "username and password". So in this case the MXID will always be distinct from the login-username.

[pixlwave]

@hex-m If the first screen only showed a field for the MXID and post look-up showed the SSO screen, would you consider this to be a nice flow? E.g. the password/SSO/GitHub,Apple,Google etc options are all hidden until the homeserver has been discovered.

[olmari]

@pixlwave Generally my vote for only exposing those elements (no pun) to user that user can actually affect at any particular stage of (login/registration) process, including social login buttons until known what homeserver and does it support em etc. More generally this also sides with @aaronraimist thoughts on general flow of work.

[hex-m]

@pixlwave Currently we have a manual that tells users to enter the homeserver address so they get redirected to the login-form they know. The homeserver address is not meant to be user-visible so this issue is about enabling us to put the server-part of the MXID into the manual.

In our case we could tell users to "replace @ with : in your e-mail address, prefix it with @ and put that into the Username-field". That way we would teach users about their identifier in the Matrix-world, but it won't make sense to them at this point.

Different organizations have different MXID-creation rules. In some cases it might not be possible to tell their user which MXID they have before they log in and their account is created.

[aaronraimist]

Ideally there would be a way to autofill the server info using something similar to element-hq/element-web#17824 for the first run experience in those types of organizations

[pixlwave]

Thanks for the extra clarity @hex-m, this is very useful to us 👍

Different organizations have different MXID-creation rules. In some cases it might not be possible to tell their user which MXID they have before they log in and their account is created.

In this instance if the user is creating an account, they'll be directed through a different flow before the field to enter a username is shown.

[aaronraimist]

In this instance if the user is creating an account, they'll be directed through a different flow before the field to enter a username is shown.

I'm not sure that is true. In a lot of SSO situations I don't think you ever go down the registration flow. Like with the mozilla.org HS you can only sign in. The server will create your Matrix account if you haven't used it before.

[pixlwave]

I'm not sure that is true. In a lot of SSO situations I don't think you ever go down the registration flow. Like with the mozilla.org HS you can only sign in. The server will create your Matrix account if you haven't used it before.

Sorry, I was meaning within the app itself. The first thing a user will see (as currently designed) is the choice of "Get Started" (I'm new, create an account) or "I already have an account" (login).

[aaronraimist]

Ah I see. I don't think the public has seen those designs.

[pixlwave]

Possibly correct, there is a small amount of information visible in #5159 if you're interested.

[DC7IA]

#4044 seems to be the same

[pixlwave]

Closed by #6469 and the new authentication flow. This should be available in the release made next week, please let us know if you experience any issues when entering a server domain rather than the full URL.