+ addConversationMember was called without any conv ready sometimes
+ call was mostly disabled
+ ban/unban was unclear sometimes
Change-Id: I4919ec70af128a5bf623405ba6840a8fafc45e8c
This heavily changes the API for the client. The goal here is
to move the logic to construct the history to show in the daemon
and not the client. This has several advantages:
1. Logic is common across every platforms, so bugs should not be
platform-specific
2. Client got less logic
3. Signal are simplified, if an edition comes, "MessageUpdated"
will be triggered instead MessageReceived.
4. Some tests are added for linearizing the history.
5. Search on edition is fixed.
Tests got heavily re-written, but the content didn't change (2 tests
are added, the rest is simplification).
GitLab: #831
Change-Id: Ie7c81077067e9e49db1dd396829c9225c0512c16
If first connection fails and presence is not tracked, the
conversation will not sync until the receiver restarts its jami,
causing the conversation to be stuck a very long time even if
peer is online and can sync.
In this patch, if we receives a trust request, we retry to sync
(this will be the case because the sender will re-send a trust
request to the contact who is still detected as an invited member)
GitLab: #922
Change-Id: I8866ceda98d50b0ddd2ea5402ef34f067f560e97
This allow to avoid to get a duplicate if a contact is added,
removed and re-added (as it will generate two conversations).
The first one is automatically declined and replaced by the new one.
GitLab: #855
Change-Id: I67d51d2286aaee3b29c9e9bdbcb10aa45f40aa26
If a contact is added, removed and a new trust request generated
and removed with "removeContact" it wasn't removing the trust request
because the contact wasn't considered as active and the banned status
didn't change.
Removing this return condition force all components to update and
supports client if they use removeContact instead of declineTrustRequest.
This avoid useless complexity with isActive, because if isActive() is
false, removeContact will not change the result and isActive() will
still return false.
A test is added.
GitLab: #855
Change-Id: I4385c2a480f6cfa5de3785a08bc2193eeb9a24a1
This allow to keep different status between accounts, remove
certificates when the account is removed. And this avoid
to use the same certificate store/trust store shared across
accounts.
Change-Id: Iba5df5c0768cefe7a861cab689ffb8ff770d8475
Because we remove the certificate, there is nothing to verify.
Also fix tests broken with new validation.
Change-Id: I8003e5d1b8cd61cfc9d944b57725081667485c00
This patches avoid swarm members to connect to all devices of the
conversation by using a better routing mechanism.
The idea is to add a component called "DRT" that will store, like
a DHT, a routing table containing the known devices of the conversation.
The DRT is bootstraped with the list of the devices that already wrote
a message in the conversation, else with some other members that have
devices present (because lot of devices may never have written any message).
Moreover, because a user can import an old backup without the conversation
and without other devices present, we also try to connect to 2 other random
members because they may never connect if they are on an old back-up.
Once bootstraped, the DRT is used to decide to who a user should be
connected. And it will use approximately log(N) connections (instead
of N like before). So, when sending a message, a user will send to
connected peers (and some mobiles). Then, some peers in the conversation
will get the message, pull it, then announce to their nearest peers (and
some mobiles) until all peers got the new message. To avoid infinite loop,
we check if we already got the commit and if we have something to announce.
Finally, if somebody disconnect, this will cause the DRT to try to re-fill
its bucket and try to connect to a new device.
GitLab: #297
Change-Id: I137788c77219fe74287585882260547cc5628784
If a member is banned from a conversation, only administrators can
re-add this member. So, clients should not show them in the list
for non admin users.
Moreover, clients should be able to show banned members in a list.
Change-Id: I0b0a80f1e2a3ed15339cd749e66dfa3e469f403c
This patch introduces the ability to start calls and extends the
usage of rendezvous points to swarm with multiple participants.
When starting a call in a swarm with multiple participats, one device
will work as the host of the conference, and the caller will
immediately start the call alone.
Other peers will receive a commit and a notification to be able
to join the active call. To join a call, users needs to call
rdv:uri/device/convId/confId to be added (if authorized) to the conf.
There are some majors differences in the process.
First, every conversation will be able to decide a default host
for conferences. This still needs some design and will be
introduced in another patch. For now, the caller is the host.
Then, because all members of the call may not be interested to join
a call, or they may want to get several calls at the same time, the
system must be able to manage more than one active calls (e.g. a
company with multiple projects can do several standups at the same
time).
Finally, in the conversation, two commits will be generated to be
able to know what active calls are available. The first is
announcing that a conference started, the second announces that
the conference stopped (the host closed the call).
However, this introduces a difficulty. The host may crash and not
commit the end of the call in time. In this case, hostedCalls are
stored in a file and the conversation is updated during the init
of the daemon.
Change-Id: I081a4920edb3773bbed884ae50f34e476ad42094
Documentation: https://docs.jami.net/technical/swarm.html#call-in-swarm
GitLab: #312
If an error occurs during the execution of git_remote_fetch, there
is no need to signal any error to the client as it's not a critical
issue (no malformed conversation, mode is recognized, no unauthorized
method) and the sync will be retried later.
Change-Id: I2d875445e51aa6cd78eb2e7dbfe5efb8b2831860
It's not possible to replace the DRing namespace for jami because of conflicts
with namespaces and classes defined under the jami namespace. Thus, use libjami
as the namespace.
Script to reproduce:
rg -l DRing | sort | uniq | awk '$0 !~ /NEWS/' | xargs sed -i -e 's|DRing|libjami|g'
rg -l DRING_ | sort | uniq | xargs sed -i -e 's|DRING_|LIBJAMI_|g'
sed -i -e 's|dring|jami|g' src/jami/CMakeLists.txt
sed -i -e 's|dring|jami|g' src/jami/def.h
Change-Id: I80e8c8b58a7586527a016bbef850bab07869c473
+ search method was incorrect if no type provided
+ some tests were not waiting for correct signals
Change-Id: If6ba59829defb168f51c4a8e25f2054cd649b8c2
Several improvements are included with this patch:
1. confirmed is resetted when account is removed, this allow to
send a request when conversation is added back and reset the
whole matrix, avoiding duplicates
2. Banned can be due to harrasement. In this case, keeping the
conversation like the old behavior (pre-swarm) is better, to keep
proofs. Also re-adding back a contact is immediate if it was a
mistake as the conversation is kept back.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1449
Change-Id: I13da8ce9bd431b91ce7b7d455dae561358c62f10
After a re-add of an invited contact, the validation was bugguy causing
the conversation to be invalidated and erased due to malformed commits
Change-Id: Ib500ae117f0c53774cfb1eec23aa160ba2f86420
A contact can be banned from another device. In this case,
JamiAccount::removeContact is not called and the daemon only call the
dedicated callback.
So, remove the conversation requests and connections to the banned
contact (and avoid future incoming calls if connected) when the
callback is called instead in JamiAccount::removeContact() as it
will be called in a multi-device context.
Change-Id: I1ac8b441268d7bfc9bb6627fbbbc7b83e2e75052
In the contact list, receiving a confirmed request for a non-active
contact would re-add the contact. If the contact was removed then
re-added, the conversation would be badly updated & removed, instead
of replacing the conversation by the old one.
Finally, remove the replaced conversation after the clone of the
new one, to avoid making the contact disappear while cloning.
Add some tests to validate the scenarios.
Change-Id: I67a94604c5869804ed66b390aa26cca9420fbc28
This patch fixes several behaviours:
+ Banning a member now stores the previous state of the member
+ This allow to store empty .crt files for invited
+ Unbanning a member is now possible for an admin
+ This re-add the member in its previous state
https://git.jami.net/savoirfairelinux/jami-product-backlog/-/issues/51
Change-Id: I34d5913c023043e07544f1b8bb6211aea5db0065
membersUris() didn't remove banned members from the list by default,
causing the daemon to send messages to banned members.
Change-Id: I84a80476d36d27ec33379b6e8be38f317322ec3b
GitLab: #298
