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.
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`.
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.
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.
The new API returns all known recipients of a wallet, by
sourcing transfers, pending_transactions and multi_transactions tables
The API is synchronous. Future work will be to make it async.
In some corner cases, when watching a famous wallet, it can
be that there are too many recipients to be returned in one go. Offset
and limit can be used to paginate through the results.
Updates status-desktop #10025
Change smart contract with new API.
Update gas amount for deployment.
Add Burn() and EstimateBurn() functions.
Add RemainingSupply() functions.
Issue #10816
It happens that an envelope is sent before it's tracked, resulting in
long delays before the envelope is marked as sent.
This commit changes the behavior of the code so that order is now
irrelevant.
fetch strategy:
Before:
- block fetching commands for different accounts were in the same wait
group, making them dependent on each iteration.
- transfers loading command was checking database for new unloaded
blocks on timeout and was in the same wait group with block fetching, so
it was often blocked until all block fetching commands finish for
iteration.
Now:
- block fetching commands run independently for each account
- transfers fetching command is run once on startup for unloaded blocks
from DB
- fetch history blocks commands are launched once on startup for
accounts with no full history loaded
- transfers are loaded on each iteration of block range check
without waiting for all ranges to be checked
Improve the error management in order to avoid DB corruption in case the process is killed while encrypting the DB.
Changes:
Use sqlcipher_export instead of rekey to change the DB password. The advantage is that sqlcipher_export will operate on a new DB file and we don't need to modify the current account unless the export is successful.
Keeping the rekey requires to create a DB copy before trying to re-encrypt the DB, but the DB copy is risky in case the DB file changes wile the copy is in progress. It could also lead to DB corruption.
* perf(sqlCipher): Increase cipher page size to 8192
Increasing the cipher page size to 8192 requires DB re-encryption. The process is as follows:
//Login to v3 DB
PRAGMA key = 'key';
PRAGMA cipher_page_size = 1024"; // old Page size
PRAGMA cipher_hmac_algorithm = HMAC_SHA1";
PRAGMA cipher_kdf_algorithm = PBKDF2_HMAC_SHA1";
PRAGMA kdf_iter = kdfIterationsNumber";
//Create V4 DB with increased page size
ATTACH DATABASE 'newdb.db' AS newdb KEY 'key';
PRAGMA newdb.cipher_page_size = 8192; // new Page size
PRAGMA newdb.cipher_hmac_algorithm = HMAC_SHA1"; // same as in v3
PRAGMA newdb.cipher_kdf_algorithm = PBKDF2_HMAC_SHA1"; // same as in v3
PRAGMA newdb.kdf_iter = kdfIterationsNumber"; // same as in v3
SELECT sqlcipher_export('newdb');
DETACH DATABASE newdb;
//Login to V4 DB
...
Worth noting:
The DB migration will happen on the first successful login.
The new DB version will have a different name to be able to distinguish between different DB versions.Versions naming mirrors sqlcipher major version (naming conventions used by sqlcipher), meaning that we're migrating from V3 to V4 DB (even if we're not fully aligned with V4 standards). The DB is not migrated to the v4 standard `SHA512` due to performance reasons. Our custom `SHA1` implementation is fully optimised for perfomance.
* perf(sqlCipher): Fixing failing tests
Update the new DB file format in Delete account, Change password and Decrypt database flows
* perf(SQLCipher): Increase page size - send events to notify when the DB re-encryption starts/ends
When we reply to our own message with an image, we didn't set the URL of
the image of the message, which resulted in the image not being
displayed correctly.
Refactor the filter interface to be an async call which returns
the result using a wallet event
A call to the filter API will cancel the ongoing filter and receive
an error result event
Closes status-desktop #10994
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
There's two scenarios in which we're leaving a community:
We either get kicked or we leave ourselves.
In case of leaving ourselves it's fine to unsubscribe from further
community updates be cause we deliberately chose to leave.
In case of being kicked however, this is different.
Say I'm kicked from a community because its token permissions have
changed, in this case we don't want clients to manually re-subscribe to
the community to get informed when there were further changes.
status-go should rather not unsubscribe if we know for sure we've been
kicked by someone else.
Main changes:
- extend DB query include status for transactions and pending_transactions
- extend DB query to aggregate data from complex activity entries
- extend tests to include the new status values
Other changes:
- Improve tests with mocked addresses in DB to have a true to/from state
Update status-desktop #10746
fix flaky test: TestRetrieveBlockedContact
resolve conflict when rebase origin/develop
Feat/sync activity center notification (#3581)
* feat: sync activity center notification
* add test
* fix lint issue
* fix failed test
* addressed feedback from sale
* fix failed test
* addressed feedback from ilmotta
go generate ./protocol/migrations/sqlite/...
feat: add updated_at for syncing activity center notification
* feat: add mutual state update system message
* feat: send mutual state update on accepting CR
* feat: send mutual state update when removing a contact
* fix: don't send MutualStateUpdateMessage over wire
* fix: mutual state update message text fixed
* fix: new clock to ensure system message after CR and add chat to the response
* feat: add AC notification for contact removal
* feat: replace "sent" mutual state system message with "added"
Extended the migration process with a generic way of applying custom
migration code on top of the SQL files. The implementation provides
a safer way to run GO code along with the SQL migrations and possibility
of rolling back the changes in case of failure to keep the database
consistent.
This custom GO migration is needed to extract the status from
the JSON blob receipt and store it in transfers table.
Other changes:
- Add NULL DB value tracking to JSONBlob helper
- Index status column on transfers table
- Remove unnecessary panic calls
- Move log_parser to wallet's common package and use to extract token
identity from the logs
Notes:
- there is already an index on transfers table, sqlite creates one for
each unique constraint therefore add only status to a new index
- the planned refactoring and improvements to the database have been
postponed due to time constraints. Got the time to migrate the data
though, extracting it can be done later for a more efficient
implementation
Update status-desktop #10746
Pascal Precht
Alexander
frank
Boris Melnik
Jonathan Rainville
Dario Gabriel Lipicar
Emil Sawicki
Anthony Laibe
Mikhail Rogachev
Stefan
Igor Sirotin
Vitaliy Vlasov
Michal Iskierko
Andrea Maria Piana
Mykhailo Prakhov
Ivan Belyakov
Alex Jbanca
mprakhov
Patryk Osmaczko
Ibrahem Khalil
Richard Ramos
Sale Djenic