This adds a check before the storeRoomUpdate() call
if the room is actually known. This has the effect
that the call of forgetRoom() is skipped.
The reason for this is an edge case in the database
implementation when calling getAllKeys(). This
somehow can corrupt the keys-cache and lead to
some problems. I wasn't able to fix this problem
yet so this refactoring is more a good-enough
workaround for now to not trigger it on an
initial sync. I plan to fix it with a different
approach which completely removes the keys-cache
in the future.
However this change leads to some problems in the
tests as they already rely on this edge case.
This makes all fields in a MatrixFile final and
the object therefore stateless. It also moves
all calculations into the isolate. After some
benchmarks it seems that this does not
really speed up the thumbnail creation
but it does no longer block the UI for
some seconds.
- By using [package:image](https://pub.dev/packages/image), the
`MatrixImageFile` was given automatically generated width and heigth.
- Moreover, `MatrixImageFile` was given a factory to create the image
file from a given maximal dimension.
- When sending images without explicitly providing a thumbnail, the
thumbnail is automatically generated based on the provided image.
- The blur hash in generated automatically based on the provided image.
Fixes:
https://gitlab.com/famedly/company/frontend/famedly-web/-/issues/162, https://gitlab.com/famedly/fluffychat/-/issues/756
Signed-off-by: Lanna Michalke <l.michalke@famedly.com>
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.
If both ends had m.dummy events queued as last messages an an olm
session corrupted, then the clients landed in an infinite game of
ping-pong. It was so stable, that the clients could have won the
ping-pong world championships!
The current implementation of sortOrder can be made way more easier now
by just keeping the sortOrder of the list
and the timelineFragments in the hiveStore. This needed a huge
change but mostly removes a lot of code which can be done
way more easy now. This also needed some rewriting of the setState logic and changes to
the prevEvent calculation. This solution should also be more stable.
More information:
https://www.reddit.com/r/fluffychat/comments/pfnlhq/the_sort_order_of_matrix_timelines/
A client might find the need to get the verification request object by
its transaction id, to be able to e.g. display for in-room verification
an "accept verification request" button easily.