Fixes https://github.com/status-im/status-desktop/issues/15930
The issue happened because I received a notification about a contact request, but the request was not associated with a message in the DB. The DB didn't have a message with the required ID in it.
This potential fix moves the creation of the contact request later in the handling code, because the only way this bug can happen as far as I see it is if there is an error later in the handler function and the message is never added to the response, and therefore never saved.
I've renamed TorrentManager to ArchiveManager, ArchiveManager to ArchiveFileManager, TorrentContract to ArchiveService, ArchiveContract to ArchiveFileService. I've also renamed all init functions and struct fields to the appropriate archive-centric naming.
I've removed any mention or dependency of TorrentManager from Manager. There is still more work to do, but Messenger now communicates directly with a TorrentManager rather than asking the communities Manager to handle it. I've ensured that LogStdout() is only called from TorrentManager and removed entirely from Manager, this functionality seems to be some kind of debug tool specifically for torrent related functionality. Next I need to focus on functions within Messenger that call a TorrentManager and see how to isolate these from the main flows, following that I also need fix the tests that are broken. I will also need to refactor torrentClientReady() so that it is a function of TorrentManager, this may allow for pushing more functions into TorrentManager which will lead to better torrent encapsulation.
* Fix(Profile): Remove profile showcase from general responce via signal
* Fix(Profile): Restore community membership validation for the prodile showcase
* feat: Make profile validation optional
* fix: review fixes
- fixed issue with displaying 3 words name on the login screen after recovering from waku
- fixed inability to delete account after recovering from waku
Fixes https://github.com/status-im/status-desktop/issues/13488
The problem was that when you add a contact, it create the chat. Then, if you remove them, it doesn't remove the chat, so `chat.Active` is true.
Now I check in that case if it's a 1x1 chat and if so, if we are contact.
The test was flaky because of re-receiving the message, which resulted
in multiple identical requestsToJoin being added to messengerResponse.
We should in general avoid using arrays in messengerResponse and prefer
maps for exactly this reason.
This commit fixes a few issues with communities encryption:
Key distribution was disconnected from the community description, this created a case where the key would arrive after the community description and that would result in the client thinking that it was kicked.
To overcome this, we added a message that signals the user that is kicked. Also, we distribute the key with the community description so that there's no more issues with timing.
This is a bit expensive for large communities, and it will require some further optimizations.
Key distribution is now also connected to the request to join response, so there are no timing issues.
Fixes an issue with key distribution (race condition) where the community would be modified before being compared, resulting in a comparison of two identical communities, which would result in no key being distributed. This commit only partially address the issue.
This PR fixes [9947](status-im/status-desktop#9947) and contains :
- Commit to fix the changing of custom picture and having the change
reflected on contact's side
- Commit to fix the deleting of picture and having the change reflected
on contact's side
- Rename confusing `ImageType` to `ImageFormat`
This commit adds basic syncing capabilities with peers if they are both
online.
It updates the work done on MVDS, but I decided to create the code in
status-go instead, since it's very tight to the application (similarly
the code that was the inspiration for mvds, bramble, is all tight
together at the database level).
I reused parts of the protobufs.
The flow is:
1) An OFFER message is sent periodically with a bunch of message-ids and
group-ids.
2) Anyone can REQUEST some of those messages if not present in their
database.
3) The peer will then send over those messages.
It's disabled by default, but I am planning to add a way to set up the
flags.
* Fix: don't create extra system messages when accepting the CR again
* chore: add one more test for cr flows repeated
* chore: use deprecation.AddChatsCount in contact requests tests
When an open community was created by Device A and shared with Device B and when Device B would request to join such a community, the general channel would be forever in loading state.
This happened because as part of messenger response the chatId of general channel was not sent and mobile client would not fetch that chat data.
This commit fixes that issue by sending chatId as part of messenger response right after the request to join community succeeds.
* feat: Add profile showcase messaging part with ecrypted data
* feat: Separate profile showcase categories to provide ablity to store custom data
* fix: review fixes
* feat: move profile showcase out of contact data
* fix: create index on contact id for profile tables
* chore: remove logger from link preview
Which specifies that if a user is not a community member & a
chat member, he can't post, react or pin messages in that chat.
Notes:
- also fix&cleanup associated failing tests.
- refactor Community.CanPost() to reflect the new requirement.
- grant code is not fully implemented and is to be removed later.
Fixes https://github.com/status-im/status-desktop/issues/11915
This commit changes the format of the encryption id to be based off 3
things:
1) The group id
2) The timestamp
3) The actual key
Previously this was solely based on the timestamp and the group id, but
this might lead to conflicts. Moreover the format of the key was an
uint32 and so it would wrap periodically.
The migration is a bit tricky, so first we cleared the cache of keys,
that's easier than migrating, and second we set the new field hash_id to
the concatenation of group_id / key_id.
This might lead on some duplication in case keys are re-received, but it
should not have an impact on the correctness of the code.
I have added 2 tests covering compatibility between old/new clients, as
this should not be a breaking change.
It also adds a new message to rekey in a single go, instead of having to
send multiple messages
Jonathan Rainville
Prem Chaitanya Prathi
Samuel Hawksby-Robinson
Mykhailo Prakhov
Mikhail Rogachev
frank
Alexander
yqrashawn
Igor Sirotin
Sale Djenic
Andrea Maria Piana
Mohsen
Patryk Osmaczko
Godfrain Jacques
Dario Gabriel Lipicar
Ibrahem Khalil
Siddarth Kumar
Cuteivist
Richard Ramos
Vitaly Vlasov
Mykhailo Prakhov
Shinnok