Commit Graph

295 Commits

Author SHA1 Message Date
Anthony Laibe 9d782edb4d feat: wallet custom token with communities 2023-08-22 12:41:35 +02: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
Mykhailo Prakhov d1db60918d
feat: owner and token master permissions (#3912) 2023-08-18 17:29:44 +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 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
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 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
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
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
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 a06984aeec Ensured time was a value and implemented explicit RekeyCommunity() 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
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
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
Jonathan Rainville 11a3f495bd
fix: only save/send request to join when the permissions are satisfied (#3748) 2023-07-14 13:06:37 -04: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
Pascal Precht 4305147f7a feat: add cropping support for community token assets
This commit extends the `AddCommunityToken` API to also expect an
optional `CroppedImage`, which will be used instead of the `ImageBase64`
path provided by `CommunityToken`, to calculate the actual base64
encoded image.
2023-07-05 11:46:23 +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
Andrea Maria Piana db56132d01 Avoid publishing on a channel if manager stopped 2023-06-29 13:04:49 +01:00
Patryk Osmaczko c53723705c chore: add TestBecomeMemberPermissions integration test 2023-06-29 10:02:09 +02:00
Pascal Precht db65d42912 fix: default to attaching all support chainIDs in membership requests
There's only one scenario in which a `RevealedAccount` will have an
empty `ChainIDs` list attached to it:

When the community in question requires users to satisfy certain
criteria to join, and the user's wallet does not own the necessary funds
on any of the supported chains.

If there are **no** permissions to join on the community, then we want
to reveal all (selected) accounts with all supported chainIDs.

This is necessary so that, once the community *does* become
permissioned, it'll have address + chain information from all joined
members.

Closes: https://github.com/status-im/status-desktop/issues/11255
2023-06-29 08:46:02 +02:00
Pascal Precht b8b402da8d feat: store check channel permission responses
This commit adds new tables to the database and APIs in `Messenger` and
communities `Manager` to store `CheckChannelPermissionsResponse`s.

The responses are stored whenever channel permissions have been checked.

The reason we're doing this is so that clients can retrieve the last
known channel permission state before waiting for onchain checks to
finish.
2023-06-27 12:13:59 +02:00
Mikhail Rogachev 2fb87b5f0d
Chore: improve mocking for community tests (#3637)
* chore: different wallet addresses for different users in community tests

* chore: fix naming for account.Manager interface
2023-06-21 16:13:31 +04:00
Pascal Precht bf64f97d5a feat: introduce `CheckAllCommunityChannelsPermissions()` API
This API is used to get a permission status of all channels of a given
community.

Clients can use this API to get the provided information for all
community channels with a single RPC call instead of doing one call
for each channel separately.
2023-06-20 10:06:44 +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
Pascal Precht f702b54d08 fix: don't check permissions if revealed accounts aren't legit
This seems to be a bug that was introduced when two features, admin
permissions and "always reveal wallet accounts" where merged.

We need to make sure we **first** check the revealed accounts and only
**then** do we perform permission checks on them. Otherwise we can run
into scenarios where fake addresses are used and users will be accepted
to the community.
2023-06-19 15:27:10 +02:00
Pascal Precht a36202ff30 fix: don't return with error in permissions check when no chain IDs are
found

Turns out that, when we return with an error, instead of
a non-statisfied check permissions response, we can run into cases where
members that should be kicked are not kicked.
2023-06-19 15:26:42 +02:00
Boris Melnik 1eb92a19a2
feat(communities): Adds muting interval to community (#3549) 2023-06-17 11:19:05 +03:00
Mikhail Rogachev 51e3d800bb
fix: save revealed accounts regardless of permissions granted (#3609) 2023-06-16 11:10:32 +04:00
Michal Iskierko ccde92377d feat(BurnCollectibles): Add burn collectibles functionality
Change smart contract with new API.
Update gas amount for deployment.
Add Burn() and EstimateBurn() functions.
Add RemainingSupply() functions.

Issue #10816
2023-06-15 15:38:19 +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
Patryk Osmaczko 15d2b4fe80 feat: add configurable throttling mechanism for importing msgs
part of: status-im/status-desktop#10815
2023-06-06 08:49:02 +02:00
Pascal Precht ffc1006953 Add permission checks for ENS token permissions
Also add tests for creating and editing token permissions
as well as a test for checking ENS ownership.
2023-06-05 13:10:48 +02:00
Jonathan Rainville a6285cc827
Fix chats reseting when a Sync signal comes for communities (#3539)
* fix(community): stop re-joining comm when receiving a sync community msg

Fixes an issue with chats being reset. Since joining a community resaves the chats with the synced default value, it resets the sate of the chats, losing the unread messages, the muted state and more.
The solution is to block the re-joining of the community. In the case of the sync, we catch that error and just continue on.

* fix(import): fix HandleImport not saving the chat

Doesn't change much, but it could have caused issues in the future, so since we might have modified the chat, we make sure to save them
Also adds a test

* fix tests
2023-05-29 13:57:05 -04:00
Andrea Maria Piana 6acb34bab7 Allow setting up wallet with new config
This commit does a few things:

1) Extend create/import account endpoint to get wallet config, some of
   which has been moved to the backend
2) Set up a loop for retrieving balances every 10 minutes, caching the
   balances
3) Return information about which checks are not passing when trying to
   join a token gated community
4) Add tests to the token gated communities
5) Fixes an issue with addresses not matching when checking for
   permissions

The move to the wallet as a background task is not yet complete, I need
to publish a signal, and most likely I will disable it before merging
for now, as it's currently not used by desktop/mobile, but the PR was
  getting to big
2023-05-19 13:23:21 +01:00
Jonathan Rainville edf8869ff2
fix(communities/manager): use sync.map to fix concurrent map writes err (#3445) 2023-05-05 14:13:55 -04:00
Jonathan Rainville b7767ea63c
fix(communities/manager): make historyArchiveTasks a SyncMap (#3448)
Fixes #3447
2023-05-05 12:40:18 -04:00
Michal Iskierko 4935848287 fix(GetAllCommunityTokens): Add GetAllCommunityTokens function
Issue #10254
2023-05-05 18:14:55 +02:00
osmaczko 83998272dd
feat: add featured communities (#3459) 2023-05-05 11:55:32 -04:00
mprakhov 57b2432290 Community encryption should automatically be enabled/disabled depending on community permissions (closed/open) 2023-05-05 17:32:39 +02:00
Boris Melnik ebf997bf63
fix(communities): Ignore requests to join from banned user (#3030) 2023-05-03 18:01:55 +03: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
Anthony Laibe 0c8ce79941 feat: returns tokens even when error 2023-03-31 19:22:53 +02:00
Andrea Maria Piana 522c578a35 Set keystore dir & network id 2023-03-30 13:39:54 +01:00
Pascal Precht 9267ad46c5 Check ownership of collectibles in community permissions
This adds an additional check for collectibles when community
permissions are validated.

Specifically this uses opensea to request all NFTs given an
owner wallet and a list of contract addresses (collectibles).
2023-03-29 18:20:09 +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 79365ef576 fix(community-requests): block community requests from rejected users 2023-03-27 10:29:12 -04:00
Pascal Precht 7bc03e22f7 Do not automatically decline requests in manual accept
When community owners accept pending requests manually, they would be
declined in that process if the request doesn't fullfill the required
token permission criteria.

We don't want this to automatically reject those requests anymore,
instead, owners have to manually reject the requests.
2023-03-23 12:04:59 +01:00
Pascal Precht 5ec9e1ac46 feat: check member permission funds periodically
This adds a periodic member permission check for every admin community
such that member funds are checked every hour.
2023-03-23 12:04:59 +01: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
Michal Iskierko 736766ec37 fix(AddCommunityToken): Change AddCommunityToken API call
The function returns object with image converted to base64 format.

Issue #9866
2023-03-22 13:45:53 +01:00
Andrea Maria Piana 5d81866957 Add request to response when canceling request 2023-03-14 13:50:18 +00:00
Pascal Precht f5475ed45c fix: add missing `Name` property to `CommunityTokensMetadata` 2023-03-07 16:37:36 +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
Michal Iskierko 8a296407f3 fix(GetCommunityTokens): Change API call - use only communityId param
Fix #9725
2023-03-06 10:46:41 +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
Richard Ramos e1ea1ccab5 chore: find free port for torrent if set as 0 2023-03-02 08:50:41 -04: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 c38ec00a2d Add community request to response when a response handled
In general, any time a piece of state is updated in the backend, that
should be propagated to the client through signals.

In this case, when a request was accepted, the client wasn't notified,
requiring them to re-fetch the accepted requests and causing
inconsistent state between status-go and client.
2023-02-07 13:17:19 +00:00
Pascal Precht f31e40264e refactor(import-tool): process import data in chunks
This commit refactors the discord import tool such that,
instead of loading all data to be imported into memory at
once, it will now perform the import on a per file basis.

This improves the memory pressure for the node performing
the import and seems to increase its performance as well.
2023-01-30 12:23:56 +01:00
Pascal Precht b5964348a1 fix(communities): ensure archive import is only cancelled if not already marked as such
There were cases where this caused a crash, as handling magnetlinks would try to close
an already closed tasked channel

See https://github.com/status-im/status-desktop/issues/8996 for more information.

This commit extends the task struct such that it can be marked as cancelled and safely
read and written by multiple go routines.
2023-01-24 08:58:40 +01:00
Pascal Precht eb2b4b7cdc refactor(Communities): ensure generated archives don't exceed max cap
This introduces an addition constraint to archive generation, in which the payload + signature size of all partitioned message that go into an archive should not exceed a certain
threshold.

This is to ensure that archives won't get too big when they are later read into memory.
2023-01-20 17:09:00 +01:00
Pascal Precht 1bab7ae056 refactor(communities): improve archive handling memory pressure
Instead of loading the entire torrent file into memory when trying
to extrract active messages, we now only read the chunks that are
necessary to decode any individual archive and then process
extracted messages in chunks.

This doesn't introduce a max cap of allowed memory yet, since the
chunk size depends entirely on the size of the archive, but this
will be done soon.
2023-01-18 15:45:13 +01:00
Pascal Precht b4bdfd3df6 Keep track of last seen magnetlink
This is to prevent processing magnetlinks if they haven't changed
2022-12-20 15:16:08 +01:00
Pascal Precht f5dfa58602 refactor(communities): better archive download handling
This commit makes a few changes to the community history archive
download routine to make it more robust:

1. Prior to this commit, even when there were no archives to be
   downloaded, we were still trying to extract messages from archive
   data.
2. Logs have been improved as they were sometimes showing confusing
   information
3. We now handle interruption of ongoing download + data import much
   better in case of multiple magnetlinks being processed in roughly the
   same time.
4. We now keep track of which archive has been successfully imported
   into the database. Without this, Status would consider any downloaded
   archives as "done" even though they haven't actually been imported
   into the database yet. This way Status should be able to pick up its
   work were it left of the last time, in case a user closes the app, or
   another magnetlink interrupts the ongoing process.
2022-12-13 16:13:15 +01:00
Pascal Precht 4bddfbd466 chore: better community archive protocol logs 2022-12-13 16:13:15 +01:00
Pascal Precht 8ac154ee0c fix: don't keep Messenger from starting when torrent client fails to
start

There are various cases that could make the torrent client fail to
start. We don't want this to keep the entire messenger from starting.
2022-12-06 18:19:36 +01:00
Michal Iskierko 8fc7d921a7 fix(ImportCommunity): Setting admin roles during import community.
Issue #7414
2022-12-06 10:25:21 +01:00
Pascal Precht 22b5690cda feat: add signal indicating that history messages are being imported
In order to give clients more insights about archive messages being
processed, we're adding this additional signal that informs clients when
the import of downloaded history archive messages has started.
2022-12-05 10:51:53 +01:00
frank 684e9654de
Allow owner/admin to delete messages of a community (#2958) 2022-12-02 19:34:02 +08:00
Pascal Precht 194f26f3b4 feat: add signal for starting history archive downloads 2022-12-01 16:12:00 +01:00
Boris Melnik 63d46481fd
feat(communities): Cancel request to join community (#2915) 2022-10-28 11:41:20 +03:00
Pascal Precht 0bdb596d3b feat: introduce discord import tool 2022-10-28 09:52:26 +02:00
Mikhail Rogachev 60cb15739d
feat(ActivityCenter): Add community membership AC notifications (#2886)
* feat(ActivityCenter): Add community request AC notification

* feat(ActivityCenter): Add CommunityID to AC notification

* feat(ActivityCenter): Add membership status for community membership AC notifications

* feat(ActivityCenter): Add tests for community notifications and fix naming

* Add notification for kicked from community action

* feat(ActivityCenter): Fix for missing notification objects for tests
2022-10-26 02:06:20 +04:00
Pascal Precht 0ccdec2985 feat(CommunitiesManager): introduce `CreateHistoryArchiveTorrentFromMessages` API
Prior to this commit we had a `CreateHistoryArchiveTorrent()` API which
takes a `startDate`, an `endDate` and a `partition` to create a bunch of
message archives, given a certain time range.

The function expects the messages to live in the database, which means,
all messages that need to be archived have to be saved there at some
point.

This turns out to be an issue when importing communities from third
party services, where, sometimes, there are several thousands of messages
including attachment payloads, that have to be save to the database
first.

There are only two options to get the messages into the database:

1. Make one write operation with all messages - this slow, takes a long
   time and blocks the database until done
2. Create message chunks and perform multiple write operations - this is
   also slow, takes long but makes the database a bit more responsive as
   it's many smaller operations instead of one big one

Option 2) turned out to not be super feasible either as sometimes,
inserting even a single such message can take up to 10 seconds
(depending on payload)

Which brings me to the third option.

**A third option** is to not store those imported messages as waku
message into the database, just to later query them again to create the
archives, but instead create the archives right away from all the
messages that have been loaded into memory.

This is significantly faster and doesn't block the database.

To make this possible, this commit introduces
a `CreateHistoryArchiveTorrentFromMessages()` API, and
a `CreateHistoryArchiveTorrentFromDB()` API which can be used for
different use cases.
2022-10-24 13:28:55 +02:00
Pascal Precht 7eb66d09e7 feat(communities): add encryption suppord to archive protocol 2022-10-24 12:35:38 +02:00
Pascal Precht 69e84b5673 feat(communities): retry downloading archive data
When fetching torrent info after receiving a magnet link,
it can happen that the request times out.

We want to retry downloading the data again at least once more
before giving up
2022-10-17 11:33:02 +02:00
Pascal Precht dd49c4c954 feat(communities): add archiveLogger for stdout logs
The default logger writes to `geth.log`, which makes debugging
the archive protocol pretty hard.

This adds an additional logger that logs to stdout, while keeping
the default logger intact for production.
2022-10-14 16:31:21 +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 ffc9aea24f fix: ensure torrent download does not finish too early 2022-10-05 13:13:16 +02:00
Pascal Precht c01ad05525 feat(common): add `ThirdPartyID` to `Message` and `protobuf.WakuMessage`
Usually, message IDs are generated by their payload and signature and
in receiving nodes calculated in based on the same data as well.

There's no ID attached to messages in-flight.

This turns out to be a bit of a problem for messages that are being
imported from third party systems like discord, as the conversion
and saving of such messages and handling of their possible assets and
attachments are done in separate steps, which changes the message
payloads after their IDs have been generated.

Hence, we're introducing a `ThirdPartyID` property to `common.Message`
and `protobuf.WakuMessage` so receiving nodes of such messages (via the
archive protocol primarily) can easily detect third party/imported
messages and give them special treatment.
2022-09-29 11:15:47 +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
Pascal Precht eb4ab9316c fix(communities): ensure existing archives are seeded on startup 2022-09-19 15:34:29 +02:00
Pascal Precht fd4488e504 feat: add signal to inform clients when all archives have been downloaded and handled
This adds a new `DownloadingHistoryArchivesFinished` signal to the
family of community archive signals. It's emitted when all to be
downloaded archives have been downloaded and handled.
2022-09-16 09:43:49 +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 7e25a6125f feat: introduce and distribute RequestToLeave community
closes: #2812
2022-08-26 11:25:33 +02:00
Pascal Precht 9b04633bb7 feat(communities): introduce `publish` flag in community manager APIs
This is so that we can control whether we want to publish the community
when it, or it's categories and channels, are created.

This is needed for the discord import so that we can create communities,
channels and categories without publishing the community and have it
show up in UIs too early.
2022-08-25 12:59:30 +02:00
Michal Iskierko e6a3f63ec7 feat: Add DeclinedRequestsToJoinForCommunity to API
Issue #6279
2022-08-22 13:43:26 +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
Michal Iskierko 72d2a97449 feat: unban user in community
Issue #2724
2022-07-04 09:02:33 +02: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 c3b0582cc9
feat: fetch curated communities from smart contract on optimism (#2685) 2022-06-02 08:17:52 -04:00
Stefan 63e58ba035 feat: add banner support for communities
Add banner image as a special `IdentityImage` beside "thumbnail" and "large"

Banner input cropped image processing

- Resize to keep in the limits of `BannerDim`
- Encode to match the file size limits define for banner
- Don't scale up. This can be done efficiently in the UI

Changes to `images` module

- Refactor `EncodeToBestSize` as `EncodeToLimits` to accept arbitrary dimensions
  and allow for custom size
- Define `DimensionLimits` for banner not to exceed 450 KB and a rough estimate
  for the ideal size
2022-05-27 14:42:14 +03:00
Pascal Precht 43d6305157 Handle history archive magnetlink messages
This introduces the ability for status notes to handle community
history archive magnetlinks. To make this work, a few things are needed:

1. A new database table has been introduced to store message archive
   hashes. This is necessary so status nodes can determine whether or
   not they need to download a certain archive
2. The messenger's `handleRetrievedMessages()` has been exteded to take
   magnetlink messages into account
3. New APIs were added to download torrent data given a magnetlink and
   also to extract messages from downloaded archives, which are then
   later fed to `handleRetrievedMessages`

Closes #2568
2022-05-10 11:27:31 +02:00
Roman Volosovskyi 9de4eb3c8a
Backup deleted communities 2022-04-14 18:01:07 +02:00
Pascal Precht 7032fc9dcc Introduce community history archive routine
This introduces logic needed to:

- Create WakuMessageArchives and and indices from store waku messages
- History archive torrent data to disk and create .torrent file from
  that
- Seed and unseed history archive torrents as necessary
- Starting/stopping the torrent client
- Enabling/disabling community history support for individual components
  and starting/stopping the routine intervals accordingly

This does not yet handle magnet links (#2568)

Closes #2567
2022-04-06 13:00:33 +02:00
Pascal Precht 364838532f Add torrent library dependency 2022-04-06 11:48:16 +02:00
Andrea Maria Piana 8a5f77dc37 Address linter issues 2022-03-28 13:14:12 +01: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 1ffcf23f9b Ensure owner is removed from community when leaving community
Prior to this commit, when a community owner leaves her community,
status-go would just set the `joined` flag to `false` without updating the
members list. This results in wrong data as the number of members doesn't
match the reality.

This commit removes the owner of the community from the members list
when she's leaving the community.
2021-11-17 11:50:04 +01: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
Jonathan Rainville 151edb3607
feat: add api to delete a community channel (#2266) 2021-07-30 13:05:44 -04:00
RichΛrd 44fe606155
fix: make the community id prefix optional in chat ids (#2273) 2021-07-02 14:07:49 -04:00
Jonathan Rainville 11c46edd8b
feat(community): add muted to community and function to set it (#2271) 2021-06-30 09:29:43 -04:00
Eric Mastro a62e76d3ed
Change community channel description (#2236)
Co-authored-by: Volodymyr Kozieiev <vkjr.sp@gmail.com>
2021-06-01 15:13:17 +03:00
RichΛrd 92032c7158
Community categories (#2228)
* create and edit community categories
* edit categories order
* adding category to chat
* Adding categories to json
2021-05-23 09:34:17 -04:00
Eric Mastro 4d8d3fb0e8
feat: Add edit communities (#2229)
* feat: Add edit communities

Allow Communities to be edited, including display name, description, color, membership, and permissions.

* Added EditCommunity request type

* Fix lint errors

* Allow editing community without changing image

Previously, retaining an existing community image was not possible because the existing community image path had to be provided in the `editCommunity` RPC call to retain the image. However, once the image is processed by status-go, it is encoded as a base64 string and therefore it is not possible to get the original file path back from this string.

This commit allows for the original to be retained by passing an empty string for the image field in the RPC call.

* Don't change permissions. Fixed clock updating

Co-authored-by: Volodymyr Kozieiev <vkjr.sp@gmail.com>
2021-05-18 15:32:15 -04:00
Andrea Maria Piana d22182ea82 Ban user from community
This commit introduces a new endpoint to ban a user from a community.

Messages from this user will be ignored.
2021-03-24 09:29:21 +01:00
Andrea Maria Piana f115b8d289 Request/Decline access to communities 2021-02-26 15:35:43 +01:00
Andrea Maria Piana b4905fdbd4 address feedback 2020-12-23 17:20:55 +01:00
Andrea Maria Piana 3be6d86326 Remove user from community 2020-12-23 17:20:55 +01:00
Andrea Maria Piana a0d5f66c8f Leave import community data 2020-12-23 17:20:55 +01:00
Andrea Maria Piana 5d929c3584 Handle organisation membership requests 2020-12-23 17:20:55 +01:00