Skip to content
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 class cannot depend on room version #362

Open
KitsuneRal opened this issue Nov 22, 2019 · 0 comments
Open

Event class cannot depend on room version #362

KitsuneRal opened this issue Nov 22, 2019 · 0 comments
Labels
enhancement A feature or change request for the library

Comments

@KitsuneRal
Copy link
Member

Mass redactions MSC introduces a different data structure used for a redaction event in a newer room version. While this data structure is back-compatible with the current one so it's possible to make an all-consuming RedactionEvent with no regard to room versions, it's not possible to use EventFactory to create events of the type depending on the room version in order to implement the MSC in a strict way. Such implementation would only create single-id redaction events (say, RedactionEventV1) for older room versions, while newer room versions would get events with the data structure introduced by the MSC (say, RedactionEventV2).

The biggest problem here is that the current library architecture does not expect event classes to depend on room versions: basically, all event parsing is triggered from SyncJob and Room only incorporates those events into the state or into the timeline - which is not quite correct from the Matrix design standpoint, as different room versions may apply different game rules to events and their format in particular. The right way would probably be if SyncJob delivers a JSON list of unparsed room data; and Room::updateData triggers actual creation of event objects, parameterising EventFactory with the room version. Removing the no more needed SyncRoomData middle-man would slightly optimise sync parsing times (already pretty small compared to the time spent in Room::updateData though).

It's a move away from a dream where SyncJob is auto-generated from CS API YAML; but that's not so much of an issue. Slightly more serious is a Catch-22 due to the room version itself being supplied in a room event; so as the first step of the very first sync parsing for a given room, Room (or even Connection::createRoom? It might be desirable to create different room classes depending on the room version) should dive down into the received JSON, find a piece that corresponds to the m.room.create state event and get the room version out of it.

KitsuneRal added a commit that referenced this issue Nov 22, 2019
Cross-ref: matrix-org/matrix-spec-proposals#2244.
The implementation does not validate the redaction event contents
against a particular room version, accepting both singular event ids
and lists of ids in any room. (In fact, Quotient cannot create objects of
different classes for the same event type depending on the room version -
see #362.) Also, this commit doesn't change Room::redactEvent - it still
only gets a single event id.
KitsuneRal added a commit that referenced this issue Jan 16, 2021
Cross-ref: matrix-org/matrix-spec-proposals#2244.
The implementation does not validate the redaction event contents
against a particular room version, accepting both singular event ids
and lists of ids in any room. (In fact, Quotient cannot create objects of
different classes for the same event type depending on the room version -
see #362.) Also, this commit doesn't change Room::redactEvent - it still
only gets a single event id.
@KitsuneRal KitsuneRal added the enhancement A feature or change request for the library label May 15, 2021
KitsuneRal added a commit that referenced this issue Mar 9, 2024
Cross-ref: matrix-org/matrix-spec-proposals#2244.
The implementation does not validate the redaction event contents
against a particular room version, accepting both singular event ids
and lists of ids in any room. (In fact, Quotient cannot create objects of
different classes for the same event type depending on the room version -
see #362.) Also, this commit doesn't change Room::redactEvent - it still
only gets a single event id.
KitsuneRal added a commit that referenced this issue Mar 9, 2024
Cross-ref: matrix-org/matrix-spec-proposals#2244.
The implementation does not validate the redaction event contents
against a particular room version, accepting both singular event ids
and lists of ids in any room. (In fact, Quotient cannot create objects
of different classes for the same event type depending on the room
version - see #362.) Also, this commit doesn't change
Room::redactEvent() - it still only gets a single event id, pending
MSC4084 (and, respectively, implementation of UIA in the library).
KitsuneRal added a commit that referenced this issue Mar 16, 2024
This implements MSC2174 and MSC2244. The implementation does not
validate the redaction event contents against a particular room version,
accepting both singular event ids and lists of ids in any room.
(In fact, Quotient cannot create objects of different classes for
the same event type depending on the room version - see #362.)
Also, this commit doesn't change Room::redactEvent() - that still gets
a single event id, pending MSC4084 (and, respectively, implementation
of UIA in the library).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A feature or change request for the library
Projects
Status: 0.9 - To Do
Development

No branches or pull requests

1 participant