Commit Graph

195 Commits

Author SHA1 Message Date
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
Mykhailo Prakhov d1db60918d
feat: owner and token master permissions (#3912) 2023-08-18 17:29:44 +02:00
Ivan Belyakov 2df9df10ab fix(tests): moved test db setup to a common place 't/helpers', created
interface for initializing db, which is implemented for appdatabase and
walletdatabase. TBD for multiaccounts DB.
Unified DB initializion for all tests using helpers and new interface.
Reduced sqlcipher kdf iterations for all tests to 1.
2023-08-18 09:00:56 +02:00
Patryk Osmaczko d0f304c262 refactor: simplify events creation logic
- use `roles_authorization.go` APIs as the ultimate source of truth
- unify&simplify community modifications in terms of events creation
2023-08-17 08:24:51 +02:00
Patryk Osmaczko 1a05c84585 chore: remove `ROLE_MANAGE_USERS` and `ROLE_MODERATE_CONTENT`
closes: #3895
2023-08-16 21:38:04 +02:00
Patryk Osmaczko a42e2907b9 fix: revert wrong conflict resolution
introduced by 1bc0d37b40
2023-08-16 16:44:24 +02:00
Mykhailo Prakhov e7f5f32298
feat: synchronize community token between TokenMasters and Owners (#3893) 2023-08-15 19:42:40 +02: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
frank daa9ad4e05
added nil checking for communitiesManager.GetByID (#3877) 2023-08-11 19:17:34 +08: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 1d2b508c20
fix(communities_manager): fix joining community with admin permission (#3870)
Fixes an issue where if a community had an admin permission, it would be impossible to join as a normal member because the admin permission wasn't satisfied.
2023-08-10 11:46:38 -04:00
Patryk Osmaczko 400ba52289 fix: ensure CommunityDescription msg kept in db is signed
closes: status-im/status-desktop#11859
2023-08-10 17:09:30 +02:00
Patryk Osmaczko dbd52edcd7 feat: sign community events
closes: status-im/status-desktop#11834
2023-08-09 13:53:32 +02: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 688fb333a0 chore: don't expose `RevealedAccount`s on community description
Prior to this commit a control node would add the revealed addresses to
the member struct on the community description, which exposes all those
addresses to the public.

We don't want that. Revealed addresses are exclusively shared with
control nodes and should stay there (although, they might be privately
shared among token masters, see
https://github.com/status-im/status-desktop/issues/11610).

In this commit, we no longer add the revealed addresses to the community
description. The addresses are already stored in the requestToJoin
database table so we can take them from there if we need them.

Closes: https://github.com/status-im/status-desktop/issues/11573
2023-08-08 19:02:47 +02:00
Mykhailo Prakhov ebadfb3e7b
feat: allow owner without community private key to manage privileged community permissions (#3861)
feat: allow owner without community private key to manage privileged permissions
2023-08-08 17:02:56 +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
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 9ae632893c refactor: rename 'permissions' to 'roles' in community module
This renames various instances of 'permissions' to 'roles' where
appropriate to ensure consistency and clarity of purpose.
2023-08-02 23:04:58 +02:00
Patryk Osmaczko 47c568fb08 refactor: improve wrapped community description naming 2023-08-02 20:57:19 +02:00
Patryk Osmaczko 9eaf229161 refactor: improve community functions naming 2023-08-02 19:59:16 +02:00
Pascal Precht 75cd002863 chore: don't process request to join if admin and community is set to
auto-accept
2023-08-01 12:19:22 +02:00
Pascal Precht d5203c5e53 chore: add token masterr to `MemberRole()` 2023-08-01 11:51:19 +02: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 bb942f6c8f fix: increase community clock with channel members changes 2023-07-28 18:13:15 +02:00
Dario Gabriel Lipicar b1cf54974e chore: make opensea client return common types 2023-07-27 12:12:03 -03:00
Dario Gabriel Lipicar 849be69299 chore: use single opensea client instance 2023-07-27 12:12:03 -03:00
Patryk Osmaczko cec81796dc fix: add all members to channel when it is no longer token-gated 2023-07-27 11:35:59 +02:00
Patryk Osmaczko 971fc0c816 fix: populate channels with all members for existing communities 2023-07-27 11:35:59 +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
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
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
Mykhailo Prakhov c77878bbfb
chore: make the owner without the community private key behave like a… (#3788)
* chore: make the owner without the community private key behave like an admin
* Add test for the owner without community key
* chore: refactor Community fn names related to the roles
2023-07-26 14:16:50 +02:00
Samuel Hawksby-Robinson d60beb2283 refactor to remove rekeyedAt and use group current key 2023-07-24 17:18:42 +01:00
Samuel Hawksby-Robinson 2536d9c8ba Implemented testing to check rekeying is happening 2023-07-24 17:18:42 +01:00
Samuel Hawksby-Robinson 1e09a4bc37 Fix for community / messenger state changes 2023-07-24 17:18:42 +01:00
Samuel Hawksby-Robinson a06984aeec Ensured time was a value and implemented explicit RekeyCommunity() 2023-07-24 17:18:42 +01:00
Samuel Hawksby-Robinson 03e28eea0d Implement correct getter and setter functionality for Communities 2023-07-24 17:18:42 +01:00
Samuel Hawksby-Robinson 243135d744 Rekey loop basics 2023-07-24 17:18:42 +01:00
Patryk Osmaczko f1db6d1615 fix: remove redundancy in permissions check when handling request to join
- Fixed redundant permissions check. If community is set to auto-accept,
  then permissions would be checked twice, in
`HandleCommunityRequestToJoin` and `AcceptRequestToJoinCommunity`.
Mitigated it by returning from `HandleCommunityRequestToJoin` immediately
in case of auto-accept.

- Extracted `accountsSatisfyPermissionsToJoin` to remove code
  duplication and simplify the logic.
2023-07-21 20:41:34 +02:00
Mikhail Rogachev 631962ce88
feat: add api to remove private key (#3772)
* feat: add api to remove private key and separete owner from private key ownership

For https://github.com/status-im/status-desktop/issues/11475

* feat: introduce IsControlNode for Community

* feat: remove community private key from syncing

* feat: add IsControlNode flag to Community json serialisation

* Update protocol/protobuf/pairing.proto

Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>

---------

Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>
2023-07-21 13:41:26 +04:00
Mykhailo Prakhov ac64e33362
chore: validate CommunityDescription signature before sending/during receiving CommunityEventsMessage (#3784)
* chore: validate CommunityDescription in CommunityEventMessage

* Update protocol/communities/community_event.go
2023-07-21 11:38:34 +02:00
Patryk Osmaczko d9df8b6150 feat: add CommunityEncryptionKeyActions and its evaluation logic
Added utility that evaluates necessary encryption key actions based on
community changes.

part of: status-im/status-desktop#10998
2023-07-20 17:17:46 +02:00
Jonathan Rainville 12dc86fe1b
fix(persistence): fix get revealed accounts when isAirdropAddress is nil (#3780) 2023-07-19 15:23:00 -04:00
John Ngei cf2d72bfa8
Mute and Unmute community
* mute and unmute all community chats when community mute status changes

* unmute community when atleast one channel is unmuted

* fix: save community, extend the function to save muted state and mute duration
2023-07-19 15:14:42 +03:00
Dario Gabriel Lipicar 1f379aec1f feat: implemented multi chain collectible ownership provider 2023-07-19 07:58:05 -03:00