The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in[RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
Store Sync nodes MAY use Store Resume to fill the gap in messages for any short-term offline period.
Such a node SHOULD keep track of its last online timestamp.
It MAY do so by periodically storing the current timestamp on disk while online.
After a detected offline period has been resolved,
or at startup,
a Store Sync node using Store Resume SHOULD select another [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store) node using any available discovery mechanism.
We RECOMMEND that this to be a random node.
Next, the Store Sync node SHOULD perform a [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store#content-filtered-queries) query
to the selected node for the time interval since it was last online.
Even while online, Store Sync nodes may occasionally miss messages.
To remedy any such losses and to achieve eventual consistency,
Store Sync nodes MUST mount [WAKU2-SYNC](./sync.md) protocol
to detect and exchange differences with other Store Sync nodes.
As described in that specification,
[WAKU2-SYNC](./sync.md) consists of two sub-protocols.
Both sub-protocols MUST be used by Store Sync nodes in the following way:
1.`reconciliation` MUST be used to detect and exchange differences between [14/WAKU2-MESSAGE](https://rfc.vac.dev/waku/standards/core/14/message)s cached by the [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store) node
2.`transfer` MUST be used to transfer the actual content of such differences.
Messages received via `transfer` MUST be cached in the same archive backend
where the [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store) node caches messages received via normal routing.
#### Periodic syncing
Store Sync nodes SHOULD periodically trigger [WAKU2-SYNC](./sync.md).
We RECOMMEND syncing at least once every `5` minutes with `1` other Store Sync peer.
The node MAY choose to sync more often with more peers
to achieve faster consistency.
Any peer selected for Store Sync SHOULD be chosen at random.
Discovery of other Store Sync peers falls outside the scope of this document.
For simplicity, a Store Sync node MAY assume that any other [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store) peer
supports Store Sync and attempt to trigger a sync operation with that node.
If the sync operation then fails (due to unsupported protocol),
it could continue attempting to sync with other [13/WAKU2-STORE](https://rfc.vac.dev/waku/standards/core/13/store) peers on a trial-and-error basis
until it finds a suitable Store Sync peer.
#### Sync window
For every [WAKU2-SYNC](./sync.md) operation,
the Store Sync node SHOULD choose a reasonable window of time into the past
over which to sync cached messages.
We RECOMMEND a sync window of `1` hour into the past.
This means that the syncing peers will compare
and exchange differences in cached messages up to 1 hour into the past.
A Store Sync node MAY choose to sync over a shorter time window to save resources and sync faster.
A Store Sync node MAY choose to sync over a longer time window to remedy losses over a longer period.
