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).
- `keypair_name` added to `accounts` table, all accounts derived from the
same master key have the same keypair name and also no two keypairs share
the same keypair name (keypair name is unique per keypair)
- `last_used_derivation_index` added to `accounts` table, cause we need
to maintain the highest index been used for the derivations made within
the same keypair
* Moved all configs into config.go
* Completed build out of new config structures
* Completed SenderClient process flow
* Completed sync data Mounter and client integration
* Completed installation data Mounter and client integration
* House keeping, small refactor to match conventions.
PayloadEncryptor is passed by value and used as a pointer to the instance value and not a shared pointer.
* Reintroduced explicit Mounter field type
* Completed ReceiverClient structs and flows
* Finished BaseClient function parity with old acc
* Integrated new Clients into tests
Solved some test breaks caused by encryptors sharing pointers to their managed payloads
* Built out SenderServer and ReceiverServer structs
With all associated functions and integrated with endpoints.
* Updated tests to handle new Server types
* Added docs and additional refinement
* Renamed some files to better match the content of those files
* Added json tags to config fields that were missing explicit tags.
* fix tests relating to payload locking
* Addressing feedback from @ilmotta
* Addressed feedback from @qfrank
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.
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.
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.
We need to store the `decimals` of a given token when creating community
permissions so that we can use it later on to do calculations when
checking funds for given wallet addresses.