-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC1597: Better spec for matrix identifiers #1597
base: old_master
Are you sure you want to change the base?
Conversation
|
For links: room aliases are at #1608 |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why 10 and not 1 as a minimum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cross-linking matrix-org/matrix-spec#503 (comment) for updated state of the world.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IDs and must therefore be a subset of that grammar. | |
IDs and must therefore be a subset of the `tok` grammar. |
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.