-
Notifications
You must be signed in to change notification settings - Fork 399
[WIP] MSC4051: Using the create event as the room ID #4051
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
Draft
turt2live
wants to merge
2
commits into
main
Choose a base branch
from
travis/msc/room-id-is-create-event
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
# MSC4051: Using the create event as the room ID | ||
|
||
Matrix has a dedicated [room ID grammar](https://spec.matrix.org/v1.8/appendices/#room-ids) which | ||
aims to ensure there is a single identifier representing the room. This is done by using the origin | ||
server's name in the ID, which often leads to confusion among users and admins that the listed server | ||
"owns" the room. | ||
|
||
**TODO(TR): Insert security context.** | ||
|
||
This proposal uses the create event's event ID as the room ID instead, ensuring there is a fully | ||
unique value that can be used. | ||
|
||
## Proposal | ||
|
||
A new room version is established to accommodate the event format, redaction, and identifier changes | ||
from this proposal. | ||
|
||
The `room_id` field is removed from events, and no longer protected from redaction. The create event's | ||
reference hash is used and prefixed with `!` when a room ID is needed (such as in API endpoints). | ||
|
||
The create event is already selected as an auth event for all events in the room, allowing servers to | ||
easily determine which room ID the sent event belongs. | ||
|
||
Events served over the client-server API MUST still include a `room_id`. Clients should already be | ||
treating the value as opaque, and therefore should not break when encountering the serverless value. | ||
|
||
**TODO(TR): Maybe go into *a bit* more detail...** | ||
|
||
## Potential issues | ||
|
||
**TODO(TR): This** | ||
|
||
## Alternatives | ||
|
||
**TODO(TR): This** | ||
|
||
## Security considerations | ||
|
||
**TODO(TR): This** | ||
|
||
## Unstable prefix | ||
|
||
**TODO(TR): This** | ||
|
||
## Dependencies | ||
|
||
As of writing, this MSC is being evaluated as a potential feature for use in the MIMI working group at | ||
the IETF through the Spec Core Team's efforts. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
room_id
is still to be kept in the encrypted payload of E2EE messages, right ? I think it should probably be mentioned in the MSC, perhaps as a security consideration.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.
What do you mean? Clients don't encrypt the room id when sending events
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.
They do: https://spec.matrix.org/v1.11/client-server-api/#mmegolmv1aes-sha2
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.
Ok, then thats probably hidden by the various view source implementations in Element X Android / Android and Web
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.
Clarification on what the concern is here would be appreciated. I'm having trouble parsing both the original comment and replies.
Links to existing spec are helpful.
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.
If I understand the proposal right, nowhere in it does it state to keep room_id for events outgoing from the client inside m.room.encrypted, to address:
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.
This MSC doesn't really operate at that layer, so would not affect encryption. It only affects the federation and room behaviour characteristics.
I can try to make this clearer, but clients should see no material difference before and after this MSC.
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.
Yea, I would suggest to make it clearer in the MSC exactly which usages of room_id it affects
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 my crypto hat on, since has security implications, I think it would be worth clarifying somewhere that this MSC doesn't affect the encrypted payload.