logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-05 15:43:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

typos

Browse Source
This commit is contained in:
SionoiS 2024-09-06 11:18:14 -04:00
parent 3721b54cc1
commit 048ee89d29
No known key found for this signature in database
GPG Key ID: C9458A8CB1852951
1 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
standards/core/sync.md
View File

@ -7,18 +7,18 @@ contributors:
- Hanno Cornelius <hanno@status.im> - Hanno Cornelius <hanno@status.im>
--- ---
# Abstract ## Abstract
This specification explains the `WAKU-SYNC` protocol This specification explains the `WAKU-SYNC` protocol
which enables the reconciliation of two sets of message hashes which enables the reconciliation of two sets of message hashes
in the context of keeping multiple Store nodes syncronized. in the context of keeping multiple Store nodes synchronized.
Waku Sync is a wrapper around Waku Sync is a wrapper around
[Negentropy](https://github.com/hoytech/negentropy) a [range-based set reconciliation protocol](https://logperiodic.com/rbsr.html). [Negentropy](https://github.com/hoytech/negentropy) a [range-based set reconciliation protocol](https://logperiodic.com/rbsr.html).
# Specification ## Specification
**Protocol identifier**: `/vac/waku/sync/1.0.0` **Protocol identifier**: `/vac/waku/sync/1.0.0`
## Terminology ### Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt). “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt).
@ -28,15 +28,15 @@ the messages created by the Negentropy protocol.
Client always refers to the initiator Client always refers to the initiator
and the server the receiver of the first payload. and the server the receiver of the first payload.
## Design Requirements ### Design Requirements
Nodes enabling Waku Sync SHOULD Nodes enabling Waku Sync SHOULD
manage and keep message hashes in a local cache manage and keep message hashes in a local cache
for the range of time for the range of time
during which syncronization is required. during which synchronization is required.
Nodes SHOULD use the same time range, Nodes SHOULD use the same time range,
for Waku we chose one hour as the global default. for Waku we chose one hour as the global default.
Waku Relay or Light Push protocol MAY be enabled Waku Relay or Light Push protocol MAY be enabled
and used in conjuction with Sync and used in conjunction with Sync
as a source of new message hashes as a source of new message hashes
for the cache. for the cache.
@ -44,7 +44,7 @@ Nodes MAY use the Store protocol
to request missing messages once reconciliation is complete to request missing messages once reconciliation is complete
or to provide messages to requesting clients. or to provide messages to requesting clients.
## Payload ### Payload
```protobuf ```protobuf
syntax = "proto3"; syntax = "proto3";
@ -58,7 +58,7 @@ message SyncPayload {
} }
``` ```
## Session Flow ### Session Flow
A client initiate a session with a server A client initiate a session with a server
by sending a `SyncPayload` with by sending a `SyncPayload` with
only the `negentropy` field set to it. only the `negentropy` field set to it.
@ -80,30 +80,30 @@ This client computation also outputs any hash differences found,
those MUST be stored. those MUST be stored.
In the case of an empty payload, In the case of an empty payload,
the client MUST send back a `SyncPayload` the client MUST send back a `SyncPayload`
with all the hashes previoudly found in the `hashes` field and with all the hashes previously found in the `hashes` field and
an empty `nengentropy` field. an empty `nengentropy` field.
# Attack Vectors ## Attack Vectors
Nodes using `WAKU-SYNC` are fully trusted. Nodes using `WAKU-SYNC` are fully trusted.
Message hashes are assumed to be of valid messages received via Waku Relay or Light push. Message hashes are assumed to be of valid messages received via Waku Relay or Light push.
Further refinements to the protocol are planned Further refinements to the protocol are planned
to reduce the trust level required to operate. to reduce the trust level required to operate.
Notably by verifing messages RLN proof at reception. Notably by verifying messages RLN proof at reception.
# Implementation ## Implementation
The following is not part of the specifications but good to know implementation details. The following is not part of the specifications but good to know implementation details.
### Interval ### Interval
Ad-hoc syncing can be useful in some cases but continueous periodic sync Ad-hoc syncing can be useful in some cases but continuous periodic sync
minimise the differences in messages stored across the network. minimize the differences in messages stored across the network.
Syncing early and often is the best strategy. Syncing early and often is the best strategy.
The default used in nwaku is 5 minutes interval between sync with a range of 1 hour. The default used in nwaku is 5 minutes interval between sync with a range of 1 hour.
### Range ### Range
We also offset the sync range by 20 seconds in the past. We also offset the sync range by 20 seconds in the past.
The actual start of the sync range is T-01:00:20 and the end T-00:00:20 The actual start of the sync range is T-01:00:20 and the end T-00:00:20
This is to handle the inherent jitter of GossipSub. This is to handle the inherent jitters of GossipSub.
In other words, it is the amount of time needed to confirm if a message is missing or not. In other words, it is the amount of time needed to confirm if a message is missing or not.
### Storage ### Storage
@ -115,11 +115,11 @@ It is expected to be a less likely case than time based insertion and removal.
Last but not least it must be optimized for sequential read Last but not least it must be optimized for sequential read
as it is the most often used operation. as it is the most often used operation.
# Copyright ## Copyright
Copyright and related rights waived via Copyright and related rights waived via
[CC0](https://creativecommons.org/publicdomain/zero/1.0/). [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
# References ## References
- https://logperiodic.com/rbsr.html - https://logperiodic.com/rbsr.html
- https://github.com/hoytech/negentropy - https://github.com/hoytech/negentropy