Skip to content

[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
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions proposals/4051-create-event-as-room-id.md
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

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.

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

Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Member Author

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.

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:

We include the room ID in the payload, because otherwise the homeserver would be able to change the room a message was sent in.
Link https://spec.matrix.org/v1.11/client-server-api/#mmegolmv1aes-sha2

Copy link
Member Author

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.

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

Copy link
Member

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.

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.