When sending messages in quick succession, it might be that multiple
messages are batched together in datasync, resulting in a single large
payload.
This commit changes the behavior so that we can pass a max-message-size
and we split the message in batches before sending.
A more elegant way would be to split at the transport layer (i.e
waku/whisper), but that would be incompatible with older client.
We can still do that eventually to support larger messages.
Marketing was relying on mailserver entries for checking the time a
give peer spent on the app.
This was not accurate as the assumption was that a peer would "ping" a
mailserver every 15s, which is not the case, it only hit the mailserver
as it comes from an "offline" state.
This commit changes the log level of two entries so that we have
connect/disconnect time for a given peer, which should be enough to
calculate roughly the time a peer has been online if connected to our
fleet.
On logout happens sometimes that `PeersCount` is called when the server
has been removed.
This commit adds a guard to make sure that the server is not nil when
calling `PeersCount`.
If one request failed, the whole batch would fail.
This caused issue as one of the contract is constantly returning an
error now, and essentially there was not way to fetch balance.
Also extend the timeout to 20s as we throw 165 request to Infura in one
go and it takes its time to reply to those, although it seems like we
should batch them on our side instead of sending them all cuncurrently.
This commit does two things:
1) Add an index on seen & update only the not-seen messages in the query
2) Hide long messages in the database, as that's likely spam
For some reason when calling saveChat from desktop with `lastMessage`
set to null, a sigsev is received.
The issue seems to be in logFormat
05280a7ae3/log/format.go (L356)
which for some reason blows up if passed a nil pointer (`lastMessage`).
Can't replicate on any other platform or running it locally, but hey,
this fixes the issue.
previously FullNode would only result in setting a bloom filter to full.
This behavior caused issues as you effectively cannot install a filter
on a FullNode, as it would advertise the new topic/bloom filter and stop
receiving all the messages.
This caused an issue when running push notifications servers together
with mailservers, also the behavior is a bit counter-intuitive as I
would expect the FullNode config to be honored no matter of what filters
are installed.
StartWallet was called before service initialization.
After the recent changes this call was moved after initialization, but
the geth system automatically start services.
This meant that `IsStarted()` returned true, although the reactor was
not started, and only after calling `StopWallet()` and `StartWallet()`
again the system would reach the right state.
This commit changes the behavior so that we only check whether the
reactor has been started when calling `IsStarted()` and we allow
multiple calls to `Start()` on the signal service, which won't return an
error (it's a noop if callled multiple times).
LastMessage in chat was encoded in bytes so that we don't have to
encoded/decode everytime we save to db or pass the client.
An issue with emoji surfaced a problem with this approach.
Chat.LastClockValue represent the last clock value of any type of
message exchanged in a chat (emoji,group membership updates, contact
updates).
So when receving a new message, we should update LastMessage if the
clock of the LastMessage is lower than the received message, and we
should not only check LastClockValue, otherwise the message might be
discarded although it is the most recent.
This commit fixes the issue by keeping LastMessage as an object and
comparing LastMessage.Clock instead of LastClockValue
If a message was inserted before the migration the field
audio_duration_ms would be set to NULL, and would not be serialized into
go correctly, as uint is non-nullable.
this commit fixes the issue by calling COALESCE on the value.
* 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
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`.
Why make the changes?
Mainly performance, those fields are almost always present in the
database but they are re-calculated on load by the client as it does not
have necessarily access to it.
What has changed?
- Remove `_legacy` persistence namespaces as it's a vestige of the
initial move frmo status-react to status-go
- Pulling chats is now a join with contacts to add contact & alias
During the move to waku/1 we removed handing of a deprecated format.
aa7f591587 (diff-ea5e44cf3db4a12b3a2a246c7fa39602R290)
Turns out that no client is using the new format and the only live
client is using the deprecated format.
This commit re-introduces the functionality.
* Refactor tidy of waku package
* Added deprecation warning on whisper README.md
* Appeasing the lint gods and testing is good
* Place Whisper deprecation warning in the correct package README
:facepalm
* Implementing changes after team feedback
* More offerings to the lint gods
* Remove apparently redundant context params
* Correctly handle concurrent HandlePeer err
* Revert "Remove apparently redundant context params"
This reverts commit 557dbd0d64.
* Added note to waku/api.go about context
* renamed statusoptions and removed unused global
* Removed OnNewP2PEnvelopes() from WakuHost interface
* Matched v1 Peer with new interface sig
Also changed common/helper.go to common/helpers.go
* Formatting of waku tests and some additional error handling
* Changed version to 0.53.0
* Removed redundant type declaration
* Moved TopicToBloom function into a Topic{} method
* Moved GenerateSecureRandomData() into helpers.go
Why make the change?
As discussed previously, the way we will move across versions is to maintain completely separate
codebases and eventually remove those that are not supported anymore.
This has the drawback of some code duplication, but the advantage is that is more
explicit what each version requires, and changes in one version will not
impact the other, so we won't pile up backward compatible code.
This is the same strategy used by `whisper` in go ethereum and is influenced by
https://www.youtube.com/watch?v=oyLBGkS5ICk .
All the code that is used for the networking protocol is now under `v0/`.
Some of the common parts might still be refactored out.
The main namespace `waku` deals with `host`->`waku` interactions (through RPC),
while `v0` deals with `waku`->`remote-waku` interactions.
In order to support `v1`, the namespace `v0` will be copied over, and changed to
support `v1`. Once `v0` will be not used anymore, the whole namespace will be removed.
This PR does not actually implement `v1`, I'd rather get things looked over to
make sure the structure is what we would like before implementing the changes.
What has changed?
- Moved all code for the common parts under `waku/common/` namespace
- Moved code used for bloomfilters in `waku/common/bloomfilter.go`
- Removed all version specific code from `waku/common/const` (`ProtocolVersion`, status-codes etc)
- Added interfaces for `WakuHost` and `Peer` under `waku/common/protocol.go`
Things still to do
Some tests in `waku/` are still testing by stubbing components of a particular version (`v0`).
I started moving those tests to instead of stubbing using the actual component, which increases
the testing surface. Some other tests that can't be easily ported should be likely moved under
`v0` instead. Ideally no version specif code should be exported from a version namespace (for
example the various codes, as those might change across versions). But this will be a work-in-progress.
Some code that will be common in `v0`/`v1` could still be extract to avoid duplication, and duplicated only
when implementations diverge across versions.
If the user deletes/leaves a group chat, the chat is set as not active.
This means that if we are re-invited to the chat it won't be shown to
the user.
This commit changes this behavior so that if we are re-invited to the
chat it is set as active again.
When receiving a message with save a contact in the database in order to
avoid re-calculating image/profile.
This contact is then passed to the client, which can negatively impact
performance.
This commit changes the behavior so that only those contacts that have
some custom fields (have been explicitly added by the user, have been
blocked by the user, have sent a contact request or have a verified ens
name) are passed to the client.
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
- unused API methods are removed
- some unusued code is removed too
- API docs are updated
That's just a portion of clean up that should be done,
but the rest of it will probably happen in different PR
with changes to the way how we watch to chain updates.
Currently ENS are verified explicitly by status-react, this is not ideal
as if that fails it will have to be explicilty retried in status-react.
This commits changes that behavior so that ENS are verified in a loop
and updated if new messages are received.
Storing absolute path for different configs breaks compatibility on iOS
as app's dir is changed after upgrade. The solution is to store relative
paths and to concatenate it with `backend.rootDataDir`. The only
exception is `LogFile` as it is stored outside `backend.rootDataDir` on
Android. `LogDir` config was added to allow adding of custom dir for log
file.
Configs concerned:
`DataDir`
`LogDir`
`LogFile`
`KeystoreDir`
`BackupDisabledDataDir`
- In order to avoid handling of the reorganized blocks we use an offset
from the latest known block when start listening to new blocks. Before
this commit the offset was 15 blocks for all networks. This offset is
too big for mainnet and causes noticeable delay of marking a transfer as
confirmed in Status (comparing to etherscan). So it was changed to be 5
blocks on mainnet and is still 15 blocks on other networks.
- Also before this commit all new blocks were handled one by one with
network specific interval (10s for mainnet), which means that in case of
lost internet connection or application suspension (happens on iOS)
receiving of new blocks would be paused and then resumed with the same
"speed" - 1 blocks per 10s. In case if that pause is big enough the
application would never catch up with the latest block in the network,
and this also causes the state of transfers to be delayed in the
application. In this commit in case if there was more than 40s delay
after receiving of the previous block the whole history in range between
the previous received block and ("latest"-reorgeSafetyDepth) block is
checked at once and app catches up with a recent state of the chain.
flexsurfer
Roman Volosovskyi
andrey
Andrea Maria Piana
Volodymyr Kozieiev
Gheorghe Pinzaru
Samuel Hawksby-Robinson
Adam Babik
Adam Babik
Jakub Sokołowski