In notifications in FluffyChat we
have "Unknown event m.reaction"
for reactions. But it should just be
enough to display the body so it
should look like:
"username: :thumbs_up_emoji:"
The to_device queue was introduced to ensure integrity if e.g. the
server temporarily failed when attempting to send a to_device message.
If, for whatever reason, the server responds with a 4xx error, though,
then we want to ignore that to_device message from the queue and move on,
as that means that something different was fundamentally wrong. This
helps to fix the to_device queue clogging up, making clients incapable
of sending to_device events anymore, should such clogging happen.
If we dump all state events from sync into memory then we needlessly
clog up our memory, potentially running out of ram. This is useless
as when opening the timeline we post-load the unimportant state events
anyways. So, this PR makes sure that only the state events of post-loaded
rooms and important state events land in-memory when processing a sync
request.
Previously we stripped all spaces off of the recovery when decoding it,
so that we could format the recovery key nicely. It turns out, however,
that some element flavours also format with linebreaks, leading to the
user having to manually remove them. We fix this by just stripping *all*
whitespace off of the recovery key.
We have disabled it by default to
prevent using workarounds as
long time solutions and to not
miss bugs. But in a federated
context we can not be sure that
we all Matrix clients are ever
bug free and we have now the
onEncryptionError Stream
anyway.
deviceKeysList.outdated is not nullable but we have seen this error
in production: `Failed assertion: boolean expression must not be null`
So this could either be a null safety bug in Dart or a result of
using unsound null safety. The extra equal check `== true` should
safe us here
Due to server bugs or whatever it sometimes
happens that old state events appear
in the setState method in the room class.
Previously we checked if we already know
this event ID, but for this we needed to
check the timeline which is very fluid.
Also this is a database operation in a
non-async method which works in Hive but
not in Sembast.
Using originServerTs is not 100% safe as
well but should be more stable because
the chance that servers have veeery wrong
time (which is necessary here) is much
lower than the risk that the timeline
is not long enough to know the
old event.
Krille Fear
Nicolas Werner
Sorunome
cloudwebrtc
td