Commit Graph

195 Commits

Author SHA1 Message Date
Patryk Osmaczko bd245ab45b refactor: unify `Owned()` and `ControlledCommunities()` 2023-10-22 21:50:41 +02:00
Patryk Osmaczko 345851c396 feat: ensure unique control node across devices
closes: status-im/status-desktop#11962
2023-10-22 21:50:41 +02:00
frank 624996a7e9
only sync decisions/state of AC notifications (#3979) 2023-10-22 17:41:20 +08:00
Patryk Osmaczko eb232d4680 fix: use `messengerSignalsHandler` instead of global object 2023-10-20 18:09:12 +02:00
Patryk Osmaczko 246b68a8c0 refactor: rename and simplify `UpdatePrivateKeyAndControlNode` 2023-10-18 22:32:29 +02:00
Patryk Osmaczko a9cde06e44 refactor: simplify community requests logic
With the recent introduction of pending states, the community requests
logic became more complex. This commit simplifies the flow and
appropriately delegates logic to its corresponding abstraction levels:
messenger, manager and community. Additionally, it eliminates
redundancies in notifications and request-saving mechanism.
2023-10-18 17:11:20 +02:00
Patryk Osmaczko b932cc97bb fix: ensure owners and token masters receive revealed addresses with
request to join
2023-10-18 17:11:20 +02:00
Patryk Osmaczko 0881d8cdb0 Add queue for processing community description & configurable control node 2023-10-17 21:00:24 +01:00
Richard Ramos ace5b26137 fix: do not send the requests to join and cancel in the protected topic 2023-10-12 17:07:57 -04: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
Igor Sirotin da3df63eb1
chore: improve requesting contact/community info from mailserver (#4110) 2023-10-06 17:30:22 +01:00
Jonathan Rainville 17cef5f211
feat(messenger_communities): only send updated curated communities (#4056)
Fixes #4029
2023-09-26 12:47:50 -04:00
Dario Gabriel Lipicar ba5cd9c1a4 feat(wallet): add community info to collectibles 2023-09-22 17:55:30 -03:00
Jonathan Rainville 0f065a9f07
chore(messenger_communities): up unknown curated communities timeout (#4046) 2023-09-22 11:14:06 -04:00
Mykhailo Prakhov db9adb631f
feat: share requests to join and revealed addresses with privileged roles (#3951)
- share requests to join with new privileged roles during reevaluating member role
- share requests to join with new members, joined the community as TOKEN_MASTER, ADMIN
- share requests to join revealed addresses to ADMINS and TOKEN_MASTERS
- refactor common test functionality to make them more predictable
- removed unused CommunityToken protobuf
2023-09-20 10:37:46 +02:00
Igor Sirotin daf3fc79bf
fix: Discord import tool various fixes for pinned messages (#4001) 2023-09-15 15:19:10 +01:00
Boris Melnik 5e8300d6a1
fix(archives): Skip importing the archives for community when user not a member (#4006) 2023-09-15 10:42:28 +03:00
Igor Sirotin 5422b867f3
Hotfix: mark `Chat` and `Pin` archive messages as seen (#3992) (#3999) 2023-09-07 13:33:20 +03:00
Jonathan Rainville f7b342bb07
feat(shared_addresses): save own shared addresses in DB (#3950) 2023-08-29 14:56:30 -04:00
Andrea Maria Piana 4fba5647d1
Use NewContractMaker for messenger 2023-08-29 14:17:49 +01:00
Andrea Maria Piana 8c41678520
Fix contract call for communities 2023-08-29 13:02:26 +01:00
Richard Ramos d900974519 fix: code review 2023-08-23 13:56:00 -04:00
Richard Ramos f9ec588c4e feat: use protected topics for communities
refactor: associate chats to pubsub topics and populate these depending if the chat belongs to a community or not
refactor: add pubsub topic to mailserver batches
chore: ensure default relay messages continue working as they should
refactor: mailserver functions should be aware of pubsub topics
fix: use []byte for communityIDs
2023-08-23 13:56:00 -04: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
Jonathan Rainville 3bf0bed78d
Fix pending join requests + API to get them (#3902)
Needed for https://github.com/status-im/status-desktop/issues/11851
2023-08-18 15:52:13 -04:00
Jonathan Rainville 5272f99b59
feat(communities): add addresses to check channel permissions functions (#3910) 2023-08-18 15:50:23 -04:00
Mykhailo Prakhov d1db60918d
feat: owner and token master permissions (#3912) 2023-08-18 17:29:44 +02:00
Mikhail Rogachev 6d3e6d1b5d
Fix fetching revealed accounts in `GetCommunityMembersForWalletAddresses` (#3891)
https://github.com/status-im/status-desktop/issues/11143
2023-08-17 02:05:32 +04:00
Mykhailo Prakhov e7f5f32298
feat: synchronize community token between TokenMasters and Owners (#3893) 2023-08-15 19:42:40 +02:00
Boris Melnik cd4ed51a25
feat(community-permissions): Adds addresses feild to check permissions request (#3858) 2023-08-15 13:26:23 -04:00
Mykhailo Prakhov 7eac9b170c
feat: community privileged user sync message (#3879) 2023-08-15 17:27:01 +02:00
Michal Iskierko 9d0acc2265 feat(OwnerToken): Owner token and master token deployment
Adding new smart contracts and generated go files.
Deploy token owner function and master token address getter.
Adding deployer and privilegesLevel columns to community_tokens table.
Passing addressFrom to API calls.

Issue #11250
2023-08-14 20:57:00 +02:00
Mikhail Rogachev 0950721a6d
feat: add 'GetCommunityMembersForWalletAddresses' endpoint (#3854)
For https://github.com/status-im/status-desktop/issues/11143
2023-08-14 12:59:02 +04:00
Patryk Osmaczko 8b9ee803e2 feat: auto re-apply rejected community events
closes: status-im/status-desktop#11552
2023-08-11 12:46:45 +02:00
Jonathan Rainville b4b0d26aa4
feat(api): add api to get members revealed accounts (#3864) 2023-08-09 11:08:20 -04:00
Pascal Precht 4b07960fba feat: rehydrate community_tokens table upon account recovery
Closes https://github.com/status-im/status-desktop/issues/11188
2023-08-09 13:38:59 +02:00
Pascal Precht 248e4a7f24 refactor: EventSenders forward RequestToJoin decision to control node
This is a bigger change in how community membership requests are handled
among admins, token masters, owners, and control nodes.

Prior to this commit, all privileged users, also known as
`EventSenders`, were able to accept and reject community membership
requests and those changes would be applied by all users.

This commit changes this behaviour such that:

1. EventSenders can make a decision (accept, reject), but merely forward
   their decision to the control node, which ultimately has to confirm
   it
2. EventSenders are no longer removing or adding members to and from
   communities
3. When an eventsender signaled a decision, the membership request will
   enter a pending state (acceptedPending or rejectedPending)
4. Once a decision was made by one eventsender, no other eventsender can
   override that decision

This implementation is covered with a bunch of tests:

- Ensure that decision made by event sender is shared with other event
  senders
  - `testAcceptMemberRequestToJoinResponseSharedWithOtherEventSenders()`
  - `testRejectMemberRequestToJoinResponseSharedWithOtherEventSenders()`
- Ensure memebrship request stays pending, until control node has
  confirmed decision by event senders
  - `testAcceptMemberRequestToJoinNotConfirmedByControlNode()`
  - `testRejectMemberRequestToJoinNotConfirmedByControlNode()`
- Ensure that decision made by event sender cannot be overriden by other
  event senders
  - `testEventSenderCannotOverrideRequestToJoinState()`

These test cases live in three test suites for different event sender
types respectively

- `OwnerWithoutCommunityKeyCommunityEventsSuite`
- `TokenMasterCommunityEventsSuite`
- `AdminCommunityEventsSuite`

In addition to the changes mentioned above, there's also a smaller
changes that ensures membership requests to *not* attached revealed wallet
addresses when the requests are sent to event senders (in addition to
control nodes).

Requests send to a control node will still include revealed addresses as
the control node needs them to verify token permissions.

This commit does not yet handle the case of event senders attempting to
kick and ban members.

Similar to accepting and rejecting membership requests, kicking and
banning need a new pending state. However, we don't track such state in
local databases yet so those two cases will be handled in future commit
to not have this commit grow larger.
2023-08-08 14:46:03 +02:00
Volodymyr Kozieiev 7560540392
Regularly update the list of curated communities (#3827)
Regularly update the list of curated communities
2023-08-07 13:54:00 +01: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 9eaf229161 refactor: improve community functions naming 2023-08-02 19:59:16 +02:00
Jonathan Rainville 9267e58143
feat(api): add GetCommunityPublicKeyFromPrivateKey to api (#3828) 2023-08-02 13:11:26 -04:00
Mykhailo Prakhov 89253ac684
fix: owner without community private key and token master was not able send all admin events (#3819) 2023-07-28 20:18:27 +02:00
Patryk Osmaczko c1a98005e9 chore: signal client with published community
Some of the changes done to the community are done async, client must
be notified about them to relfect current state.
2023-07-28 18:13:15 +02:00
Patryk Osmaczko 367b7722d1 feat: introduce channel-level encryption
- distribute ratchet keys at both community and channel levels
- use explicit `HashRatchetGroupID` in ecryption layer, instead of
  inheriting `groupID` from `CommunityID`
- populate `HashRatchetGroupID` with `CommunityID+ChannelID` for
  channels, and `CommunityID` for whole community
- hydrate channels with members; channel members are now subset of
  community members
- include channel permissions in periodic permissions check

closes: status-im/status-desktop#10998
2023-07-27 11:35:59 +02:00
Patryk Osmaczko 30da8390bd feat: introduce CommunitiesKeyDistributor
This component decouples key distribution from the Messenger, enhancing
code maintainability, extensibility and testability.
It also alleviates the need to impact all methods potentially affecting
encryption keys.
Moreover, it allows key distribution inspection for integration tests.

part of: status-im/status-desktop#10998
2023-07-27 11:35:59 +02:00
Patryk Osmaczko fa5b316324 chore: deprecate InviteUsersToCommunity 2023-07-27 08:45:01 +02:00
Pascal Precht 3d1b1bab57 feat: introduce messenger API to remove community tokens
This is to allow users to remove a community token if the deployment
transaction has been rejected.
2023-07-26 15:57:08 +02:00
Pascal Precht e8bac916ec !refactor: introduce `SaveCommunityToken()` and change `AddCommunityToken()`
**This is a breaking change!**

Prior to this commit we had `AddCommunityToken(token *communities,
croppedImage CroppedImage)` that we used to

1. add a `CommunityToken` to the user's database and
2. to create a `CommunityTokenMetadata` from it which is then added to
   the community's `CommunityDescription` and published to its members

However, I've then discovered that we need to separate these two things,
such that we can deploy a community token, then add it to the database
only for tracking purposes, **then** add it to the community description
(and propagate to members) once we know that the deploy tx indeed went
through.

To implement this, this commit introduces a new API
`SaveCommunityToken(token *communities.CommunityToken, croppedImage
CroppedImage)` which adds the token to the database only and doesn't
touch the community description.

The `AddCommunityToken` API is then changed that it's exclusively used
for adding an already saved `CommunityToken` to the community
description so it can be published to members. Hence, the signature is
now `AddCommunityToken(communityID string, chainID int, address
string)`, which makes this a breaking change.

Clients that used `AddCommunityToken()` before now need to ensure that
they first call `SaveCommunityToken()` as `AddCommunityToken()` will
fail otherwise.
2023-07-26 14:45:02 +02:00