Fixed logic to respect specified NFT quantities. Previously, holding one
NFT sufficed, regardless of the required count.
fixes: status-im/status-desktop#15122
That's an optimisation. Instead of fetching collectibles owners for each
member, it is fetched once, before members iteration.
It should significantly reduce amount of queries to providers.
closes: status-im/status-desktop#14914
Send information to owners and token masters about operations: burn, airdrop, remote destruct.
Add CommunityTokenActionSignal to signalize client side.
Fix#13371
Use EventWatcher to catch wallet events.
Handling all community tokens wallet events in communitytokens service (database and messenger operations).
Adding new signal to nim: CommunityTokenTransactionSignal, which is emitted everytime when the event is received.
Issue #4351
AmountInWei will have a wei-like units.
Amount field becomes deprecated because it kept string with float value.
Comparison (in case of Decimals == 5):
Amount (deprecated) = "1.2"
AmountInWei = "120000"
Issue #11588
The test was flaky because of re-receiving the message, which resulted
in multiple identical requestsToJoin being added to messengerResponse.
We should in general avoid using arrays in messengerResponse and prefer
maps for exactly this reason.
This commit fixes a few issues with communities encryption:
Key distribution was disconnected from the community description, this created a case where the key would arrive after the community description and that would result in the client thinking that it was kicked.
To overcome this, we added a message that signals the user that is kicked. Also, we distribute the key with the community description so that there's no more issues with timing.
This is a bit expensive for large communities, and it will require some further optimizations.
Key distribution is now also connected to the request to join response, so there are no timing issues.
Fixes an issue with key distribution (race condition) where the community would be modified before being compared, resulting in a comparison of two identical communities, which would result in no key being distributed. This commit only partially address the issue.
This commit adds basic syncing capabilities with peers if they are both
online.
It updates the work done on MVDS, but I decided to create the code in
status-go instead, since it's very tight to the application (similarly
the code that was the inspiration for mvds, bramble, is all tight
together at the database level).
I reused parts of the protobufs.
The flow is:
1) An OFFER message is sent periodically with a bunch of message-ids and
group-ids.
2) Anyone can REQUEST some of those messages if not present in their
database.
3) The peer will then send over those messages.
It's disabled by default, but I am planning to add a way to set up the
flags.
New contracts and contract go functions.
Adjust owner&master tokens deployment flow.
Create deployment signature.
CommunityTokens API for handling signer pubkey.
Issue #11954
- 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
interface for initializing db, which is implemented for appdatabase and
walletdatabase. TBD for multiaccounts DB.
Unified DB initializion for all tests using helpers and new interface.
Reduced sqlcipher kdf iterations for all tests to 1.
* 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
Patryk Osmaczko
Godfrain Jacques
Michal Iskierko
Mykhailo Prakhov
Igor Sirotin
Andrea Maria Piana
Ibrahem Khalil
Vitaly Vlasov
richΛrd
Sale Djenic
Mykhailo Prakhov
Vitaliy Vlasov
Anthony Laibe
Ivan Belyakov