-
Notifications
You must be signed in to change notification settings - Fork 57
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
Labels
enhancement
A feature or change request for the library
Comments
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
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
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 useEventFactory
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
andRoom
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 ifSyncJob
delivers a JSON list of unparsed room data; andRoom::updateData
triggers actual creation of event objects, parameterisingEventFactory
with the room version. Removing the no more neededSyncRoomData
middle-man would slightly optimise sync parsing times (already pretty small compared to the time spent inRoom::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 evenConnection::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 them.room.create
state event and get the room version out of it.The text was updated successfully, but these errors were encountered: