MSC1597: Better spec for matrix identifiers#1597
Conversation
|
|
|
For links: room aliases are at #1608 |
|
since the state of this MSC was causing confusion, I have turned this issue into a PR so that it matches the modern system. I also don't think it has had what would qualify for an FCP nowadays, since it hasn't been implemented; I've updated the labels accordingly. |
|
note that a lot of discussion on this proposal took place on #1598. |
... to match the characters which do not need URL-encoding
|
|
||
| Additional proposal: | ||
|
|
||
| > Device IDs must not exceed 31 characters in length. |
There was a problem hiding this comment.
I counter-propose that at least 36 characters should be allowed so that - separated UUIDs can be use.
Furthermore adopting a minimum length of 10 characters could be sensible
There was a problem hiding this comment.
why 10 and not 1 as a minimum?
There was a problem hiding this comment.
My thinking was that it would encourage a degree of uniqueness.
| ### Call IDs | ||
|
|
||
| [Spec](https://matrix.org/docs/spec/client_server/unstable.html#m-call-invite) | ||
|
|
||
| These are only used within the body of `m.call.*` events, as far as I am | ||
| aware. They should be unique within the lifetime of a room. (Some | ||
| implementations currently treat them as globally unique, but that is considered | ||
| an implementation bug.) | ||
|
|
||
| [matrix-js-sdk](https://github.com/matrix-org/matrix-js-sdk/blob/4d310cd4618db4e98a8e6b5eb812480102ee4dee/src/webrtc/call.js#L72) uses `c[0-9.]{32}`. | ||
| [matrix-android-sdk](https://github.com/matrix-org/matrix-android-sdk/blob/5c6f785e53632e7b6fb3f3859a90c3d85b040e7f/matrix-sdk/src/main/java/org/matrix/androidsdk/call/MXWebRtcCall.java#L221) uses `c[0-9]{13}`. | ||
|
|
||
| Additional proposal: | ||
|
|
||
| > Call IDs should be long enough to make clashes unlikely. |
There was a problem hiding this comment.
something similar has now been specced at https://spec.matrix.org/v1.7/client-server-api/#grammar-for-voip-ids.
|
Thoughts on also moving megolm session_id values to being url-safe base64? Same reasoning as excluding the slash from user ids. |
The reason for user ids is that user IDs appear in the path of REST endpoints, but I don't think the same is true of megolm session IDs? Megolm session IDs are base64-encoded ed25519 public keys. Base64-encoded ed25519 keys are used a lot in the protocol, and normally don't use url-safe encoding. |
They appear in the room_key backup related URLs unfortunately: https://spec.matrix.org/latest/client-server-api/#get_matrixclientv3room_keyskeysroomidsessionid |
Oh hrm, right. We've got some other changes planned for megolm (cf matrix-org/matrix-spec#1557) so this might be a thing to consider at the same time. |
|
|
||
| > Call IDs should be long enough to make clashes unlikely. | ||
|
|
||
| ### Media IDs |
There was a problem hiding this comment.
cross-linking matrix-org/matrix-spec#503 (comment) for updated state of the world.
There was a problem hiding this comment.
With exclusive appservice namespaces, it is currently possible for appservices that are registered to unknowingly overlap with existing user IDs, room aliases, (and possibly in the future, media IDs). Ideally there should be some chars or some sigil reserved solely for usage with appservices to prevent this issue in the future.
So perhaps this could be addressed here.
|
|
||
| They are used between users and across federation for E2E and to-device | ||
| messages. They need to be unique for a particular user. They also appear in key | ||
| IDs and must therefore be a subset of that grammar. |
There was a problem hiding this comment.
I think this means that the Device ID would appear within the tok part of the key_id defined previously. If so, could this sentence be updated to clarify this?
|
|
||
| They are used between users and across federation for E2E and to-device | ||
| messages. They need to be unique for a particular user. They also appear in key | ||
| IDs and must therefore be a subset of that grammar. |
There was a problem hiding this comment.
| IDs and must therefore be a subset of that grammar. | |
| IDs and must therefore be a subset of the `tok` grammar. |
|
7 years later, I don't think this is ever likely to land. More likely, we would create separate MSCs to address specific identifier types. |
Rendered: https://github.com/matrix-org/matrix-doc/blob/rav/proposals/id_grammar/proposals/1597-id-grammar.md
A proposal to clarify a bunch of rules about what is and is not allowed in various identifiers.
This is intended to fix matrix-org/matrix-spec#174, matrix-org/matrix-spec#175, matrix-org/matrix-spec#278 and matrix-org/matrix-spec#290.