deploy: 877bdfa889

develop/development/database_schema.html

@@ -308,6 +308,22 @@ default value is the <strong>string</strong> <code>&quot;FALSE&quot;</code> - wh
 in Python, evaluates to <code>True</code>.</p>
 </li>
 </ul>
+<h2 id="event_id-global-uniqueness"><a class="header" href="#event_id-global-uniqueness"><code>event_id</code> global uniqueness</a></h2>
+<p>In room versions <code>1</code> and <code>2</code> it's possible to end up with two events with the
+same <code>event_id</code> (in the same or different rooms). After room version <code>3</code>, that
+can only happen with a hash collision, which we basically hope will never
+happen.</p>
+<p>There are several places in Synapse and even Matrix APIs like <a href="https://spec.matrix.org/v1.1/server-server-api/#get_matrixfederationv1eventeventid"><code>GET /_matrix/federation/v1/event/{eventId}</code></a>
+where we assume that event IDs are globally unique.</p>
+<p>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
+<code>event_id</code> in the database schema, it should be also accompanied by <code>room_id</code>
+(<code>PRIMARY KEY (room_id, event_id)</code>) and lookups should be done through the pair
+<code>(room_id, event_id)</code>.</p>
+<p>There has been a lot of debate on this in places like
+https://github.com/matrix-org/matrix-spec-proposals/issues/2779 and
+<a href="https://github.com/matrix-org/matrix-spec-proposals/pull/2848">MSC2848</a> which
+has no resolution yet (as of 2022-09-01).</p>
 
                     </main>
 

develop/print.html

@@ -15161,6 +15161,22 @@ default value is the <strong>string</strong> <code>&quot;FALSE&quot;</code> - wh
 in Python, evaluates to <code>True</code>.</p>
 </li>
 </ul>
+<h2 id="event_id-global-uniqueness"><a class="header" href="#event_id-global-uniqueness"><code>event_id</code> global uniqueness</a></h2>
+<p>In room versions <code>1</code> and <code>2</code> it's possible to end up with two events with the
+same <code>event_id</code> (in the same or different rooms). After room version <code>3</code>, that
+can only happen with a hash collision, which we basically hope will never
+happen.</p>
+<p>There are several places in Synapse and even Matrix APIs like <a href="https://spec.matrix.org/v1.1/server-server-api/#get_matrixfederationv1eventeventid"><code>GET /_matrix/federation/v1/event/{eventId}</code></a>
+where we assume that event IDs are globally unique.</p>
+<p>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
+<code>event_id</code> in the database schema, it should be also accompanied by <code>room_id</code>
+(<code>PRIMARY KEY (room_id, event_id)</code>) and lookups should be done through the pair
+<code>(room_id, event_id)</code>.</p>
+<p>There has been a lot of debate on this in places like
+https://github.com/matrix-org/matrix-spec-proposals/issues/2779 and
+<a href="https://github.com/matrix-org/matrix-spec-proposals/pull/2848">MSC2848</a> which
+has no resolution yet (as of 2022-09-01).</p>
 <div style="break-before: page; page-break-before: always;"></div><h1 id="implementing-experimental-features-in-synapse"><a class="header" href="#implementing-experimental-features-in-synapse">Implementing experimental features in Synapse</a></h1>
 <p>It can be desirable to implement &quot;experimental&quot; features which are disabled by
 default and must be explicitly enabled via the Synapse configuration. This is