feat: waku sync

[SionoiS]

First draft of what a Waku Sync specification would look like.

I'm not sure about the direction, do we want more details or maybe write more about what we want in the future?

I feel like it should be really short since it only wraps Negentropy.

WDYT?

[jm-clius]

I think this is a good start for a basic spec. I would indeed remain light on details. A separate spec should explain the integrated approach of a synchronised Store (Store-Sync) using resume and Waku-Sync with reference to this spec.
I would avoid tying any directives in this doc directly to any other Waku Protocol, although referencing Relay and Store as the most obvious environment in which Sync can be setup makes sense to me.

[jm-clius]

The reference to an hour is indeed an implementation detail. We want to write "friendly" specs, in that we shouldn't avoid specific examples that may help understanding. I just wouldn't phrase it as part of the protocol.
The requirements are:

• nodes that send and receive Waku messages (most likely via Waku Relay, but they could also be using Waku Filter)
• subset of these nodes that want to cache and synchronise the Waku messages (most likely because they run Waku Store service)

In other words, I wouldn't make the protocol dependent on Relay and Store, but would mention that this is the most obvious example use case. Then I'd say:

• Sync nodes maintain a representative set of message hashes corresponding to locally cached messages
• This representative set should cover the time period over which the nodes require to sync. 1 hour is a sensible default here.
• The sync protocol operates on message hashes and assume that after reconciliation of message hash sets, the full contents of messages can be retrieved in a secondary step (e.g. via Store protocol) and added to the local now-synced cache

In other words:

• describe the function not the protocol
• frame the most likely specific protocols performing functions above as examples
• where implementation is involved, name (but do not mandate) sensible defaults to be as useful as possible

[jm-clius]

Perhaps just note under Design Requirements that the size of the local set of message hashes should be managed to correspond to the time period over which you want to sync. No need for negentropy implementation specifics.

[SionoiS]

Some of this spec will have to change for 2.0 but lets merge.

[jm-clius]

Approving as a raw spec. I think this will change substantially with the intro of Sync 2.0.