MSC4108 - the flow where an existing session shows a QR code and a new device scans it to sign in and be verified in one step. Element X leads with it.
Not to be confused with what exists: matrixVerificationQrCode is MSC1544, which verifies a device that has already signed in. The login flow is a different MSC and is absent.
Worth noting that the Discord backend already does its own cross-device QR login, so the window has the shape of this flow already.
MSC4108 - the flow where an existing session shows a QR code and a new device scans it to sign in and be verified in one step. Element X leads with it.
Not to be confused with what exists: `matrixVerificationQrCode` is MSC1544, which verifies a device that has *already* signed in. The login flow is a different MSC and is absent.
Worth noting that the Discord backend already does its own cross-device QR login, so the window has the shape of this flow already.
Not done, and here is why, measured rather than assumed.
MSC4108 is built on OIDC-native auth: the new device is signed in through an OAuth 2.0 device authorization grant carried over a rendezvous channel, with an ECIES secure channel between the two devices. It is not a variant of m.login.token — a homeserver without MSC2965 auth metadata and without a rendezvous endpoint cannot do it however willing the client is.
Probed against matrix.poast.org, the only homeserver available for testing here:
matrix.salastil.com cannot federate and is mid-move from Conduit to tuwunel, so it is not a second opinion.
So the flow cannot be completed or exercised against anything we have. Several hundred lines of ECIES channel, QR payload codec and device-grant plumbing written blind is the kind of work that looks finished and is not — the failure would surface the first time a real device scanned a real code.
Left open. The spec probe now reports all four of those answers in one line, so the moment a homeserver in use supports it, that is one command away. The existing matrixVerificationQrCode (MSC1544, verifying a device that has already signed in) is unaffected and still works.
Everything else from the Matrix coverage review — #214 through #221 and #223 through #229 — is finished and closed.
Not done, and here is why, measured rather than assumed.
MSC4108 is built on OIDC-native auth: the new device is signed in through an **OAuth 2.0 device authorization grant** carried over a **rendezvous channel**, with an ECIES secure channel between the two devices. It is not a variant of `m.login.token` — a homeserver without MSC2965 auth metadata and without a rendezvous endpoint cannot do it however willing the client is.
Probed against matrix.poast.org, the only homeserver available for testing here:
- `/_matrix/client/versions` advertises `org.matrix.msc4108: false`
- `/_matrix/client/v1/auth_metadata` — 404
- `/_matrix/client/unstable/org.matrix.msc2965/auth_metadata` — 404
- `/_matrix/client/unstable/org.matrix.msc4108/rendezvous` — 404
matrix.salastil.com cannot federate and is mid-move from Conduit to tuwunel, so it is not a second opinion.
So the flow cannot be completed or exercised against anything we have. Several hundred lines of ECIES channel, QR payload codec and device-grant plumbing written blind is the kind of work that looks finished and is not — the failure would surface the first time a real device scanned a real code.
Left open. The spec probe now reports all four of those answers in one line, so the moment a homeserver in use supports it, that is one command away. The existing `matrixVerificationQrCode` (MSC1544, verifying a device that has *already* signed in) is unaffected and still works.
Everything else from the Matrix coverage review — #214 through #221 and #223 through #229 — is finished and closed.
MSC4108 carries the device grant over a rendezvous channel, and there is no rendezvous endpoint on matrix.org in either spelling. So the QR flow still cannot be completed or exercised, and the original reason for leaving this open stands: several hundred lines of ECIES channel and QR payload codec written blind would fail the first time a real device scanned a real code.
Worth splitting out: the device authorization grant on its own is now implementable and testable. That is the flow where this client shows a short code and the person approves it at account.matrix.org in a browser they are already signed in to - no password typed into moho, no QR, and no rendezvous channel. It is not what this issue asks for, but it is most of what somebody wants from it, and unlike MSC4108 it can be verified end to end today.
Re-probed against matrix.org, which is OIDC-native. The answer has moved, but not far enough.
**What matrix.org does have:**
- `/_matrix/client/v1/auth_metadata` - 200, stable, no longer the unstable MSC2965 spelling
- issuer `https://account.matrix.org/`
- `device_authorization_endpoint`, and `urn:ietf:params:oauth:grant-type:device_code` among `grant_types_supported`
So the OAuth half that the earlier probe found missing on poast now exists somewhere we can reach.
**What it still does not have:**
- `/_matrix/client/versions` advertises `org.matrix.msc4108: false`
- `/_matrix/client/v1/rendezvous` - 404
- `/_matrix/client/unstable/org.matrix.msc4108/rendezvous` - 404
MSC4108 carries the device grant over a rendezvous channel, and there is no rendezvous endpoint on matrix.org in either spelling. So the QR flow still cannot be completed or exercised, and the original reason for leaving this open stands: several hundred lines of ECIES channel and QR payload codec written blind would fail the first time a real device scanned a real code.
**Worth splitting out:** the device authorization grant on its own is now implementable and testable. That is the flow where this client shows a short code and the person approves it at `account.matrix.org` in a browser they are already signed in to - no password typed into moho, no QR, and no rendezvous channel. It is not what this issue asks for, but it is most of what somebody wants from it, and unlike MSC4108 it can be verified end to end today.
Salastil
added this to the v1.0 milestone 2026-10-02 00:00:02 -04:00
Salastil
removed this from the v1.0 milestone 2026-10-04 15:51:25 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
MSC4108 - the flow where an existing session shows a QR code and a new device scans it to sign in and be verified in one step. Element X leads with it.
Not to be confused with what exists:
matrixVerificationQrCodeis MSC1544, which verifies a device that has already signed in. The login flow is a different MSC and is absent.Worth noting that the Discord backend already does its own cross-device QR login, so the window has the shape of this flow already.
Not done, and here is why, measured rather than assumed.
MSC4108 is built on OIDC-native auth: the new device is signed in through an OAuth 2.0 device authorization grant carried over a rendezvous channel, with an ECIES secure channel between the two devices. It is not a variant of
m.login.token— a homeserver without MSC2965 auth metadata and without a rendezvous endpoint cannot do it however willing the client is.Probed against matrix.poast.org, the only homeserver available for testing here:
/_matrix/client/versionsadvertisesorg.matrix.msc4108: false/_matrix/client/v1/auth_metadata— 404/_matrix/client/unstable/org.matrix.msc2965/auth_metadata— 404/_matrix/client/unstable/org.matrix.msc4108/rendezvous— 404matrix.salastil.com cannot federate and is mid-move from Conduit to tuwunel, so it is not a second opinion.
So the flow cannot be completed or exercised against anything we have. Several hundred lines of ECIES channel, QR payload codec and device-grant plumbing written blind is the kind of work that looks finished and is not — the failure would surface the first time a real device scanned a real code.
Left open. The spec probe now reports all four of those answers in one line, so the moment a homeserver in use supports it, that is one command away. The existing
matrixVerificationQrCode(MSC1544, verifying a device that has already signed in) is unaffected and still works.Everything else from the Matrix coverage review — #214 through #221 and #223 through #229 — is finished and closed.
Re-probed against matrix.org, which is OIDC-native. The answer has moved, but not far enough.
What matrix.org does have:
/_matrix/client/v1/auth_metadata- 200, stable, no longer the unstable MSC2965 spellinghttps://account.matrix.org/device_authorization_endpoint, andurn:ietf:params:oauth:grant-type:device_codeamonggrant_types_supportedSo the OAuth half that the earlier probe found missing on poast now exists somewhere we can reach.
What it still does not have:
/_matrix/client/versionsadvertisesorg.matrix.msc4108: false/_matrix/client/v1/rendezvous- 404/_matrix/client/unstable/org.matrix.msc4108/rendezvous- 404MSC4108 carries the device grant over a rendezvous channel, and there is no rendezvous endpoint on matrix.org in either spelling. So the QR flow still cannot be completed or exercised, and the original reason for leaving this open stands: several hundred lines of ECIES channel and QR payload codec written blind would fail the first time a real device scanned a real code.
Worth splitting out: the device authorization grant on its own is now implementable and testable. That is the flow where this client shows a short code and the person approves it at
account.matrix.orgin a browser they are already signed in to - no password typed into moho, no QR, and no rendezvous channel. It is not what this issue asks for, but it is most of what somebody wants from it, and unlike MSC4108 it can be verified end to end today.