Commit Graph

16 Commits

Author SHA1 Message Date
Mykhailo Prakhov b9197510b1
fix: use community controlNode pubkey instead of community ID for verifying the received community data signer (#4411) 2023-12-04 10:56:54 +01:00
Vitaly Vlasov 1794b93c16 Always set PubsubTopic in filters 2023-11-18 02:26:34 +02:00
Mikhail Rogachev a17ee052fb
feat: Introduce KickedPending and BannedPending states (#3948)
* feat: introduce KickedPending state for community members

* feat: tests for ban/unban pending states

* fix: remove pending And banned members from public serialization

* feat: add check for banning and kicking privileged users

* fix: process only first event when obtaining PendingAndBannedMembers

* fix: review fixes

* fix: proper conditions for kicking and banning checks

* Fix: fix tests after rebase
2023-10-04 23:47:22 +03:00
Patryk Osmaczko a12e87dac6 feat: add pending state for token permissions
iterates: status-im/status-desktop#11852
2023-08-23 10:34:59 +02:00
Patryk Osmaczko 63131aebbc refactor: merge AddTokenPermission and UpdateTokenPermission 2023-08-23 10:34:59 +02: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
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 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 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 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 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 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
Mykhailo Prakhov 0919a87588
chore: community admin events (#3678)
chore: 
- add CommunityEventsMessage
- refactor community_admin_event to accept a list of events and patch a CommunityDescription
- save/read community events into/from database
- publish and handle community events message
- fixed admin category tests
- rename AdminEvent to Events or CommunityEvents
2023-07-18 17:06:12 +02:00