Commit Graph

167 Commits

Author SHA1 Message Date
Patryk Osmaczko e304fe3344 chore: enable community rekey loop 2023-10-27 16:29:26 +02:00
Patryk Osmaczko 3452eb72a8 refactor: remove community invitation only access 2023-10-25 17:34:37 +02:00
Patryk Osmaczko b262d7e88c refactor: rename Community.OnRequest() -> AutoAccept() 2023-10-25 17:34:37 +02:00
Patryk Osmaczko b321f28c9d refactor: update community access enum naming 2023-10-25 17:34:37 +02:00
Shinnok 3805662a18
fix(messenger_communities): block messages and reactions to token gated or spectated communities (#4064)
Which specifies that if a user is not a community member & a
chat member, he can't post, react or pin messages in that chat.

Notes:
- also fix&cleanup associated failing tests.
- refactor Community.CanPost() to reflect the new requirement.
- grant code is not fully implemented and is to be removed later.

Fixes https://github.com/status-im/status-desktop/issues/11915
2023-10-25 10:26:18 -04: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
Patryk Osmaczko fc8ce915af fix: prevent nil dereference in `IsControlNode` for existing communities 2023-10-19 22:11:53 +02:00
Patryk Osmaczko 05db628406 chore: omit `CommunityDescription` queuing if owner is already verified 2023-10-19 22:11:53 +02:00
Patryk Osmaczko 3292c1c883 feat: rekey community on control node change
closes: status-im/status-desktop#11963
2023-10-18 22:32:29 +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 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
Patryk Osmaczko 1410b1e422 fix: ensure community channels are dehydrated on publish 2023-10-10 20:11:31 +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
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 9d374bcadc chore: use lamport timestamp for communities
closes: status-im/status-desktop#11961
2023-10-03 21:45:28 +02:00
Patryk Osmaczko 475036e9f2 fix: stop sending channels members over the wire
fixes: status-im/status-desktop#12114
2023-09-26 13:01:30 +02: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
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
Patryk Osmaczko 8764170149 fix: expose token permission from events
Ensure token permission from events is returned by `tokenPermissions`.
2023-08-23 18:50:26 +02: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
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
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
Mykhailo Prakhov e7f5f32298
feat: synchronize community token between TokenMasters and Owners (#3893) 2023-08-15 19:42:40 +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
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
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
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
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 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
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
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
Patryk Osmaczko caca511aed refactor: extract community_changes 2023-07-17 12:48:47 +02:00
Andrea Maria Piana 3f5f87d1d1 Don't panic if config is nil in community
I have encountered a crash in the app after syncing, looks like a
community has been created without a Config.
This crashes the app after the user logs in.
This commit prevents the app from crashing, but does not fix the
underlaying issue (that's something I will have to investigate).
Added tests to validate the behavior.

Check community exists
2023-07-14 08:23:38 +01:00
Michal Iskierko ff0628c23b feat(Collectibles): Handle ERC20 burn and mint
Modify API to handle also ERC20 tokens.
Modify community_tokens table - keep supply as string since string is easly convertible to bigint.BigInt.
Use bigint.BigInt for supply functions and fields.

Issue #11129
2023-07-12 10:41:17 +02:00
Jonathan Rainville 2c275058ad
feat(community): add api to edit shared address (#3723) 2023-07-10 10:11:37 -04:00
Mikhail Rogachev 511d6bfc54
feat: add parsing for new links format (#3665)
* feat(share-links): Add protobuf and encode/decode url data methods

* feat(new-links-format): Adds generators for new links format

* feat: add parsing for new links format

* feat: add messenger-level pubkey serialization and tests

* feat: fix and test CreateCommunityURLWithChatKey

* feat: impl and test parseCommunityURLWithChatKey

* feat: fix and test CreateCommunityURLWithData

* feat:  impl and test parseCommunityURLWithData (not working)

* feat: UrlDataResponse as response share urls api

* feat: impl& tested ShareCommunityChannelURLWithChatKey

* feat: impl & tested ParseCommunityChannelURLWithChatKey

* fix: bring urls to new format

* feat: add regexp for community channel urls

* feat: impl & test contact urls with chatKey, Ens and data

* fix: encodeDataURL/encodeDataURL patch from Samyoul

* fix: fix unmarshalling protobufs

* fix: fix minor issues, temporary comment TestParseUserURLWithENS

* fix: allow url to contain extra `#` in the signature

* fix: check signatures with SigToPub

* chore: lint fixes

* fix: encode the signature

* feat: Check provided channelID is Uuid

* fix(share-community-url): Remove if community encrypted scope

* fix: review fixes

* fix: use proto.Unmarshal instead of json.Marshal

* feat(share-urls): Adds TagsIndices to community data

* feat: support tag indices to community url data

---------

Co-authored-by: Boris Melnik <borismelnik@status.im>
2023-07-04 17:48:52 +04:00
Pascal Precht 8184ae62ed fix: mark community as no longer spectated when joined
Fixes https://github.com/status-im/status-desktop/issues/11334
2023-07-04 15:35:37 +02: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
Pascal Precht a8678575a7 fix: admins are not allowed to kick or ban other admins 2023-06-27 09:14:26 +02:00
Pascal Precht 7938297606 feat: introduce `CheckChannelPermissions` API
Similar to `CheckPermissionToJoin()` we now get
a `CheckChannelPermissions()` API.

It will rely on the same `PermissionResponse` types, but gives
information about both `ViewOnlyPermissions` and
`ViewAndPostPermissions`.
2023-06-20 09:42:10 +02:00
Boris Melnik 1eb92a19a2
feat(communities): Adds muting interval to community (#3549) 2023-06-17 11:19:05 +03: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
mprakhov 57b2432290 Community encryption should automatically be enabled/disabled depending on community permissions (closed/open) 2023-05-05 17:32:39 +02:00
Patryk Osmaczko 8dd8b1ae45 feat: implement community members count
iterates: status-im/status-desktop#8016
2023-03-29 17:08:41 +02:00
Jonathan Rainville 329f5c8316 fix(community): only checkPermissions if the community has permissions 2023-03-27 10:31:12 -04:00
Pascal Precht 128f82df09 Perform token criteria checks on existing members
When a community permission is edited, we need to revalidate
the token criteria with the existing member list, as members might
no longer fulfill the requirements.

This commit runs the checks in a go routine after the permission has
been updated.
2023-03-23 08:53:43 +01: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 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 a6194ffad4 fix: don't expect `CommunityTokensMetadata` in `EditCommunity()`
The `Edit()` method on `Community` merely updates "primitive" values
that live inside a community description. For any data that is more complex,
we typically have dedicated methods.

Because `Edit()` was expecting `CommunityTokensMetadata`, it would
override it with empty data every time we would edit a community.
This is because we typically don't update that kind of data as part
of `Edit()`.

In addition, `CommunityTokensMetadata` is append-only anyways,
so there wouldn't be any other way to update that field, other than
adding new items to it, which is done in a dedicated method.
2023-03-07 16:07:48 +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
Michal Iskierko d0cc036d48 feat(CommunityTokens): Keep community token details in database
New table for community tokens.
API for get,add, update community token.

Issue #9233
2023-02-27 10:37:54 +01:00
Andrea Maria Piana ed9ca8392c Upgrade linter to 1.50.0 2023-01-13 17:52:03 +00:00
Jonathan Rainville e98e6b61af fix: use the uncompressed community pubkey as topic to receive requests 2023-01-11 13:41:29 -04:00
Michal Iskierko 8fc7d921a7 fix(ImportCommunity): Setting admin roles during import community.
Issue #7414
2022-12-06 10:25:21 +01:00
frank 684e9654de
Allow owner/admin to delete messages of a community (#2958) 2022-12-02 19:34:02 +08:00
Richard Ramos d4d35710be fix: community encryption was not being marshalled 2022-10-10 13:11:10 +02:00
Patryk Osmaczko 73a45dd58e feat: add `SpectateCommunity` api
- added `SpectateCommunity` endpoint, it is supposed to be used in
  scenarios where we want to "Go to public Community" and see its
  content without joining
- added `spectated` field to `Community`, it means we are observing the
  community and its chats but we are not members

Use case:
https://github.com/status-im/status-desktop/issues/7072#issuecomment-1246560885
2022-10-06 21:21:37 +02:00
Pascal Precht 81e279a055 chore(community): community itself has admin rights
This might look like a weird requirement at a fist glance.
The reason this is needed, is because some message signals require
admin rights to take effect (e.g. PinMessage).

When messages are imported from third-party services,
translated to status messages, signed by the community, and eventually distributed
via the archive protocol, we need to ensure that messages signed
by the community itself are considered as admin privileges as well,
so they can be correctly replayed into the database.
2022-09-28 13:03:56 +02:00
Patryk Osmaczko e4ca8a256c fix: remove ourselves from members when leaving community
Otherwise clients see invalid members count in invitation bubbles.
2022-09-21 08:35:52 +02:00
Patryk Osmaczko 65be6f2b96 feat: add and distribute `chatIdentity.FirstMessageTimestamp`
`FirstMessageTimestamp` enables members of the community to determine if
there are any messages they can fetch on the community channel(chat).

`FirstMessageTimestamp` is advertised by admin for each community chat
through `CommunityDescription`. It assumes admin is online frequently
enough to capture the first channel message.

For existing communities admin determines first message timestamp by
finding oldest chat message in its local database.

task: status-im/status-desktop#6731
2022-09-09 08:59:39 +02:00
Patryk Osmaczko e5e07408e2 feat: share image/username on separate topic on a community
closes: #2707
2022-07-20 10:35:19 +02:00
Pascal Precht f6c9ec7838 refactor: Require request access for all communities
This commit introduces a few changes regarding users accessing
communities:

While the APIs still exist, community invites should no longer be
used, instead communities should merely be "shared".
Sharing a community to users allows users to "join" the community,
which in reality makes them request access to that community.
This means, users have to request access to any community, even if
the community has permissions set to NO_MEMBERSHIP
Only difference between ON_REQUEST and NO_MEMBERSHIP is that
ON_REQUEST communities require manual approval of the owner/admin
to access a community. NO_MEMBERSHIP communities accept
automatically (as soon as owner/admin receives the request).
This also implies that users are no longer optimistically added to the
member list of communities, but only after they have been accepted.

This introduces a bit of a message ping-pong for users to know that
someone is now part of a community
2022-07-08 13:16:12 +02:00
Mikhail Rogachev 7ad0057003
feat(@communities): Add saving tags on community edit (#2739) 2022-07-04 16:56:00 +03:00
Michal Iskierko 72d2a97449 feat: unban user in community
Issue #2724
2022-07-04 09:02:33 +02:00
Richard Ramos 2873e65a61
feat: community tags (#2708)
Signed-off-by: Richard Ramos <info@richardramos.me>

Co-authored-by: MishkaRogachev <mishkarogachev@gmail.com>
2022-06-24 09:40:12 -04:00
Boris Melnik 8063152657
fix(community-edit): Save permissions when community edited (#2720)
Part of: https://github.com/status-im/status-desktop/issues/6073
2022-06-21 13:43:49 -04:00
Vitaliy Vlasov 4f722b6fe8 Communities encryption integration 2022-06-17 21:24:39 +03:00
Pascal Precht 9d5bcc3c60 feat: sync `CommunitySettings` across paired devices
This commit introduces a new `clock` field in the
`communities_settings` table so that it can be leveraged for syncing
community settings across devices.

It alsoe exends existing `syncCommunity` APIs to generate
`SyncCommunitySettings` as well, avoiding sending additional sync messages
for community settings.

When editing communities however, we still sync community settings
explicitly are we aren't syncing the community itself in that case.
2022-06-16 12:45:05 +02:00
Richard Ramos 9430f494be
fix: handle nil descriptions in communities for chat_getChats (#2694) 2022-06-08 08:46:52 -04:00
Patryk Osmaczko ee7025a573 feat: add intro/outro message to communities 2022-05-31 11:41:26 +02:00
Pascal Precht 714c03c635 feat: introduce `CommunityAdminSettings` in `CommunityDescription`
This allows to store community admin settings that are meant to be propagated
to community members (as opposed to the already existing
`CommunitySettings` which are considered local to every account).

The first setting introduced as part of this commit is one that enables
community admins to configure whether or not members of the community
are allowed to pin messages in community channels.

Prior to this commit, this was not restricted at all on the protocol
level and only enforced by clients via UI (e.g. members don't see an
option to pin messages, although they could).

This config setting now ensures that:

1. If turned off, members cannot send a pin message
2. If turned off, pin messages from members are not handled/processed

This is needed by https://github.com/status-im/status-desktop/issues/5662
2022-05-18 09:58:11 +02:00
Pascal Precht 3b3921f483 Make community owners store waku message payloads
This is needed so that when they are bundled into archives, receiving
nodes can still verify the messages payload using its signature.

This commit introduces a new `waku_messages` table and APIs to store
such messages. Waku message payload is store for any message that has
a topic that matches any of the admin communities chats.

Closes #2566
2022-03-28 11:24:23 +02:00
Pascal Precht bf8e71cfa9 Introduce `CommunitySettings` to store community related settings
These are used to store settings for individual communities a
user is part of, either as member or as owner.
This included whether or not the community history archive protocol
is enabled.

This adds a new `CommunitySettings` type and adds
a migration script that introduces a new `communities_settings`
table.

It also extends the `MessengerResponse` type to include
`CommunitySettings` which are honored when communities are being
added, edited, joined or left.

Lastly, this adds a new RPC API to retreive the settings.

Closes #2564
2022-03-22 12:33:40 +01:00
Pascal Precht 64b8ad5176 Ensure community owners and members subscribe to magnetlink channel
This commit adds the special magnetlink channel that is used to
distribute community archive magnetlinks to community members.

The channel shoudn't be visible in the UI, so instead creating an
actual channel instance, it just sets up the filters.

Closes #2565
2022-03-21 12:55:45 +01:00
Richard Ramos 9e833cd4c7 fix: add community status updates channel to list of filters on Init 2022-03-10 09:45:42 -04:00