fix: only fire backend.onNewParticipant and backend.onLeftParticipant when it is not the local participant, this fixes the issue where onNewParticipant would get triggered when it detects a new call even though you were not in the call, as of now there is no code in those functions which needs to be triggered before you have joined the call so this should be fine
chore: also improve participants join leave tracking logic
with this you can now send the key before joining the call to the participants, make sure to call onMemberStateChanged first to ensure groupCall.participants is populated
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.
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.
fix: while singleShotStaleCallChecker code seems to be correct we are seeings some random disconnects in group calls, this makes sure we have all the to-device messages we are supposed to have before checking for stale calls
currently in the app we start the group call (but do not enter it), then we use the localStreams provided by it to show the setup page (enable/disable media devices). This causes some issues because the user hasn't joined the group call so the member state events don't update and the group call is killed if they just sit on the setup call page. Also creating a group call, sends notifications in our apps but no one has entered it. With this MR, apps can get their own user media, then edit that stream on setup page add it to GroupCall.enter(stream). This way, a group call doesn't have to be started and we get to do the setup page as well.
td
Krille
td
Karthikeyan S
Nicolas Werner
Mohammad Reza Moradi
Malin Errenst
cloudwebrtc