* Replace mclock with time in peer pools
we used mclock as golang before 1.9 did not support monotonic clocks,
https://github.com/gavv/monotime, it does now https://golang.org/pkg/time/
so we can fallback on the system implementation, which will return
nanoseconds with a resolution that is system dependent.
* Handle case where peer have same discovered time
In some system the resolution of the clock is not high enough so
multiple peers are added on the same nanosecond.
This result in the peer just added being immediately removed.
This code adds a check making sure we don't assume that a peer is added.
Another approach would be to make sure to include the peer in the list,
so prevent the peer just being added to be evicted, but it's slightly
more complicated and the resolution is generally accurate enough for our
purpose so that peers will be fresh enough if they have the same
discovered time.
It also adds a regression test, I had to use an interface to stub the
clock.
Fixes: https://github.com/status-im/nim-status-client/issues/522
* bump version to 0.55.3
Geth decided to link to this place here https://github.com/ethereum/whisper, and it isn't a very welcoming README. Hopefully this points people in the right direction :)
## What has changed?
I've introduced to the public binding functionality that will compress and decompress public keys of a variety of encoding and key types. This functionality supports all major byte encoding formats and the following EC public key types:
- `secp256k1` pks
- `bls12-381 g1` pks
- `bls12-381 g2` pks
## Why make the change?
We want shorter public (chat) keys and we want to be future proof and encoding agnostic. See the issue here https://github.com/status-im/status-go/issues/1937
---
* Added basic signature for compresspk and uncompresspk
* Added basic encoding information
* make vendor
* formatted imports for the linter
* Reformatted imports hoping linter likes it
* This linter is capricious
* Added check that the secp256k1 key is valid
* Added test for valid key
* Added multiformat/go-varint dep
* Added public key type handling
* Added key decompression with key type handling
* Added handling for '0x' type indentifying
* Added more robust testing
* Less lint for the linting gods
* make vendor for bls12_381
* Added bls12-381 compression tests
* Added decompress key expected results
* Refactor of typed and untyped keys in tests
* Lint god appeasment
* Refactor of sample public keys
* Implemented bls12-381 decompression
* gofmt
* Renamed decode/encode funcs to be more descriptive
* Added binary bindings for key de/compression
* Refactor of func parameters
gomobile is a bit tempermental using raw bytes as a parameter, so I've decided to use string only inputs and outputs
* gofmt
* Added function documentation
* Moved multiformat de/compression into api/multiformat ns
* Moved multiformat de/compression into api/multiformat ns
* Changed compress to serialize on API
Why make this change?
Currently we only rate limit by number of messages.
This works well if we want to limit a large amount of small messages but
breaks down if sending a smaller amount of large messages.
This commit extends the current code to limit by size as well, setting
the default to 1MB per second, which should be enough.
What has changed?
- Rate limiter for waku only
The index for message was fairly inefficient as it was only using the
cursor, as it was referring to the old `chat_id` field.
This meant that newer messages would be fetched much faster then older
messages.
The index has been changed so that now it includes `local_chat_id`
(which is currently used for filtering), and not using `hide`.
The reason being is that `hide` is a low cardinality index, so there's
no performance benefit to have it in, also it's mostly ignored by the
query planner.
This commit also adds the missing migrations, we generated the file, but
the source was missing, probably I forgot to add them in a rebase. They
have been generated from the migration file, using `RestoreAsset`.
'm trying to add more documentation to parts of the repo that I go into.
I feel this basic history will make it easier to understand why the protocol package is as big as it is compared to the other packages in the repo, and help in understanding its existence.
Before we had two directories `lib/` and `mobile/` that generated
respectively the bindings for desktop and ios/android.
This needed to be kept in sync and there was a fair amount of code
duplication, plus some missing methods on one or the other side.
I have made a change so the whole `lib/` namespace is generated by
parsing the `AST` of `mobile`, and bindings are generated before
compiling.
Incentivisation was an experiment in running an incentivised fleet that
rewarded nodes based on their well behavior. It was heavily influenced
by https://docs.loki.network/ . It is currently not used anymore, so
removing.
We used *Raw method in message_processor as before we had non-Raw method
during the transition from status-react to status-go. This naming is not
meaningful anymore, so I have changed it.
Images are too large to be sent over waku/whisper with the
current PoW (0.002).
This commit lowers the PoW for sending messages to a lower value,
depending on the size.
This means that older clients will not be able to receive messages that
are greater than 50KB (none of the messages we currently send is anywhere close to
that, most of them are less than 1KB).
I would have preferred to set the PoW explicitly for images to be lower,
but it's not trivial as we use `datasync` to send messages and its
interface takes a payload that is to be dispatched and a function to
dispatch, at initialization stage.
This make it difficult (impossible?) to set a different PoW for a
particular message, without changing function signature in datasync
(which is agnostic to the transport used).
So a less cumbersome approach is to just fingerprint on size.
This commit adds support for images in protobuf messages.
The client can specify a path which will be used to load the image
and set the corresponding fields.
This makes the assumption that the RCP server runs on the same machine
as the client and they have access to the same files. This holds
currently for both status-react and status-console-client, we could
revisit and adds an upload if that changes in the future.
Andrea Maria Piana
Oskar Thorén
Roman Volosovskyi
Samuel Hawksby-Robinson
Jakub Sokołowski