|
|
|
|
---
|
|
|
|
|
title: Room Version 4
|
|
|
|
|
type: docs
|
|
|
|
|
weight: 40
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
This room version builds on [version 3](/rooms/v3) 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](/rooms/v3), 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](/server-server-api#calculating-the-reference-hash-for-an-event) of
|
|
|
|
|
the event encoded using a variation of [Unpadded
|
|
|
|
|
Base64](/appendices#unpadded-base64) which replaces the 62nd and
|
|
|
|
|
63rd characters with `-` and `_` instead of using `+` and `/`. This
|
|
|
|
|
matches [RFC4648's definition of URL-safe
|
|
|
|
|
base64](https://tools.ietf.org/html/rfc4648#section-5). 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" %}}
|
