From 66dc75ec0555669b38b5446df40ddadcd76ef70c Mon Sep 17 00:00:00 2001 From: erikjohnston Date: Wed, 14 Sep 2022 20:25:14 +0000 Subject: deploy: 80bb098d8775cc2ad1bf5abd150913577e643481 --- latest/development/database_schema.html | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) (limited to 'latest/development/database_schema.html') diff --git a/latest/development/database_schema.html b/latest/development/database_schema.html index f6b579226e..901808363e 100644 --- a/latest/development/database_schema.html +++ b/latest/development/database_schema.html @@ -76,7 +76,7 @@ @@ -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