Add element wellknown for registration_helper_url

[langleyd]

Add element wellknown for registration_helper_url

[cloudflare-workers-and-pages]

Deploying matrix-website with    Cloudflare Pages

Latest commit:	6498056
Status:	✅  Deploy successful!
Preview URL:	https://8ec3fba3.matrix-website.pages.dev
Branch Preview URL:	https://langleyd-add-registration-he.matrix-website.pages.dev

View logs

[MTRNord]

Not directly involved in matrix.org HS affairs, so take this please from a community hat POV and not from a website maintainer POV:

Should the well-known really link to a develop instance? That feels odd. @richvdh already in #2374 (review) voiced concerns in the past about adding semi stable things to the well-known file.

[ara4n]

This PR is being proposed by @langleyd with an Element hat on:

• as a convenience for (new) users on matrix.org to be able to use Element X
• as a workaround given that matrix.org is unable to roll out MAS yet (given the scale of the necessary migration, that it's a big bang migration, and the fact that the OIDC MSCs aren't FCP'd yet).

The fact that the registration helper instance happens to hosted on EW's develop instance right now doesn't feel massively relevant - surely the main contentious bit here is providing an off-spec client-specific convenience on matrix.org.

With (purely) my Matrix hat on: if another client came to the Foundation with a similar ask ("I haven't implemented the old registration flows in my client because it looks like OIDC is coming soon, can I publish a temporary helper app in .well-known/fluffychat or wherever to help my users register on matrix.org meanwhile") then out of pragmatism I'd recommend approving it - especially with an explicit decommission plan if it's a temporary convenience.

So, what I think is missing here is clarification around how long this would last for (to ensure that it doesn't become a weird off-spec defacto registration API that the whole internet ends up depending on). I'd like to propose that this gets deleted on Jan 1 2025 (unless MAS still hasn't landed on matrix.org by then), and then EX will be back on spec and this bodge won't be needed any more.

Given I'm conflicted here, @joshsimmons, your input would be very much appreciated on whether it's okay to pragmatically help EX uptake in this manner (effectively working around the fact that MAS is running late for matrix.org).

N.B. this is blocking submission of the final EXI & EXA builds to their respective app stores, assuming we want users to be able to register on matrix.org via them, and we are running very low on review time.

[MTRNord]

The fact that the registration helper instance happens to hosted on EW's develop instance right now doesn't feel massively relevant - surely the main contentious bit here is providing an off-spec client-specific convenience on matrix.org.

So this makes me actually wonder: What is this actually doing? Does eleX not have a registration form and this is the workaround for that? Or whats the deal with this at all? 🤔

Which then leads me to: Why is this needed in the first place and shouldnt it rather be in eleX? (yes I am questioning the stability of eleX in this too. But this is not an element repo so this is the wrong place to discuss this.)

[joshsimmons]

Provided a clear sunset, and someone who is accountable for following up on it, I'm OK with proceeding.

I am acutely aware of how such a thing could be perceived though, and so want to share my rationale:

The reason for having the matrix.org homeserver is to ease adoption, and it serves an outsized role in facilitating changes across the ecosystem. I think about how major servers played a key role in the rollout of OMEMO within XMPP, and how matrix.org is playing a key role in the move to authenticated media, for example -- granted those two examples aren't client-specific, but the matter at hand might also be reasonably viewed through the lens of supporting transitions on user authentication.

And while I'm not aware of us having done something like this for other clients, I do think it'd be perfectly reasonable to do so.

What makes me uncomfortable is that we don't have guidelines in place for this -- but of course, that's the way of things. There are rarely guidelines or process when something happens for the first time, those things get established in response to emerging patterns. I suspect there's conversation to be had with the Governing Board and the community of client developers about how we reason about this more generally. We don't need to block on that, though.

[ara4n]

(Written with my Element hat on):

What is this actually doing?

This is letting a homeserver recommend a client-specific helper app to aid pre-OIDC registration, for a scenario where the client hasn't implemented native registration (e.g. because it's targeting OIDC and can't burn time implementing soon-to-be-obsolete APIs).

Effectively, it's providing off-spec 'fallback registration', much as specced Matrix already has fallback auth - except there is no intention to spec this, given it's a temporary shim needed only because matrix.org hasn't enabled OIDC yet due to the migration slipping.

Does eleX not have a registration form and this is the workaround for that? Or whats the deal with this at all? 🤔

EX doesn't have native pre-OIDC registration, and this is a workaround for that.

Which then leads me to: Why is this needed in the first place

It is needed so that new users installing EX can register on matrix.org prior to matrix.org enabling OIDC, so they don't have a crap first time user experience, because:

• For consistency with Element, EX defaults to pointing at matrix.org
• Therefore existing users expect their existing matrix.org creds to work (i.e. we can't point it at a different server with OIDC already enabled)
• New users using EX as a way to evaluate Matrix however will be lost unless they can register
• Telling new users "sorry, go register with another Matrix client" is a joke in terms of awful UX, given EX is otherwise production ready - and if matrix.org was already speaking OIDC, registration and all the other auth would work fine.

This means that new users can actually play with EX on its default server (matrix.org) successfully, and accelerate EX uptake (and by extension Matrix uptake) by having a pragmatic EX-specific shim in place to compensate for OIDC not being ready yet on matrix.org, thereby making the ecosystem grow better.

and shouldnt it rather be in eleX?

It is conceptually in EX. It's code provided by Element, specifically for EX clients (although others are welcome to use it given it's FOSS, but it's not been built for any purpose than as a temporary solution to the current problem). It's not related to the Matrix spec; it's just an implementation detail of how EX handles pre-OIDC registration. In an ideal world it could be shipped as a webview distributed in EXI & EXA's codebase itself, but the timings of trying to get EX launched on this Friday (Sept 20th) at the Matrix Conference are such that we need to submit the EXI/EXA apps now, and don't have time to embed a webserver+webapp in them for a temporary registration shim. Instead, the helper app can be hosted serverside, and rather than hardcoding its location in the app (penalising self-hosters), instead we've made the location of the helper app discoverable via .well-known/element (not ./well-known/matrix), in case other deployments want to use the same temporary shim to roll out EX prior to OIDC being ready.

(yes I am questioning the stability of eleX in this too. But this is not an element repo so this is the wrong place to discuss this.)

If you have bug reports about EX stabillity, I'm not sure they're relevant to this discussion - please feel free to file them at github.com/element-hq/element-x-{ios,android}.

Again, if any major Matrix client (e.g. FluffyChat or whoever) turned up saying "we'd like to advertise a client-specific .well-known on matrix.org to help uptake our client, to ease migration until new stable APIs are available on matrix.org", this would be considered reasonable. Just as matrix.org announced the unstable SS proxy as a convenience for clients who implemented SS (EW, EX, iamb, etc) - even though that will get removed in favour of native SSS in future.

[ara4n]

Provided a clear sunset, and someone who is accountable for following up on it, I'm OK with proceeding.

Thanks. Sunset date will be Jan 1 2025 (assuming matrix.org has managed to migrate to OIDC by then). I can be the accountable person to drive the sunset; have put it in my cal.

[joshsimmons]

OK, sounds good. Thank you!