New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jevolk opened this Issue Feb 21, 2018 · 2 comments

Comments

@jevolk
Copy link
Contributor

jevolk commented Feb 21, 2018

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

This comment has been minimized.

Copy link
Member

richvdh commented May 3, 2018

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

This comment has been minimized.

Copy link
Contributor

jevolk commented May 4, 2018

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...

@ara4n ara4n added this to To do (general backlog) in August 2018 r0 via automation Sep 3, 2018

@ara4n ara4n added spec-bug s2s labels Sep 3, 2018

@turt2live turt2live moved this from To do (general backlog) to To do: server-server (prioritized) in August 2018 r0 Sep 3, 2018

@turt2live turt2live moved this from To do: server-server (prioritized) to In review (just the issues) in August 2018 r0 Sep 5, 2018

@richvdh richvdh removed the spec-bug label Sep 7, 2018

@hawkowl hawkowl added this to To Do in Backend Core Team Sep 28, 2018

@hawkowl hawkowl moved this from To Do to To Do S2S r0 in Backend Core Team Sep 28, 2018

@neilisfragile neilisfragile moved this from To Do S2S r0 to In Progress: Planned Project Work in Backend Core Team Sep 28, 2018

@neilisfragile neilisfragile added the r0 P1 label Nov 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment