- migrated to more useful MSC directory structure
- migrate Widgets API into new structure
- add recent emoji API into new structure
The recent emoji API is non-standard and should be compatible with Element.
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>
When opening a room we need to
fetch all users from the database.
Otherwise we would need to
update the timeline per user after
creation which should be much slower.
For thumbnail generation, encrypting
and uploading it is not necessary
to block the UI. The given file
event should already be displayed
in the timeline. This placed it in
the UI and adds a additional
fileSendingStatus property so the
app can fetch the current status.
States were used before being fetched from the database.
Thus, room membership states weren't set, and so,
user display names weren't be fetched from the database.
refactor: Make MatrixFile final and move all image calculation into isolate
Closesfamedly/fluffychat#863
See merge request famedly/company/frontend/famedlysdk!972
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.
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.
The redaction events should not
be displayed in the GUI but it
is the job of the app to hide
them from the timeline while
the SDK should offer an
accurate list of ALL timeline
events by default.
Please note that this does not implement *modifying* widgets,
as this requires a full implementation of the Matrix Integration Manager
API first. This is to be done later.
Signed-off-by: TheOneWithTheBraid <the-one@with-the-braid.cf>
- 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>
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.
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.
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.
Apps had a hard time to just set
the marker for the last event.
The lastEvent in the Room may
not be the actual last event
because we ignore several
event types there. Therefore
it makes sense to refactor
the setUnread method.
Now the timeline class has an
easy method to set the read
marker to the last synced
event, which can only be
known by the timeline if we
want to avoid another DB access.
This makes it finally possible to
use Flutters AnimatedListView with
our Timeline class and in web we
can now update single elements
instead of the whole timeline
on every change which should
be quiet good for the
performance
fix: add room invite update to roomStateBox, so invites don't show empty room when app is restarted
Closes#228
See merge request famedly/company/frontend/famedlysdk!865
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.
Events with a status of 1 should be sorted in the normal timeline.
They should not be stucked at the bottom. This fixes a bug
where a limited timeline flag
can stuck a SENT event at the bottom of
the chat forever.
When requesting history the `start` parameter could become larger than the loaded events
from the database were, resulting in an error when attempting to request history.
If requesting history happens to contain a m.key.verification.request we currently create a new key verification object and push it to the client.
This fixes it.
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!
Just using the .init() method to wait for the client
to initialize is a more easy way than listen to onLoginStateChanged.
But by default it waits for the first sync.
This should be configurable.
If a box is corrupted the clear function fails on it. Then
we should delete the box from the disk.
Currently we use the Hive.deletefromDisk() method which does not
work because it deletes only open boxes, but the box is obviously not open in
this case.
Previously we had a check which uses the old
sortOrder value.
This check has been removed with the refactoring which leads to
bug #209. This fixes it by checking if the
event is already known in the database.
I am not 100% happy with this solution as this database api is impossible
to be implemented with a sqlite db. Once we start to refactor the whole sync update logic
we maybe could find a better way, but only the fox god knows.
Previously when using RoomUpdate in the constructor the notificationCount to update
was never null and set to 0 if it was missing. Now that we are
no longer using it, I forgot to
add the null fallback at this point.
This leads to serious crashes in the apps at runtime
and thats why I bump the version here as well!
The method was not type safe and therefore there
was no warning that with the sortOrder changes
now DateTimes are compared which leads to
an exception in the app if not using converting to milliseconds first.
RoomUpdate came from a time where we had no data model for
SyncUpdates but now we have and therefore this class is just
code duplication. This removes the class
and uses the SyncRoomUpdate class from
the package matrix_api_lite instead.
It needed a lot of refactoring at some places
where I also have removed some unnecessary null or type checks.
This is an edge case which might occour
on unstable data connections. The user sends an event and receives the sync
before the response to the sending
http request. This leads to duplicated
events while the response actually
should be ignored at this point.
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/
Normally we do not need a workaround here at all but we had
one in the displayname calculation for
historical reasons. A "good" server should always send the mHeroes correctly.
Instead of removing this workaround completely we do a compromise and implement a more
lightweight alt behaviour by just saying that in a DM room with no
heroes, the directChatMatrixId will be used. This is the same behaviour like in Element
and needs way less lines than before and also covers the avatar
calculation. For Synapse we seem to not need this but for Conduit it
might be helpful.
That way some concurrency bugs might be fixed, such as if two sync
requests are processed at the same time. That can e.g. happen if you
request history while a sync request is already being processed.
We should just let the `auth` object null and dont send it at the
first try and wait for the servers response. This worked in the past
but now it is broken because of changes in the
matrix_api_lite. This could also be fault for some
bootstrap issues.
I have also removed an unnecessary check if a String is a String and just made it a
null check because this was intended at this point.
Because of that this blocks uiaRequests it is a hotfix and therefore directly bumps the version.
As it turns out, some of the code set the prev_batch for rooms too
early to an empty string. For synapse this means "request from the start",
for conduit it is just an error. This commit fixes that by never resolving
null --> empty string, but instead throw an error.
The old mentionMap was very inefficient to build and scaled badly with
room member size. This resulted in noticable lag when sending any message
in a large room, no matter if it contained a message or not.
Now, the algorithm is severly optimized and mentions (and emotes) are
only loaded when actually used.
It appears that [hideEdit] in Event.getLocalizedBody was written in a way that it
assumes a valid event body. This was also fixed, while also adding tests for the
various parameters of Event.getLocalizedBody
Using JoinedRoomUpdate() in a fake
sync for archived rooms when requesting
the history leads to the problem that
the room is stored as a joined room
in the store which is wrong.
getRoomById searches now in the local cache for the given room and returns null if not
found. If you have loaded the [archive] before, it can also return
archived rooms.
This should make it much easier to display
archived rooms in the client.
Krille Fear
Nicolas Werner
Henri Carnot
Reza
Lanna Michalke
td
Duan Weiwei
TheOneWithTheBraid
Marcel
Sorunome
td
Jindra
Jindřich Pikora
Lukas Lihotzki