Redact message events according to spec and ruma types. Remove content
using events redact() method and insert the redacting event into the
event being redacted.
High-level summary of changes:
- Rewrite the disambiguation algorithm to simplify it.
- Fixes to state tracking, e.g. use `state_key` instead of `user_id` when
determining which member an event is acting on.
- Changes to `RoomMember`:
* Make `RoomMember` "dumber" and don't let it mutate itself. This came about
primarily because `update_profile` cannot live on `RoomMember` because it
needs some information from `Room`. The other few mutating methods then
looked odd so it seemed best to move them to `Room` so that the room takes
care of updating its members.
* Each `RoomMember` now contains all information to calculate its set of
names:
+ `.name()` (short/ergonomic but potentially ambiguous),
+ `.unique_name()` (unique but may be contain MXID when not necessary),
+ `.disambiguated_name()` (shortest possible while being unique).
- Add some logging using the `tracing` crate.
- Improvements to `EventBuilder`:
* Add a docstring.
* Make it clear itself when building a sync response so the same builder can
be reused for later sync responses.
- A few tests.
This makes more sense as all the required information is now available
on `RoomMember`. We also don't have to handle the case of the missing
member since now you have to actually get a `RoomMember` before you can
ask for their name.
- use `state_key` instead of `user_id` to determine which member is
affected by the event
- assign state directly from the event in `add_member` instead of using
`membership_change`
- expand/fix docstrings
- add some logging
The new algorithm is simpler. Instead of tracking a list of
disambiguated display names in `Room`, we instead track the display name
ambiguity status in `RoomMember`. This allows a client to generate the
correct name for a member using solely the information available in
`RoomMember`.
The disambiguation algorithm itself now only calculates the set of members
whose ambiguity status had changed instead of producing disambiguated
display names for everyone affected. This is called on each room entry
(join or invite), room entry and profile change, and the updates are
propagated to the affected `RoomMember`s.
Ruma can't currently handle an event with the wrong event content type.
When replacing the MessageEventStub's content it automatically
serializes as "m.room.redaction".
Damir Jelić
Denis Kasak
Jonas Platte
Devin R
Dan Enman