Event ID's should be hashes and the hashes field should not exist.

[jevolk]

Appendix 4.2.2 "Room IDs and Event IDs" states:

An event has exactly one event ID. An event ID has the format:
$opaque_id:domain

There is no benefit to event ID's being opaque. A vehicle for useful federated information is lost by not standardizing the format of event ID's further than the sigil prefix and domain postfix. The effect of this loss is seen by:

• Having to include additional structure in each event for a hashes object specified in Federation unstable.4.1 "PDU Fields."

• Having to include additional structure in every single prev_event, prev_state, and auth_events list for a hashes object.

As one of several possible suggestions to improve this, the future specifier should consider the following:

$sha256$b58$DtRwDAMJW1BhvSS4SJQB6XZciiBtEQCngLScYaHFvp6yS:matrix.org

[richvdh]

the hashes field is (I learnt last week...) something different to the hashes you get in prev_event and friends.

So we have two hashes, the "content hash", which is based on the complete unredacted event; and the "reference hash", which is based on the redacted event in the same way as the signature.

The hashes field is the content hash. prev_event, prev_state and auth_events all use the reference hash (so that you know you're looking at the right event, even if you are seeing a redacted version of it). So the event id would want to be based on the reference hash.

So, everything you said is true, except that the hashes field still has a (different) purpose and should still exist.

[jevolk]

So the hashes field remains for redactions but we lose the hashes in the prev_*. Then everything except the content is used to create the event_id hash.

Correction: Specifically prev_events and auth_events because prev_state is already dead it seems...

[erikjohnston]

Fixed by #1659 :)