3 ms·

> The real crucial missing piece in Element X compared to Element is key/device/session/verification management and insights. Hmmmmmmm. Are you running EX agai

> The real crucial missing piece in Element X compared to Element is key/device/session/verification management and insights. Hmmmmmmm. Are you running EX against an older homeserver which doesn't have matrix-authentication-service and native OIDC? On my EX on matrix.org, I have "Manage account" and "manage devices" options in Settings which takes me through to manage the current devices and sessions. In terms of managing verification and cross-signing, the reason there's no longer explicit controls for verifying your sessions is that the model going forwards is that users must verify all their devices: in future any devices not verified by the user will be excluded from conversations. EX does this by forcing you to verify when you login (and Element Classic also does this). In other words, the missing functionality you're talking about is deliberately removed because it was never a good idea in the first place - it was a backwards-compatibility side-effect of the way that encryption and cross-signing incrementally landed in the first place. Now, we're moving towards a model like Signal or iMessage or any other E2EE messenger where all your devices should be verified and cross-signed and trusted automatically, and so the UX reflects that. Obviously if you have other Matrix clients or bots flying around which don't verify by default, this then becomes tricky, but it's very unclear that the right solution is to bog EX's UI down with the fragility and complexity of the old apps. If you're a poweruser who needs to juggle dangerous Matrix arcana like unverified devices, then the right solution probably is to use a poweruser app to do so. Meanwhile, we want EX's UI to be simple and just work out of the box, rather than getting tangled up with these complexities.

baobun 1y ago
This all assumes that things are always consistent, free of bugs and clears throat database issues (yeah we got hit by that too - I don't see how we'd been able to troubleshoot and salvage it as well as we managed if we had been on EX only - MAS or not).... The problematic situations that have otherwise crept up are generally devices that all think they're independently verified but somehow get out of sync for any nuber of arcane or archaic reasons. Reset flows are another pain point. And yeah, I think our homeserver will not adopt MAS/OIDC - requiring a separate service and client (web browser) for account managament certainly feels like a regression. I see why it makes sense for matrix.org and the customers of Element but making EX depend on MAS for full functionality was not something I expected going in.
- Arathorn 1y ago
  I suspect we'll end up bundling MAS inside Synapse for situations like this - trying to limp along on the legacy auth stack when stuff like 2FA/MFA/QR-login etc are all handled by MAS/OIDC will be painful.
  - baobun 1y ago
    Still, keys and sessions should all be managable from the client and not depend on a separate server/browser flow, no? What I'm talking about so far is basically orthogonal to user-server authn/authz flows and mechanics (the scopes of MAS and OIDC). Tightly coupling user-user authn to client-server authz doesn't seem ideal.
    - Arathorn 1y ago
      user-user authn is indeed orthogonal to client-server authz. For authenticating your own devices in EX, you are forced to verify them at login. If you have other devices flying around that aren’t verified then you have to use a different app to unpick the mess - in a Matrix 2.0 world it should not be possible to get into that mess (even if the server DB rolls back). So it’s only if you have 1.x clients hanging around that you need this… at which point you might as well use the 1.x clients to unpick the mess if needed. For verifying other users - EX should support that well as the classic apps ever did.

baobun 1y ago

This all assumes that things are always consistent, free of bugs and clears throat database issues (yeah we got hit by that too - I don't see how we'd been able to troubleshoot and salvage it as well as we managed if we had been on EX only - MAS or not).... The problematic situations that have otherwise crept up are generally devices that all think they're independently verified but somehow get out of sync for any nuber of arcane or archaic reasons. Reset flows are another pain point. And yeah, I think our homeserver will not adopt MAS/OIDC - requiring a separate service and client (web browser) for account managament certainly feels like a regression. I see why it makes sense for matrix.org and the customers of Element but making EX depend on MAS for full functionality was not something I expected going in.

Arathorn 1y ago
I suspect we'll end up bundling MAS inside Synapse for situations like this - trying to limp along on the legacy auth stack when stuff like 2FA/MFA/QR-login etc are all handled by MAS/OIDC will be painful.
- baobun 1y ago
  Still, keys and sessions should all be managable from the client and not depend on a separate server/browser flow, no? What I'm talking about so far is basically orthogonal to user-server authn/authz flows and mechanics (the scopes of MAS and OIDC). Tightly coupling user-user authn to client-server authz doesn't seem ideal.
  - Arathorn 1y ago
    user-user authn is indeed orthogonal to client-server authz. For authenticating your own devices in EX, you are forced to verify them at login. If you have other devices flying around that aren’t verified then you have to use a different app to unpick the mess - in a Matrix 2.0 world it should not be possible to get into that mess (even if the server DB rolls back). So it’s only if you have 1.x clients hanging around that you need this… at which point you might as well use the 1.x clients to unpick the mess if needed. For verifying other users - EX should support that well as the classic apps ever did.