Skip to content
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

Open
wants to merge 7 commits into
base: old_master
Choose a base branch
from

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Aug 19, 2020

@richvdh richvdh added proposal-wip proposal A matrix spec change proposal labels Aug 29, 2018
@richvdh
Copy link
Member Author

richvdh commented Aug 29, 2018

please take comments to #1598.

@matrix-org matrix-org locked and limited conversation to collaborators Aug 29, 2018
@richvdh
Copy link
Member Author

richvdh commented Aug 29, 2018

For links: room aliases are at #1608

@matrix-org matrix-org unlocked this conversation Aug 19, 2020
@richvdh
Copy link
Member Author

richvdh commented Aug 19, 2020

note that a lot of discussion on this proposal took place on #1598.

proposals/1597-id-grammar.md Outdated Show resolved Hide resolved
... to match the characters which do not need URL-encoding
@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
@neilisfragile neilisfragile mentioned this pull request Mar 1, 2022
12 tasks
@turt2live turt2live changed the title Better spec for matrix identifiers MSC1597: Better spec for matrix identifiers Jul 19, 2022

Additional proposal:

> Device IDs must not exceed 31 characters in length.
Copy link
Member

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

Copy link
Member

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?

Copy link
Member

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.

@richvdh
Copy link
Member Author

richvdh commented Oct 12, 2022

Fixes matrix-org/matrix-spec#503

Comment on lines +164 to +178
### 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.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bradtgmurray
Copy link

Thoughts on also moving megolm session_id values to being url-safe base64? Same reasoning as excluding the slash from user ids.

@richvdh
Copy link
Member Author

richvdh commented Jun 7, 2023

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.

@bradtgmurray
Copy link

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

@richvdh
Copy link
Member Author

richvdh commented Jun 7, 2023

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
Copy link
Member

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.

Copy link
Contributor

@Kladki Kladki Apr 16, 2024

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.
Copy link
Member

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
IDs and must therefore be a subset of that grammar.
IDs and must therefore be a subset of the `tok` grammar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Grammar for completely opaque IDs (SPEC-388)
6 participants