Step 3.iii of the naming algorithm[0] covers name calculation for empty
rooms; however, it isn't an else condition for steps 3.i and 3.ii. It's a
final conditional in the algorithm before returning the name. The
current implementation treats it as an else condition.
To fix this, use step 3.i and 3.ii to calculate a room name then check
if the user is alone. If alone, return "Empty room (was...)" containing
any former member names. If alone and there aren't any former members,
return "Empty room"
Fixes#133
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
The current implementation uses number of invited and joined members for
"and {} others" message. This assigns rooms with 5 members the name "a,
b, c, and 5 others" suggesting 8 room members. The correct message is
"a, b, c, and 2 others". To get this, subtract number of heroes from
invited and joined member count.
Step 3.ii of the naming algorithm[0] confirms using a remaining users
count in the name.
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
Split `calculate_room_name()` into a high-level function using Matrix
data types and low-level function containing the core logic using plain
Rust data types. Since the low-level function uses simple data types,
unit testing becomes easier.
Step 3.ii of the name calculation algorithm[0] specifies the conditional
as `heroes < invited + joined - 1 AND invited + joined > 1`. However,
current implementation uses `invited + joined - 1 > 1` in the
conditional, which can trigger the conditional if the user is alone.
Correct this by using two variables representing `invited + joined` and
`invited_joined - 1` and updating the conditional. `invited + joined` is
kept as a variable since step 3.iii uses it for its conditional.
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
Usually only room keys and forwarded room keys are sent as encrypted
to-device events, those are specially handled to avoid accepting room
keys coming in unencrypted.
Some clients might send out other events encrypted which might lower
metadata leakage and the spec doesn't disallow it.
This patch handles decrypted events the same way as non-encrypted ones,
we're still special casing the decryption handling to avoid decryption
loops/bombs (i.e. events that are encrypted multiple times).
Johannes Becker
Kévin Commaille
Damir Jelić
timorl
Austin Ray
projectmoon
Jonas Platte
Devin Ragotzy
Devin Ragotzy