This was implicitly relying to the timestamp of state events getting
compared in the setState function. Fix this by using the helper
functions already used for invite and join rooms.
We used to add app the member counts of invited users and joined users,
which would make us assume the participants list is complete. Which
would mean we always return the wrong state.
Additionally there is no need to rely on if we have a cached response.
Instead we always only check for completeness instead of possibly
returning stale responses just because we fetched the members once.
We now handle state in the correct order in the sync handler. Using the
timestamp lead to false results when we still generated a default
timestamp of "now" for events, however even without that state events
can have an older timestamp like when accepting an invite on a server
with the clock behind by a minute and we should instead rely on the sync
handler giving us state in the right order.
This causes issues with state handling as we prefer the newer event. It
also has knock-on effects in other places. Instead set such events to
have an obviously invalid timestamp, which makes issues easier to
identify.
This may break invites showing a timestamp or the timestamps for just
sent events, if you rely on the timestamp getting set to "now".
This patch introduces a helper class for SQfLite encryption related operations.
Most matrix clients will encrypt their sqlite database at rest. Since
this is a quite fragmented task using the Flutter sqlite ecosystem, this
helper aims to simplify some more complex operations.
It in particular helps with the following tasks :
- loading the correct shared objects / dynamic libraries for sqlcipher
- check whether a database is encrypted
- migrate an unencrypted SQLite database to SQLCipher
- apply the cipher to a database while opening it and ensure it loads
This code is not exactly matrix related, though presumably any matrix
client will use parts of it.
Possible regressions :
- `package:sqlite3` became a direct dependency. As of now it already was a
transitive dependency of the SDK itself.
Signed-off-by: The one with the braid <info@braid.business>
This refactors the transaction
workaround with
"zone transactions" and
abstracts them in a mixin. Then
it just uses this mixin in the
HiveDatabase and the
sqflite_box and also applies
them on indexedDB to
fix transactions on web.
This creates a set before
requesting users from the
database. This prevents
doing the same check for
the same user multiple
times and also prevents
concurrent modifications
of the event list.
This changes the behavior
when client init fails. It
no longer calls logout and does
only clear local data while
returning all available
information in a new
exception type so that the
SDK consumer can decide
to logout or try again to init
with these information. This
should make it much more rare
that users loose their sessions.
This creates the timeline object
earlier in the Room.getTimeline() method.
This results to that the
Timeline object already starts
to listen on the event stream
while the getTimeline() method
requests users from the database
and tries to decrypt room
events. I assume that this
causes the problem that
on timeline creation new
events get lost because they
come in, while getTimeline() is
not yet completed but the
onEvent stream is not yet
connected at the same time.
This fixes the response
timeout for the initial
sync and sets it to 2
minutes instead of 10
seconds. This should increase
the speed for the initial
sync especially for large
accounts. This change
also adds some
documentation in the
code about what
timeout does what.
This refactors three methods
regarding powerlevels. It
makes them a little bit more
readable and removes
unnecessary checks. it
also changes the canSendDefaultMessage
method in a way that it also
checks the events map in the
powerlevels so that it returns
true if message events are
overwritten there. It also
improves the dart docs and
explains in more detail what it
does.
dynamic.copy returned a type
error so I reverted the previous
change of the copyMap
method to an extension. Also
I found out that we have used
two copyMap methods in the
SDK which did exactly the same.
I deleted the old one and
changed the tests.
Unfortunately we need to copy
all maps. I took the opportunity
and abstracted the copy map
method to utils. I kept the
copyMap method as a
reference in HiveCollections
database to not require a
huge refactoring there as we
are going to ditch it anyway.
BREAKING CHANGE: This replaces the old dehydrated devices
implementation, since there is no way to query what is supported easily
and supporting both would be complicated.
fixes https://github.com/famedly/matrix-dart-sdk/issues/1579
There were several issues here. Key uploads in general failed, because
the await caused a Future<dynamic> to be returned, which failed type
checking.
But also we never unset our future, which was used for the online key
backup uploads, which meant we would very quickly stop uploading any
keys at all.
This changes the behavior
of the markdown method to
only convert linebreaks inside
of p blocks. I found no better
solution yet for the problem
as otherwise also lists
will have linebreaks between
the list items. Unfortunately
the default linebreak syntax
seems not to fulfill our needs.
BREAKING CHANGE: This changes the runInRoot method to not return a
future. As a user, if you need the result of an async computation passed
to runInRoot, please await it directly. Also the KeyVerification start
and a few call methods now return a future.
- store left rooms in archive during sync (as well as they are removed
on join already)
- refactor room archive code
- fix typo
Internal reference: SMC-385
Signed-off-by: The one with the braid <info@braid.business>
Removes two test cases in the markdown test which do not work anymore.
Reason for this is that just parsing a word inside of $$ word $$
katex is not valid anyway because katex is only made for mathematical
things. So the output is undefined behavior anyway.
At least in our CI this throws a null assertion error and since we
explicitly expect this to sometimes be null in our code, we should store
it as such.
If you create DM room, but the other party doesn't join it, they might
be unable to create a new DM using startDirectChat. Since creating a new
DM is pretty much the same as joining the invite, we try to join the
pending DM invite first and fall back to creating a new room if that
fails.
This does make the reset take longer on big accounts, but otherwise
users might sign out before the keys are uploaded, which makes the reset
more destructive than necessary. In the common case of not having any
keys it shouldn't make a difference.
It wasn't quite obvious that invites were always sorted at the top, if
you just looked at the sort function. This makes it more explicit and
also makes invites always sort before favourited rooms.
fix: Also update last event on redaction in store
Closes famedly/company/product-management#990
See merge request famedly/company/frontend/famedlysdk!1298
If we join first, it is possible that our member event is not the invite
event anymore. As such we should fetch that state first, before joining.
But also there is little reason not to mark the room as a DM
immediately. That prevents the room from temporarily becoming a group
room, that might be visible in the UI temporarily.
fixes https://gitlab.com/famedly/company/product-management/-/issues/1006
Otherwise it would be possible, that we haven't loaded account data, so
we return that cross-signing is disabled and then we load it and return
a different result. Might fix the sentry issue for that.