3.0 KiB
| title | name | editor | contributors | ||
|---|---|---|---|---|---|
| WAKU-SYNC | Waku Sync | Simon-Pierre Vivier <simvivier@status.im> |
|
Abstract
This specification explains the WAKU-SYNC protocol
which enables the reconciliation of two sets of message hashes
in the context of keeping multiple nodes syncronized.
Waku Sync is a wrapper around
Negentropy a range-based set reconciliation protocol.
Specification
Protocol identifier: /vac/waku/sync/1.0.0
Terminology
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.
The term Negentropy refers to the protocol of the same name. Negentropy payload refers to the messages created by the Negentropy protocol. Client always refers to the initiator and the server the receiver of the first payload.
Design Requirements
Nodes enabling Waku Sync SHOULD manage and keep message hashes for the range of time during which syncronization is required. Nodes SHOULD use the same time range, for Waku we chose one hour as the global default. Waku Relay or Filter protocol MAY be enabled and used in conjuction with Sync as a source of new message hashes for the time range.
Nodes MAY use the Store protocol to request missing messages or to provide messages to requesting clients.
Payload
syntax = "proto3";
package waku.sync.v1;
message SyncPayload {
optional bytes negentropy = 1;
repeated bytes hashes = 20;
}
Session Flow
A client initiate a session with a server
by sending a SyncPayload with
only the negentropy field set to it.
This field MUST contain
the first negentropy payload
created by the client
for this session.
The server receives a SyncPayload.
A new negentropy payload is computed from the received one.
The server sends back a SyncPayload to the client.
The client receives a SyncPayload.
A new negentropy payload OR an empty one is computed.
If a new payload is computed then
the exchanges between client and server continues until
the client computes an empty payload.
This client computation also outputs any hash differences found,
those MUST be stored.
In the case of an empty payload,
the client MUST send back a SyncPayload
with all the hashes previoudly found in the hashes field and
an empty nengentropy field.
Attack Vectors
Nodes using WAKU-SYNC are fully trusted.
Message hashes are assumed to be of valid messages received via Waku Relay or Filter.
Further refinements to the protocol are planned to reduce the trust level required to operate. Notably by verifing messages RLN proof at reception.
Copyright
Copyright and related rights waived via CC0.