Peer handshake is for full replicas that both possess the full op log of the database.
It is essentially a server to server handshake, albeit nothing prevents a client from having a full replica too.
Peer .on ops are scoped to their respective sending peers.
Peer .on may not obey the request-response pattern; peers may send their handshakes independently.
On receiving a peer on, replica sends back the section of the local log that the other peer missed and, once the catch-up phase is over, keeps relaying new ops as they arrive. A peer replica may choose to suppress echoed ops (i.e. don't send ops back to the same peer it received them from).
A replica must maintain exactly the same op order when relaying ops live and when replaying them in a catch-up. The local arrival order is linear and persistent.
The simplest example of a peer handshake is peers X and Y connecting for the first time to sync database db:
> /Swarm#db!0.on+X
< /Swarm#db!0.on+Y
< ... op log
> ... op log
In a repeated handshake, peers mention the timestamp of the last op received from each other in the past:
> /Swarm#database!1CRE6l29+A34h~s1.on+X
< /Swarm#database!1CRE6K+Agritzk004.on+Y
Although the op has the type-id of the metadata object (/Swarm#database), the stamp (!1CRE6l29+A34h~s1) may come from any op.
Note that the last stamp is not necessarily the max stamp.
A peer handshake can be used by non-replica subscribers, i.e. various log consumers.
Such subscribers may not have a replica id.
Thus, their .on is scoped to ~.
Similarly, the response .on is read-only (the stamp is !~, the "never" value).
> /Swarm#database!1CRE6l29+Or5az.on+~
< /Swarm#database!~.on+Y