I'm a bit torn on the "auth check based on the current state of the
room". It can mean multiple things:
1. The state of the room before the homeserver looked at the event at
all. But that means if a message event from a user arrives, but we
didn't see their join event before, we soft fail the message (even
though we would find the join event when going through the auth events
of the event and doing state res)
2. The state of the room after doing state-res with the event and our
previous room state. We need to do this state resolution to find the new
room state anyway, so we could just use the new room state for the auth
check. The problem is that if the incoming event is a membership leave
event, the new room state does not allow another leave event. This is
obviously the wrong option.
3. The state of the room after doing state-res with the state **before**
the event and our previous room state. This will mean a lot more
calculations because we have to run state-res again
We used 2. before and now use 1. again
- power level content override adds to the default event instead of
replacing it
- sending code refactored to make edus possible
- remove presence events when restarting conduit
- remove room_id field from read receipts over /sync
- handle incoming read receipts
- fix array bounds bug in server_server.rs
Jonas Platte
Timo Kösters
hamidreza kalbasi
Gabriel Souza Franco
phesch
Jonathan de Jong