silikonfactor.blogg.se

#Im encrypto update#
#Im encrypto android#

I've got 3 logged in accounts (2x android, 1x desktop/flatpak).

I'm uncertain, but this looks closest to a fatal encryption issue I've encountered recently, so I'll chip in instead of creating new issue (unless instructed differently): The settings screen should also reflect that state, and offer a action/button for admin that would fix encryption) We should no more see ignored encryption tiles

The encryption tile in timeline should also reflect the state

#Im encrypto android#

^ Sample on android (copy and icon to be defined)Ī specific icon should be displayed on top bar to reflect misconfigured state Should use the same ux system as when the user can't send due to power levels (hiding / disabling text composer): Each event would fail to send, so better to deny sending) UX to deny sending when encryption is misconfigured (FTR currently on web, if encryption is using an unknwon algorithm sending in the room would be broken. => If a follow up valid m.room.encryption with correct alg is received, client should repair the room and allow sending. If a valid `m.room.encryption` is received with unknown alg -> Same (Mark the room as encrypted but Deny sending) If an invalid `m.room.encryption` is received -> Mark the room as encrypted but Deny sending

If the event is correct and using megolm algorithm ( m.megolm.v1.aes-sha2), then the room is correctly configured and the user can send messagesįor live m.room.encryption state event received, never ignore and store value:.

If the m.room.encryption is malformed or refer to an unknown algorithm, then consider the encryption as missconfigured and block sending in that room (until fixed by a state update).

If there is a m.room.encryptionstate event, consider the room as e2e (no matter what the content of the event is).

We decided to follow a more pragmatic approach:

#Im encrypto update#

There is no UI to update such state events, but a state event can be sent by a room admin using devtools for example (user with enough Power Level to send state events)Ĭurrently some clients ignores m.room.encrytion state events when there is already one in the room, but it's problematic because new logins will only see the latest resolved state, and woud have to resolve the full history of that state to decide what to with that room. A room is set as encrypted when a state event of type m.room.encryption is set.