We need to re-consider splitting users into alias & underlying opaque ID (SPEC-152)

[matrix-org]

We need to re-consider splitting users into alias & underlying opaque ID (SPEC-152)

[matrixbot]

Jira watchers: @ara4n @richvdh

[matrixbot]

Links exported from Jira:

relates to https://github.com/matrix-org/matrix-doc/issues/586
relates to SPEC-62
relates to SPEC-390

[matrixbot]

One thing that may be worth considering is making the ^opaque_id the hash of some variety of key, and aliases are inserted as Signed(alias || separator || opaque_id), such that the signature is with the key that the opaque_id is the hash of. This avoids the possibility of mappings that the opaque_id's user didn't consent to (both are present in the signature, the id/sig pair is self-certifying), and may be possible to link to e2e, such that keys for an ID are also self-certifying.

-- Alex Elsayed

[matrixbot]

One other option - rather than '^{' use '_{' - all of the benefits of '}}' apply, with the added bonus that using '' to mean "something user-specific" is a long-standing convention (Unix, mapping public_html, etc).

-- Alex Elsayed

[matrixbot]

Further arguments in favor of '~':

• It's an explicit unreserved character in the URI spec, cutting back on the escaping needed
• ^ is a shell metacharacter that causes execution of commands from history

-- Alex Elsayed

[matrixbot]

Why do we want to break the world by using ^ as the sigil for opaque IDs, rather than using the current @​user_ids and layering aliases on top?

-- @richvdh

[matrixbot]

Isn't it the other way around? My understanding was that opaque IDs would be opaque in the sense of https://github.com/matrix-org/matrix-doc/issues/666; the current @​-form mxids would transparently grow an opaque-id backing and upgrade to aliases.

-- Alex Elsayed

[matrixbot]

This bug is quite stale now - who knows if we'd use public keys as the underlying identifier (discovered by a DHT or whatever) or a ^user:domain or a ~user:domain or whatever. I'd be anxious that we keep @​user:domain as public-facing user IDs for compatibility with existing conversations etc - and it would then be an indirection through to the underlying ID (which could be hosted on multiple HSes etc). Effectively the @​user:domain ID could become a 3PID mapping. Anyway, this is all completely not designed yet and up in the air, other than the desire for decentralised accounts.

See https://github.com/matrix-org/GSoC/blob/master/IDEAS.md#decentralised-accounts for other thoughts.

-- @ara4n