The need for a database destroyer
is gone since we have switched
from sqflite/moor to Hive. Removing
it is the first step to a major
refactoring to make the database
not nullable anymore.
This makes it possible to pass cache
and getFromRooms variable in
fetchOwnProfile. It also removes the
never working and duplicated
check from rooms. The Profiles
can be duplicated in the Set
because they are equal but not
the same objects. In the get
profile method, it now checks the
cache first before the rooms as
the cache might have the more
accurate result.
This makes displaying an avatar
change much easier as it makes
it possible to just disable cache
then.
In order to allow key sharing with
unknown devices (master key has been
verified but this device is not
signed by this master key) the
user should at least be informed.
This makes it possible to set
in the client constructor whether
the app should share keys with
unverified devices or unknown
devices.
This makes sure that the handle
ephemerals method becomes fully
type and null safe, does not handle
maps directly anymore and stores
the corresponding fake m.read
room account data only once
per sync.
- implement session export
- implement session import
Please note, this is not device dehydration but a fully offline session
dump eligible for e.g. TOR users.
Signed-off-by: Lanna Michalke <l.michalke@famedly.com>
- for external access, Client.accountData should be read only
- added corresponding getter and private Map
Signed-off-by: Lanna Michalke <l.michalke@famedly.com>
There are a few ways to fix this. We could skip events, where we don't
have the state in memory yet or always do a /profile request and cache
that.
I chose to go with loading the event from the database if necessary. If
we have a room in the db, we should have our memberevent in the db. In
some cases we might not (if the server thinks our memberevent is super
redundant), but I think the spec doesn't really allow that and it
doesn't happen in practice. And even if it would, we probably would want
our member event ASAP. And if we have no rooms, we fetch it from the
server as before instead of constructing a member with an MXID as the
username.
fixes https://gitlab.com/famedly/company/frontend/frontend-issue-inbox/-/issues/65
Reactions are triggering push
notifications and should therefore
be displayed as last events
in the room list of a client.
The body should just display
the reaction key.
This fixes that rooms with
new reactions can't set to
read.
FluffyBox behaves different on
web transactions which leads
to the result that _sortRooms()
is performed before the
rooms UI can be there. This
leads to an unsorted room list
on web.
I think the commit which broke it was this: e3bd0cf1 It makes sure that only important state events get cached and room member events are not important state events and so new invites have no room member events cached. It makes sense to also allow room member events here to always be cached as they are special typed.
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.
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
This can improve the start-up time of apps.
The three big db reads on init are
loading account data, rooms and
device keys.
This makes it now possible to let
them run parallel
(while it may depend on platform
if this has any effect)
and the init() method can skip
awaiting them. They will
be at least awaited before handling
the first received sync.
So the app can already display the
room list before device keys are
loaded and request the first sync
from the server before anything
else is loaded from the DB.
Room states are ignored if the event with the same event ID
is already known in the database. But
because of the event is stored in the
database and after this
setState in the Room class is called,
an event is always "known" and
therefore auto updating was broken.
Christian Pauly
Nicolas Werner
henri2h
cloudwebrtc
Lanna Michalke
td
Henri Carnot
Isabella Hundstorfer
MTRNord
Sorunome
Jayesh Nirve