MSC2848: Globally unique event IDs #2848
Conversation
turt2live
added
kind:feature
|
I've doubled the MSC size and made it a whole lot less cryptic in the process (hopefully) - it's still the same proposal, just worded differently. |
| request parameters. Typically this sort of argument would be countered by saying it's making the system | ||
| no worse (which is true), however the justification for making a system no worse instead of better | ||
| tends to fall apart quickly. This MSC does not have an immediate answer against the bandwidth concern | ||
| and favours API consistency and usability, discussed later. |
There was a problem hiding this comment.
TBH the bandwidth concern seems.....off. Even with long event IDs / room IDs, they are still significantly shorter than event contents themself, especially due to all the (edit, reply) fallbacks, when we start signing and whatnot. The length of event ids / room ids is insignificant compared to that.
| identifiers together in events/systems like room upgrades and read receipts. The single example, aside | ||
| from the contested endpoint itself, where this convention is not true is in the `m.in_reply_to` format. | ||
| However, the specification for that `event_id` field also says the referenced event *should* belong | ||
| to the same room as the event being sent, but doesn't have to be. |
There was a problem hiding this comment.
Sounds like replies need fixing that they have to be in the same room, then?
There was a problem hiding this comment.
There's use cases popping up (threading) where it might actually be useful to do cross-room references. Replies might be a natural extension to this.
There was a problem hiding this comment.
one option would be that, if the referenced event is not in the same room, the client has to also specify a room_id in the m.relates_to, next to the event_id.
Co-authored-by: Kitsune Ral <Kitsune-Ral@users.sf.net>
turt2live
added
the
needs-implementation
| should be able to populate the request over federation with the details. When a server is validating | ||
| an event or has just called `/state_ids`, it knows which room ID to expect and thus can supply it. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
I am a bit worried that server implementations are vulnerable to a kind of attack where someone sends an event id but a mismatching room id. Or an event with auth events from a different room.
There was a problem hiding this comment.
That would mean different room_id in the path and in the body?
| @@ -0,0 +1,166 @@ | |||
| # MSC2848: Globally unique event IDs | |||
There was a problem hiding this comment.
The security properties of the event DAG rely on a strong cryptographic hash function to prevent collisions. Namespacing events at best does nothing to improve on this security1, at worst reduces security because now you need to make sure the room ID is correct in multiple places.
Timo alludes to this, but it's a real problem we've had in the past when developing servers. Naively, a developer thinks that if you get a 200 OK from GET /_matrix/federation/v1/room/:roomId/event/:eventId that the :eventId is in the room :roomId, but this is not true. The only place that matters is the event JSON. As such, you have to check the JSON anyway, so what on earth is the point of adding :roomID other than to create a footgun for server developers?
We should be designing good APIs which don't lead developers to write insecure servers. Adding GET /_matrix/federation/v1/room/:roomId/event/:eventId is not a good API.
Footnotes
-
You might think that surely having all events ever under one namespace is bad because there may be an accidental collision at some point. I used to think this too, but humans are really awful at imagining large numbers. 2^256 which SHA-256 uses is an unfathomably large number. Even if you just want to find two inputs which hash to the same value (a collision attack), that requires 2^128 computations. Apparently as of today, bitcoin is currently doing 950 exahashes per second, or 950x10^18 hashes per second, a huge amount with an estimated 0.5% of the entire world's electricity going to it. Even with all this collective effort, it would take around 11.35 billion years just to find one collision. ↩
8 participants
Rendered