From 9475d1aef0b2936bafbe28bad5692055353a7c08 Mon Sep 17 00:00:00 2001 From: richvdh Date: Tue, 27 Sep 2022 19:44:10 +0000 Subject: deploy: 35e9d6a6161c05db491a36e8c194f9cb6b0af073 --- develop/print.html | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'develop/print.html') diff --git a/develop/print.html b/develop/print.html index e2549b6e1c..0a6eab1f9a 100644 --- a/develop/print.html +++ b/develop/print.html @@ -15380,21 +15380,21 @@ in Python, evaluates to True.

event_id global uniqueness

-

In room versions 1 and 2 it's possible to end up with two events with the -same event_id (in the same or different rooms). After room version 3, that -can only happen with a hash collision, which we basically hope will never -happen.

-

There are several places in Synapse and even Matrix APIs like GET /_matrix/federation/v1/event/{eventId} -where we assume that event IDs are globally unique.

-

But hash collisions are still possible, and by treating event IDs as room -scoped, we can reduce the possibility of a hash collision. When scoping -event_id in the database schema, it should be also accompanied by room_id -(PRIMARY KEY (room_id, event_id)) and lookups should be done through the pair -(room_id, event_id).

-

There has been a lot of debate on this in places like -https://github.com/matrix-org/matrix-spec-proposals/issues/2779 and +

event_id's can be considered globally unique although there has been a lot of +debate on this topic in places like +MSC2779 and MSC2848 which -has no resolution yet (as of 2022-09-01).

+has no resolution yet (as of 2022-09-01). There are several places in Synapse +and even in the Matrix APIs like GET /_matrix/federation/v1/event/{eventId} +where we assume that event IDs are globally unique.

+

When scoping event_id in a database schema, it is often nice to accompany it +with room_id (PRIMARY KEY (room_id, event_id) and a FOREIGN KEY(room_id) REFERENCES rooms(room_id)) which makes flexible lookups easy. For example it +makes it very easy to find and clean up everything in a room when it needs to be +purged (no need to use sub-select query or join from the events table).

+

A note on collisions: In room versions 1 and 2 it's possible to end up with +two events with the same event_id (in the same or different rooms). After room +version 3, that can only happen with a hash collision, which we basically hope +will never happen (SHA256 has a massive big key space).

Implementing experimental features in Synapse

It can be desirable to implement "experimental" features which are disabled by default and must be explicitly enabled via the Synapse configuration. This is -- cgit 1.5.1