From cb59d5b4d23a3e112099b7d07e24fe53aac199b3 Mon Sep 17 00:00:00 2001 From: MadLittleMods Date: Fri, 2 Sep 2022 19:06:22 +0000 Subject: deploy: 877bdfa889fa07d09f385df297a9282d51d50dae --- develop/development/database_schema.html | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'develop/development/database_schema.html') diff --git a/develop/development/database_schema.html b/develop/development/database_schema.html index 8bbd1c46da..901808363e 100644 --- a/develop/development/database_schema.html +++ b/develop/development/database_schema.html @@ -308,6 +308,22 @@ default value is the string "FALSE" - wh 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 +MSC2848 which +has no resolution yet (as of 2022-09-01).

-- cgit 1.5.1