* chore(telemetry)_: add telemetry publish retry
* fix(telemetry)_: return error when server does not respond with 200
---------
Co-authored-by: Arseniy Klempner <arseniyk@status.im>
If there are multiple routes across multiple networks, but the user doesn't have a positive balance
on the network which the router initially suggested as the best (cheapest) route, then we are not returning
an error saying there are not enough balance, but instead try to suggest the route on the network where
the user has a positive balance even that's not the cheapest route (it should be the second cheapest route,
but if there are not enough balance on it we proceed with the third cheapest route and so on...).
A signal type `wallet` which had an event `type` set to `sing-transactions` is now a new signal
type `wallt.sing.transactions` with event which represents list of transactions that need to be signed.
* fix_: use cluster and shard to filter peers received via peerExchange
* chore_: enable pxClient in relay and increase relay peer connections (#5411)
* chore_: update go-waku with fixes
This commit removes the list of members from non token gated channels.
Unfortunately is a breaking change. I could make it non-breaking, but
we would lose any performance benefit.
For clients, the pseudo code for checking the member list of a channel
is:
```
members := channel.TokenGated ? channel.Members : community.Members
```
* 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`
- router logic splitted into two more logical functions
- locked amount validation improved
- hop and swap processors cached data kept per from/to chain and from/to token
- Clear function which clears the local cache is added
- process of evaluating `amountToSend` if more than a single network is locked is improved
- optimized params for require approval function
Fixes https://github.com/status-im/status-desktop/issues/15175
The problem was that we used StartMembersReevaluaitonLoop in createCommunityPermission, in case the loop was never started. Indeed it worked if it was the first ever permission, because the loop would then start and members would be re-evaluated.
However, if the loop was already started, in the case where there were previous permissions, the call would just early exit, because it was already started.
The solution here is to use `ScheduleMembersReevaluaiton` like other permission functions use. To make sure a first permission still works, we call startLoop in schedule if the task doesn't exist.
* feat(community)_: Move images from community data to MediaServer
* test_: fix lint issue
* test_: add more test statements
* feat_: deprecate old API
* test_: addressed review feedback from Icaro
* fix_: addressed review feedback from Jonathan
* chore_:wrap image url in an object
Samuel Hawksby-Robinson
Stefan
richΛrd
Vaclav Pavlin
Jakub Sokołowski
Andrey Bocharnikov
Dario Gabriel Lipicar
Sale Djenic
Prem Chaitanya Prathi
Arseniy Klempner
Igor Sirotin
Patryk Osmaczko
Andrea Maria Piana
kaichao
Mikhail Rogachev
Pablo Lopez
Jonathan Rainville
Mykhailo Prakhov
frank
Ivan Belyakov
Godfrain Jacques