Fixes https://github.com/status-im/status-desktop/issues/13545
The code is correct in sending an updated CR to make sure the sync doesn't sync back the previous state or at least overrides it.
However, if we never were a contact with the person sending us a CR, and we block them, it sends them a "you got removed" message, which first doesn't make sense but also could let them know they got blocked/ignored.
The trick is just to make sure we added them first. Then dismissing the CR makes sense.
- Extracted `community_events_factory.go`
- Introduced `eventsProcessor`
- Improved processing logic order
- Improved events filtering
- Introduced concept of `EventTypeID` to prevent redundant events handling
- Added sanity check before events appliance when reading community from
database
- Removed reject&re-apply scheme (no more ping-pong issue)
- Fixed and added more variants to eventual consistency test
fixes: status-im/status-desktop#13387fixes: status-im/status-desktop#13388
* chore: move profile showcase structures to the indentity package
* feat: implement proof of membership for unecrypted communities
* feat: implement proof of membership for encrypted communties with grants
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.
This commit adds HighestRole & a list of permissions in order of
importance to the CheckPermissionToJoinResponse.
This simplify client code so that it doesn't need to be calculated on
the client.
Enables controlling order of messages in tests. Useful for deterministic
reproduction of out-of-order messages.
Required for: status-im/status-desktop#13387
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.
* fix(community_import): fix import getting stuck in case of error in msgs
Fixes#13438 and #13439
* fix(community_import): fixes a bug with the timestamp format
The importer didn't like `-` time zones like `-4`. Using the standard date format makes it work.
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.
BridgeMessage is a type of chat message content which will be sent from Matterbridge.
It contains fields:
- bridge name - depends on the used bridge, eg. "discord", "slack", etc...
- user name - username the message was received from
- content - message content
- user avatar
- message id
- parent message id - used in case of replies
Message is saved to a separated table: bridge_messages, similarly to discord messages.
The user_messages table is untouched.
bridge_messages table contains user_messages_id in order to join with user_messages table.
Issue #13098
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.
- favourite column removed from the saved_addresses table
- favourite property removed from the SavedAddress struct
- ens name removed from the primary key, the primary key now is composed of address and is_test columns
- ens parameter removed from wakuext_deleteSavedAddress
- wallet_getSavedAddresses moved to wakuext_getSavedAddresses (to keep them all in a single place)
- saved addresses related endpoints removed from the wallet service, even they logically belong there, a reason for that
is avoiding emitting sync message if one uses calls from the wallet service, while that's not the case in ext service. Once
we refactor this and introduce devices syncing mechanism in the wallet service, we should not only these but other wallet
related endpoints move there (removed: wallet_getSavedAddresses, wallet_addSavedAddress and wallet_deleteSavedAddress).
Affected area:
Saved addresses
Patryk Osmaczko
Jonathan Rainville
Mikhail Rogachev
Mykhailo Prakhov
frank
Michał Iskierko
Pablo Lopez
Igor Sirotin
Cuteivist
Roman Volosovskyi
Andrea Maria Piana
Sale Djenic
osmaczko
Michal Iskierko
Icaro Motta
Mohsen
Ivan Belyakov
richΛrd
Godfrain Jacques
Ibrahem Khalil
Siddarth Kumar
Dario Gabriel Lipicar