matrix-spec-proposals/content/rooms/v4.md

---
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" %}}