In this PR https://github.com/status-im/status-go/pull/5557 when we were migrating
v1 accounts, because of incorrect condition some weird entries were added to keycard-related
tables which caused other wallet issues later and this commit cleans it.
This commit adds support for centralized metrics.
There are two providers as of now, and we haven't quite decided which
one to go for, so for the time being both are supported.
It also introduces a new endpoint InitializeApplication that replaces
OpenAccounts
* feat_: add ability to enable http and ws connections from the client app
* feat_: add websocket option for api config
* fix_: use new api options in statusd
* chore_: add test for `overrideApiConfig`
* chore_:Don't rely on the master key when generating accounts under the bip 0044 path m/44'/60'/0'/0/0
* fix_: lint issue
* fix_: failed test TestBackendStartNodeConcurrently
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.
Dario Gabriel Lipicar
richΛrd
frank
Sale Djenic
flexsurfer
Prem Chaitanya Prathi
Andrea Maria Piana
Mikhail Rogachev
kaichao
Igor Sirotin
Godfrain Jacques
Andrey Bocharnikov
Cuteivist
Alexander
Ivan Belyakov
Anthony Laibe
Mykhailo Prakhov
Pablo Lopez
Ibrahem Khalil