You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec-proposals/content/rooms/v4.md

2.3 KiB

title type weight
Room Version 4 docs 40

This room version builds on version 3 using a different encoding for event IDs.

Client considerations

This room version changes the format form event IDs sent to clients. Clients should already be treating event IDs as opaque identifiers, and should not be concerned with the format of them. Clients should still encode the event ID when including it in a request path.

Clients should expect to see event IDs changed from the format of $randomstring:example.org to something like $Rqnc-F-dvnEYJTyHq_iKxU2bZ1CI92-kuZq3a5lr5Zg (note the lack of domain).

Server implementation components

{{% boxes/warning %}} The information contained in this section is strictly for server implementors. Applications which use the Client-Server API are generally unaffected by the intricacies contained here. The section above regarding client considerations is the resource that Client-Server API use cases should reference. {{% /boxes/warning %}}

Room version 4 uses the same algorithms defined in room version 3, however using URL-safe base64 to generate the event ID.

Event IDs

{{% boxes/rationale %}} Room version 3 generated event IDs that were difficult for client implementations which were not encoding the event ID to function in those rooms. It additionally raised concern due to the / character being interpretted differently by some reverse proxy software, and generally made administration harder. {{% /boxes/rationale %}}

The event ID is the reference hash of the event encoded using a variation of Unpadded Base64 which replaces the 62nd and 63rd characters with - and _ instead of using + and /. This matches RFC4648's definition of URL-safe base64. Event IDs are still prefixed with $ and may result in looking like $Rqnc-F-dvnEYJTyHq_iKxU2bZ1CI92-kuZq3a5lr5Zg.

Just like in room version 3, event IDs should not be sent over federation to servers when the room uses this room version. On the receiving end of an event, the server should compute the relevant event ID for itself. Room version 3 also changes the format of auth_events and prev_events in a PDU.

{{% definition path="api/server-server/definitions/pdu_v4" %}}