Else, if a client calls addContact with an invalid uri, it will
create a conversation with an invalid contact and the client will
be in a bugguy state.
git.jami.net/savoirfairelinux/jami-client-android/-/issues/1681
Change-Id: Id6227c45c279c78aac0a191b6ae688ebe0d3d1c4
This allow users to delete files. Moreover, change edited type and
use edited commit type instead.
GitLab: #796
git.jami.net/savoirfairelinux/jami-client-qt/-/issues/1287
Change-Id: Ida04c15cf1570de2f7707ce547be9f4a5e638245
The goal of this patch is to allow the clients to get a better
sent/read status from the daemon.
API doesn't change much, but internal logic got some changes. For the
client:
+ SwarmMessage now contains a map<string,int> status where string is the
uri of a member, int is the status (0 = sending, 1 = sent, 2 = read)
+ cancelMessage is removed as not used anymore (sendMessage with flag=1
will edit a message)
+ getMessageStatus is removed as the status is sent in the SwarmMessage
+ accountMessageStatusChanged is now emitted for swarm messages when a
fetch or setDisplay occurs. Client must handle this signal correctly.
+ Previous code to manage last displayed, fetched status is now merged
with message status
+ Sync info is done when the sync is opened, else status are not updated
correctly
GitLab: #948
Change-Id: I60763d4de8a995c6fc9f6df6434e266211f8dc2f
If the first interaction from a device in a conversation is a
profile update, the certificate was not added correctly causing
the conversation to be illformed
GitLab: #946
Change-Id: I07f1735639c2dbf89ba2b2e6b7d9c3f57e5823e4
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
setKnownNodes will add new nodes that may be already connected
with a TCP link, but maintainBuckets may not choose those nodes,
delaying the bootstrap.
If we detect a new node that we're already connected with, we can
add it in the list of nodes we want to connect with.
Change-Id: I422a32495693e1e2d925a3af127a4a59903c1833
If a new device is doing some actions for the first time, the merge
will detect a new certificate that is not yet in the certificate
store (unless if the sender is the new device).
This will block the validation. So, instead, use the certificate
in the processed commit.
GitLab: #892
Change-Id: I0ab492e700a2aa7ef4258e2bf711117f67e29fae
When a trust request is confirmed with an old conversationId, new
messages will be transferred and the conversation will be replaced
to avoid duplicates.
However, because erasePending() wasn't used after a lock, the
removal was failing with "operation not permitted" causing a duplicate
to stay.
A test is added to avoid any further regression.
Change-Id: Ic0fd960005a064ddd7b410f014f67d9125e50446
If the signature creations fails due to an invalid display name, the
signature will use the device Id instead.
GitLab: #885
Change-Id: Ifddf0c8afec03f26f43aebe12e56d028ca5200d0
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
Since the DRT, we're not using trackPresence to start syncing
with other members of the conversation but "bootstrap".
For bootstraping conversation's requests we should try to clone
it with the members marked in the convInfo.
Also fix one incorrect test.
Change-Id: I8cbefe266c15c637ef23350220a71a616ddefab6
Multiple changes are included in this patch:
+ Remove pendingConversationFetchMtx_ and use conversationsMtx_
instead to avoid any potential weird state
+ Remove RepeatedTask causing two fetch operations to happen
+ Remove bugguy map access causing a fetch to happen even if
previously removed
A test for the problematic scenario is added to avoid any future
regression.
Change-Id: I9b5f93fc11f053a0552e5f34711130d5a5c22c05
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
- mobile shutdown: added time / block for callback
- check existing connection before removing node from rt
- threadpool instead of lock for shutdown
Change-Id: I79fc9506cd465763cd38723aedd08a59a0573970
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
This is a pretty trivial patch as all the necessary logics are
already supported by the deamon.
A client can use sendMessage with flag = 2 to add a reaction.
This only adds a "react-to" in the body of the message that the
client can interpret.
To remove a reaction, the client can use editMessage (and set the
body to "" for the id of the reaction), also there is no limit
on the content of the reaction and multiple reactions can be added
to the same message.
For non compatible clients, it will be shown as a simple text message
as it's the same type.
Change-Id: I7b13d32771109118b94ed17d0b918e66487e94bb
The new logic is there! Swarm is working since some time now, so we can
remove previous logic.
GitLab: #524
Change-Id: I5ca172e9349694d944c9561d97fe8a63d190ebf3
As a measure of refactorization of the code and to prepare to the
development of dhtnet, the following changes aims at seperating
jami-specific code to connectivity-specific code.
GitLab: #778
Change-Id: Iaa08100f7d61c80292f039a5aae66819cc85b0e9
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
logUntil should retrieve the commits with the commit passed.
Add a LogOptions parameter to avoid too much parameters.
Change-Id: I77a0150b135b14fe44577747d2b1a86cb2cf2509
In some cases the file "contacts" was badly synced. Also, if for any
reason "contacts" is not correctly formed, we may be able to fix it.
This patch handles two cases of failures:
1. If the contact details doesn't contain any conversationId BUT
a 1:1 conversation is found with this contact, we update the
conversationId in the details.
2. If, for some reason, multiple 1:1 conversations are detected
with the same contact, we only keep the one in the details, as
it should be the correct one.
This should fix the fact that for some conversation, calls are not
written in the history (cause getOneToOneConversation() returns
nothing).
Change-Id: I5dd9fc51999540d8a4230f8fdce828a461da752a
This store user's preferences per conversation into
conversation_data/<convId>/preferences
In this way, the daemon is able to sync this file across devices
and remove preferences at the same time we remove the conversation.
For now, only support "color" and "ignoreNotifications"
The preferences are synced via partial SyncMsg sent across devices.
Change-Id: I8fe74cc06733ad61d45d721e0264b1941d4cf122
+ search method was incorrect if no type provided
+ some tests were not waiting for correct signals
Change-Id: If6ba59829defb168f51c4a8e25f2054cd649b8c2
