Commit Graph

11 Commits

Author SHA1 Message Date
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 bb7273cf6f feat: allow for pending community request state changes
iterates: status-im/status-desktop#11842
2023-10-05 09:24:45 +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
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
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
Mohamed Javid 0eff61c57a
Community request to join changes for pending and declined states (#3387)
* Community request to join changes

* Fix read state for request to join notification

* Bring back deleted notification when updated with response

* Update Request timeout to 7 days

* Update VERSION
2023-04-21 14:48:47 +05:30
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
Boris Melnik 63d46481fd
feat(communities): Cancel request to join community (#2915) 2022-10-28 11:41:20 +03:00
Patryk Osmaczko 7e25a6125f feat: introduce and distribute RequestToLeave community
closes: #2812
2022-08-26 11:25:33 +02:00
Samuel Hawksby-Robinson 89251e8416
Sync Communities (#2253)
* Added community sync protobuf

* Updated community sync send logic

* Integrated syncCommunity handling

* Added synced_at field and tidied up some other logic

* persistence testing

* Added testing and join functionality

* Fixed issue with empty scan params

* Finshed persistence tests for new db funcs

* Midway debug of description not persisting after sync

* Resolved final issues and tidied up

* Polish

* delint

* Fix error not handled on SetPrivateKey

* fix infinite loop, again

* Added muted option and test fix

* Added Muted to syncing functions, not just in persistence

* Fix bug introduced with Muted property

* Added a couple of notes for future devs

* Added most of the sync RequestToJoin functionality

Tests need to be completed and tests are giving some errors

* Finished tests for getJoinedAndPending

* Added note

* Resolving lint

* Fix of protobuf gen bug

* Fixes to community sync tests

* Fixes to test

* Continued fix of e2e

* Final fix to e2e testing

* Updated migration position

* resolve missing import

* Apparently the linter spellchecks

* Fix bug from  #2276 merge

* Bug fix for leaving quirkiness

* Addressed superfluous MessengerResponse field

* Addressed feedback

* VERSION bump
2021-08-06 16:40:23 +01:00
Andrea Maria Piana f115b8d289 Request/Decline access to communities 2021-02-26 15:35:43 +01:00