Clarify how reference hashes are done

specification/rooms/v3.rst

@@ -63,17 +63,8 @@ Event IDs
    should be using. By removing the use of a dedicated event ID, servers are required
    to track the hashes on an event to determine its ID.
 
-The event ID is calculated using the following algorithm. Note that the hashing
+The event ID is the reference hash of the event encoded using `Unpadded Base64`_,
-algorithm used is the same as in previous room versions.
+prefixed with ``$``. A resulting event ID using this approach should look similar to
-
-1. Redact the event.
-2. Remove the `signatures` field from the event.
-3. Serialize the event into `Canonical JSON`_.
-4. Compute the hash of the JSON bytes.
-5. Encode the sha256 hash using `Unpadded Base64`_.
-6. Use the resulting string as the event ID prefixed with ``$``.
-
-A resulting event ID using this approach should look similar to
 ``$CD66HAED5npg6074c6pDtLKalHjVfYb2q4Q3LZgrW6o``.
 
 Event IDs should not be sent over federation to servers when the room uses

specification/server_server_api.rst

@@ -1050,6 +1050,22 @@ been given a redacted version of the event. To enforce this, the receiving
 server should use the redacted copy it calculated rather than the full copy it
 received.
 
+Calculating the reference hash for an event
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The *reference hash* of an event covers the essential fields of an event,
+includuing content hashes. It is calculated as follows.
+
+1. The event is put through the redaction algorithm.
+
+2. The ``signatures``, ``age_ts``, and ``unsigned`` properties are removed
+   from the event, if present.
+
+3. The event is converted into `Canonical JSON`_.
+
+4. A sha256 hash is calculed on the resulting JSON object.
+
+
 Calculating the content hash for an event
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~