Group chats with no user
avatar should return null for
the room.avatar getter and not
a random hero avatar. This could
otherwise lead to confusion as
it looks like this is a DM which
is not the case.
For the name we should also
not just display the name of
the invitor like in a DM even for
group chats, but some more
additional information. I found
a String for
invites quite useful here as
this would name rooms without
a m.room.name like this:
"Invited by $senderName"
which should be short enough.
The alternative
"You have been invited by $senderName" could be too
long IMO.
This completely redoes the requestUser function.
It now doesn't stop requesting a user forever just because of a network
error. But redundant calls are still deduplicated, however their
parameters are taken into account now.
It also now only calls onUpdate and onRoomState when there is actually
new state. This way apps can just listen to updates to rerender instead
of having to implement the deduplication themselves.
It also now doesn't treat member events without membership as "join"
anymore. And lookup errors don't cause an empty user to get inserted
into the room state.
In general this should still request the profile from the server, if the
displayname is unset in a leave event, but it should also allow the app
to actually settle in the tests.
This has been set to false
to prevent storing global
user profiles as member states
in the database. However
looks like this is already
solved below. We can
safely store the profile
in the local cache, otherwise
we cannot calc the body
for an event synchroniously.
The direct chat account data
content is a map from matrixId
to roomId(s). If we want to find
the roomId for a given userId,
then this is not a problem. But
the other way around, if we
want to check if a given roomId
is a direct chat or not, needs to
process all entries which can be
hundreds. Doing this very
often in an app costs a lot of
performance. This adds a simple
cache in the room object and
validates the cache every time
to make this more efficient.
This lead to the huge problem that there is no
user feedback between sending a message and
seeing it in the timeline as it is encrypted
before the first user feedback is shown. But
the encryption step is async and also includes
fetching devices if necessary so that can take
seconds or even forever on bad internet
connection.
This reverts commit 981c3ea94d.
Before we have used the Event class for all
state events while for invite rooms those
actually were StrippedStateEvent objects. This
created some problems like we needed to set a
fake originServerTs (usually to DateTime.now()).
Actually we don't need the additional keys for
state events most of the time so just using
StrippedStateEvent for all states and typecasting
them to event where needed is not much of a
hassle while we benefit from a more clear
structure.
This also now uses StrippedStateEvent as a base
class for the User class which makes the User
class more minimal as keys like event_id and
origin_server_ts are no longer necessary. As we
create a lot of fake User objects where we had to
put fake values in it, it brings more benefits
than problems to just get rid of those fields.
This makes sure that the
users for an invitation are
correctly loaded so that we
can display the avatar, the
room displayname and
wether the room is a direct
chat or not.
This fixes the bug that the
actual dart Map in the state
has been manipulated because
we have not worked with a
copy of the map. Also this
crashes if the powerlevelmap
would had a wrong type in
users.
When user A invites user B to
a group chat, the avatar getter
should not return the
avatar of the inviting user A.
This is not intuitive. A client might
decide to do so but IMO it makes
no sense to do this by default.
If the
room is a DM invite, user A's
avatar is already used in the
code block before.
This changes the way how the last event is stored
for each room. It is now stored next to the
room event itself in the rooms box and no longer
stored like a room state. This way we need to
bump the database version which will cause an
inital sync for the client. Be aware of this when
updating the SDK!
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 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 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 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.
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.
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.
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.
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
You can either set them to private on the client or overwrite the
behaviour for that on each readMarker call. This also handles incoming
thread receipts and tries its best to figure out what is the latest
receipt. This however breaks the old m.receipt account data event.
fix: implement activeGroupCallEvents to get all active group call state events in a room
refactor: move staleCallChecker and expires_Ts stuff to an extension on Room, instead of Voip because it makes much more sense per room rather than on voip, also makes testing easier
fix: populate local groupCalls list on instantiating VOIP()
fix: starting stale call checker is now handled by the sdk itself because clients can forget to do so
This fixes a bug that the
last message was sent
incorrectly when a session
key received for example
from the key backup. It may
fix several issues like the
last message is set as a
very old one or the last
message is not decrypted.
This deprecates the displayname
getter in favor of the new
getLocalizedDisplayname which
gets the default localization
by default so it can be
called without defining localizations. It adds a method
to calculate if a room is an
abandoned DM room where
it is made sure that the room
is actually empty.
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.
Krille
td
Nicolas Werner
krille-chan
Karthikeyan S
krille-chan
Patrick Hettich
Patrick Hettich
Karthikeyan S
Krille
The one with the braid
Clemens-Toegel
The one with the braid
Malin Errenst
Dmitriy Bragin
Philipp Grieshofer
TheOneWithTheBraid
Reza
cloudwebrtc
Lanna Michalke
Henri Carnot