Commit Graph

69 Commits

Author SHA1 Message Date
Mykhailo Prakhov 3959948c4c
chore: fix ban/unban flow and delete all messages feature (#4743)
feat: delete all messages for banned member and ban/unban AC notifications
2024-02-22 11:25:13 +01:00
Pablo Lopez 3f19972c8e
enable custom community storenodes (#4532)
* enable custom community store nodes

* fix

* fix

* fix

* fix

* cleanup

* fix

* migration

* fix

* cleanup

* fix

* cleanup

* fix

* fix

* cleanup

* message to update the community storenodes

* rename

* fix test

* wait for availability only if global storenode

* fix test

* fix typo

* sync community storenodes

* remove unused

* add tests

* fix imports

* fix todo

* unused

* pr comments

* pr feedback

* revert merge deleted

* fix lint

* fix db and perform ms request

* typo

* fix log

* fix go imports

* refactor handle message

* cleanup public message

* add tests

* fix test

* cleanup test

* fix test

* avoid making one file to big to keep codeclimate from complaining

* fix lint

* revert

* Update protocol/storenodes/database.go

Co-authored-by: richΛrd <info@richardramos.me>

* Update protocol/messenger_mailserver_cycle.go

Co-authored-by: richΛrd <info@richardramos.me>

* PR comment

* fix tx

* proto files

* pr comment

---------

Co-authored-by: richΛrd <info@richardramos.me>
2024-02-20 17:49:39 +02:00
Igor Sirotin add46fbda0
chore: `make generate` with nix-shell (#4745) 2024-02-16 12:48:27 +00:00
Mikhail Rogachev 3ea2002904
Feat: Modify grants for profile showcase use (#4694)
* chore: regenerate proto binaries

* feat: remove unused grant code for community's canPost
2024-02-11 15:11:04 +03:00
Andrea Maria Piana 605fe40e32 Fix encryption metadata issues #4613
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.
2024-02-07 10:25:41 +00:00
Godfrain Jacques 5f6f7e502d
(fix/status-go) fix profile picture update/removal (#4570)
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`
2024-01-24 12:09:28 -08:00
Andrea Maria Piana e65760ca85 Add basic peersyncing
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.
2024-01-23 12:46:17 +00:00
Ibrahem Khalil 436d229856
Add last opened at key for community (#4514) 2024-01-21 12:55:14 +02:00
Dario Gabriel Lipicar 0d2c3cef7c feat: implement token management settings for collectibles 2024-01-18 11:46:35 -03:00
Patryk Osmaczko 1d3c618fb4 feat: encrypt `CommunityDescription` fields
Extended `CommunityDescription` with a `privateData` map. This map
associates each hash ratchet `key_id` and `seq_no` with an encrypted
`CommunityDescription`. Each encrypted instance includes only data
requiring encryption.

closes: status-im/status-desktop#12851
closes: status-im/status-desktop#12852
closes: status-im/status-desktop#12853
2023-12-22 18:17:06 +01:00
Mykhailo Prakhov 134137f9c5
feat: implemented a mechanism to retrieve shard information for a given community ID (#4499)
* feat: a mechanism to retrieve shard information for a given community ID
2023-12-22 13:37:37 +01:00
Mikhail Rogachev 03c32f620f
feat: Profile showcase data sharing (#4209)
* 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
2023-11-09 22:59:01 +04:00
Mykhailo Prakhov eb437e9d8d
feat: kick all members after ownership change and auto-accept after sharing the address (#4187)
feat: kick all members after the ownership change and auto-accept after sharing the address
2023-10-31 15:20:40 +01:00
Andrea Maria Piana 360c2d50d4 Fix issues with out of order encryption and batched messages
This commit fixes 3 issues:

1) In some cases, the hash ratchet was not correctly found
2) Out of order messages were not processed correctly as the wrong error
   was returned
3) Batched non datasync messages were not processed correctly

Fixes: #4170
2023-10-30 10:11:32 +00:00
Patryk Osmaczko b321f28c9d refactor: update community access enum naming 2023-10-25 17:34:37 +02:00
Andrea Maria Piana 23f71c1125 Fix encryption id && rekey with a single message
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
2023-10-24 20:48:54 +01:00
frank 624996a7e9
only sync decisions/state of AC notifications (#3979) 2023-10-22 17:41:20 +08:00
Patryk Osmaczko 0881d8cdb0 Add queue for processing community description & configurable control node 2023-10-17 21:00:24 +01:00
richΛrd ba5ed725ce
waku2: static shards (#3944)
- use protected topics for communities
- associate chats to pubsub topics and populate these depending if the chat belongs to a community or not
- mailserver functions should be aware of pubsub topics
- generate private key for pubsub topic protection when creating a community
- add shard cluster and index to communities
- setup shards for existing communities
- distribute pubsubtopic password
- fix: do not send the requests to join and cancel in the protected topic
- fix: undefined shard values for backward compatibility
- refactor: use shard message in protobuffers
2023-10-12 15:21:49 -04:00
Patryk Osmaczko 653df822da fix: derive community.Encrypted() from permissions 2023-10-12 01:45:33 +02:00
Mykhailo Prakhov 86d969727f
feat: share CommunityTokens between privileged users (#3931)
feat: sync CommunityTokens between privileged users
feat: restore PrivilegeLevel for synchronized CommunityToken
2023-08-22 19:48:42 +02:00
Andrea Maria Piana 8dd1b66d69 Always use protobufs by reference & generate handlers 2023-08-22 12:08:54 +01:00
Mykhailo Prakhov d1db60918d
feat: owner and token master permissions (#3912) 2023-08-18 17:29:44 +02:00
Patryk Osmaczko 1a05c84585 chore: remove `ROLE_MANAGE_USERS` and `ROLE_MODERATE_CONTENT`
closes: #3895
2023-08-16 21:38:04 +02:00
Mykhailo Prakhov 7eac9b170c
feat: community privileged user sync message (#3879) 2023-08-15 17:27:01 +02:00
Patryk Osmaczko ce82a8c0e5 chore: remove community invitations 2023-08-05 11:49:00 +02:00
Mykhailo Prakhov 3bd972dec4
chore: Added TokenMaster permission token type (#3848) 2023-08-04 12:28:46 +02:00
Patryk Osmaczko 47c568fb08 refactor: improve wrapped community description naming 2023-08-02 20:57:19 +02:00
Mykhailo Prakhov f89eee9f40
feat: register new community member role ROLE_TOKEN_MASTER and grant him admin permissions (#3810)
feat: register new member type TokenMaster and grant him admin permissions
2023-07-26 18:01:19 +02:00
Jonathan Rainville 9674bc463f
feat(communities): add airdropAddress param to SharedAccounts (#3756)
Adds airdropAddress to the request to join params and a is_airdrop_address flag in the communities_requests_to_join_revealed_addresses table. 

This airdropAddress is used by the owner to know which address to use when airdropping
2023-07-14 13:33:47 -04:00
Jonathan Rainville 2c275058ad
feat(community): add api to edit shared address (#3723) 2023-07-10 10:11:37 -04:00
Michal Iskierko 6ec50d52aa feat(AssetsDeployment): Assets deployment
- Add ERC20 contract
- Add decimals field to community_tokens db table
- Adjusting API to handle assets deployment
- Add decimals field to CommunityTokenMetadata

Issue #10987
2023-06-29 16:10:05 +02:00
Mykhailo Prakhov e058b50a2e
feat: community admin permission functionality (#3569)
* feat: community admin implementation

* fix: code review fixes

* chore: request admin permissions in CheckPermissionToJoin, unit test fix
2023-06-14 10:15:46 -04:00
mprakhov 6bc8765d39 chore: new CommunityTokenPermission types 2023-06-13 13:42:48 +02:00
Pascal Precht 1a2ca21070 Add chainIds to revealed accounts in memberhsip requests
This commit does a few things:

- Adds a migration that adds chainids to communities_request_to_join_revealed_addresses
- Removes RevealedAddress in favor of RevealedAccount which is now a struct that contains the revealed address, as well as the signature and a list of chain IDs on which to check for user funds
- Changes the logic of sending requests to join a community, such that after creating address signatures, the user node will also check which of the addresses has funds on which networks for the community's token permissions, and add the chainds to the RevealedAccount
- Updates checkPermissionToJoin() such that only relevant chainids are used when checking user's funds. Chain IDs are retrieved from RevealedAccounts and matched against token permission criteria chain IDs
2023-06-12 10:49:29 +02:00
Patryk Osmaczko 8dd8b1ae45 feat: implement community members count
iterates: status-im/status-desktop#8016
2023-03-29 17:08:41 +02:00
Pascal Precht 2cbced95c5 Check token funds when handling community requests to join
This adds checks to `HandleCommunityRequestToJoin` and
`AcceptRequestToJoinCommunity` that ensure a given user's revealed
wallet addresses own the token funds required by a community.

When community has token permissions of type `BECOME_MEMBER`, the
following happens when the owner receives a request:

1. Upon verifying provided wallet addresses by the requester, the owner
   node accumulates all token funds related to the given wallets that
   match the token criteria in the configured permissions
2. If the requester does not meet the necessary requirements, the
   request to join will be declined. If the requester does have the
   funds, he'll either be automatically accepted to the community, or
   enters the next stage where an owner needs to manually accept the
   request.
3. The the community does not automatically accept users, then the funds
   check will happen again, when the owner tries to manually accept the
   request. If the necessary funds do not exist at this stage, the
   request will be declined
4. Upon accepting, whether automatically or manually, the owner adds the
   requester's wallet addresses to the `CommunityDescription`, such that
   they can be retrieved later when doing periodic checks or when
   permissions have changed.
2023-03-23 08:40:31 +01:00
Pascal Precht 48eb705284 fix: add `decimals` to `TokenCriteria`
We need to store the `decimals` of a given token when creating community
permissions so that we can use it later on to do calculations when
checking funds for given wallet addresses.
2023-03-22 14:31:36 +01:00
Pascal Precht 051314aad0 feat: add verified wallet accounts to community requests
This commit extends the `CommunityRequestToJoin` with `RevealedAddresses` which represent wallet addresses and signatures provided by the sender, to proof a community owner ownership of those wallet addresses.

**Note: This only works with keystore files maanged by status-go**

At high level, the follwing happens:

1. User instructs Status to send a request to join to a community. By adding a password hash to the instruction, Status will try to unlock the users keystore and verify each wallet account.
2. For every verified wallet account, a signature is created for the following payload, using each wallet's private key

   ``` keccak256(chatkey + communityID + requestToJoinID) ``` A map of walletAddress->signature is then attached to the community request to join, which will be sent to the community owner
3. The owner node receives the request, and if the community requires users to hold tokens to become a member, it will check and verify whether the given wallet addresses are indeed owned by the sender. If any signature provided by the request cannot be recovered, the request is immediately declined by the owner.
4. The verified addresses are then added to the owner node's database such that, once the request should be accepted, the addresses can be used to check on chain whether they own the necessary funds to fulfill the community's permissions

The checking of required funds is **not** part of this commit. It will be added in a follow-up commit.
2023-03-22 13:50:25 +01:00
Pascal Precht f5475ed45c fix: add missing `Name` property to `CommunityTokensMetadata` 2023-03-07 16:37:36 +01:00
Michal Iskierko 1b24342a75 feat(CommunityTokenMetadata): Keep token metadata in CommunityDescription
Community tokens has some metadata (image, description) which must be kept in waku(CommunityDescription).
Add CommunityTokenMetadata message to communities.proto.
Add []CommunityTokenMetadata to CommunityDescription.

Issue #9545
2023-03-07 08:40:47 +01:00
Pascal Precht 596660c110 feat: add CommunityTokenPermission to community description
This adds token permission capabilities to CommunityDescription such that token permissions can be created, updated and deleted.
2023-03-03 09:46:49 +01:00
Pascal Precht 2ef10f23e5 feat(protobuf): introduce `CommunityTokenType` enum
This is a shared enum type that will be used by `CommunityDescription`
and community token permission protobuf (introduced in a future commit).
2023-03-03 08:20:51 +01:00
Pascal Precht dd8be1d8b0 feat(communities): add magnetlink to RequestToJoinResponse
This is done so that when member join a community by being accepted by
the community owner, they also receive the most up-to-date magnetlink
along with it.
2022-12-14 13:43:43 +01:00
frank 684e9654de
Allow owner/admin to delete messages of a community (#2958) 2022-12-02 19:34:02 +08:00
Boris Melnik 63d46481fd
feat(communities): Cancel request to join community (#2915) 2022-10-28 11:41:20 +03:00
Pascal Precht c01ad05525 feat(common): add `ThirdPartyID` to `Message` and `protobuf.WakuMessage`
Usually, message IDs are generated by their payload and signature and
in receiving nodes calculated in based on the same data as well.

There's no ID attached to messages in-flight.

This turns out to be a bit of a problem for messages that are being
imported from third party systems like discord, as the conversion
and saving of such messages and handling of their possible assets and
attachments are done in separate steps, which changes the message
payloads after their IDs have been generated.

Hence, we're introducing a `ThirdPartyID` property to `common.Message`
and `protobuf.WakuMessage` so receiving nodes of such messages (via the
archive protocol primarily) can easily detect third party/imported
messages and give them special treatment.
2022-09-29 11:15:47 +02:00
Patryk Osmaczko 7e25a6125f feat: introduce and distribute RequestToLeave community
closes: #2812
2022-08-26 11:25:33 +02:00
siddarthkay 924820c14a Implement wallet connect session CRUD API 2022-08-19 12:32:00 +01:00
Pascal Precht d0e0deac95 feat: introduce `discord_message_authors` persistence APIs
This introduces a new table to store discord message authors.
The main reason this table is being introduce is so that we don't have
to duplicate discord message author information in the `user_messages`
table when importing discord communities (ongoing work).

In addition to the table there are also two new APIs on the messenger
persistence layer (which are later used in the import logic):

- `HasDiscordMessageAuthor`
- `SaveDiscordMessageAuthor`

Closes #2759
2022-08-10 10:13:55 +02:00