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 <[email protected]>
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?
Rendered