- 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".
The state store creates directory structure but the crypto store does
not.
This can lead to confusing errors where we require a directory to be
created by the library user but it gets created by the library.
The previous test only tested using the `EventEmitter`, which missed the
fact that the client was receiving unhoisted events. The test now also
tests the client state to detect this.
Also refactor and document why this hoisting is needed.
This change makes the user_presence test fail because the hoisting
exposes an error encoded into the test's expected result.
Previously, the test expected 2 members in the room at the end. This is
incorrect since one of the members in the test data leaves the room.
However, since the prev_content of state events was previously not
hoisted to the top level, the `membership_change` method would not
notice it and thus not realize the member had left the room. The test
was corrected to expect only a single member in the room.
Another test change was made due to a limitation of EventBuilder: due to
the fact that it makes the test data go through a de/ser cycle, it
cannot easily hoist prev_content to the top level. Because of this, the
tests were change to put prev_content into the top level from the
outset.
The client objects in the sdk accepted an optional session argument at
creation time. If provided this would restore the client into a logged
in state.
Since we need to restore the client state and encryption state at some
point it makes sense to do it when the client transitions into a logged
in state. At the same time we would like to avoid the client creation to
be async.
This introduces a restore_login() method which can be called instead of
the login() method to restore a session.