Dilation

dilation-protocol.md

@@ -47,28 +47,30 @@ Currently there is only one version: `"1"`.
 ## Leaders and Followers
 
 Each side of a Wormhole has a randomly-generated dilation `side` string (this
-is included in the `please-dilate` message, and is independent of the
+is included in the `please` message, and is independent of the
 Wormhole's mailbox "side"). When the wormhole is dilated, the side with the
 lexicographically-higher "side" value is named the "Leader", and the other
 side is named the "Follower". The general wormhole protocol treats both sides
 identically, but the distinction matters for the dilation protocol.
 
-Both sides send a `please-dilate` as soon as dilation is triggered. Each side
+Both sides send a `please` as soon as dilation is triggered. Each side
 discovers whether it is the Leader or the Follower when the peer's
-"please-dilate" arrives. The Leader has exclusive control over whether a
+"please" message arrives. The Leader has exclusive control over whether a
 given connection is considered established or not: if there are multiple
 potential connections to use, the Leader decides which one to use, and the
 Leader gets to decide when the connection is no longer viable (and triggers
 the establishment of a new one).
 
-The `please-dilate` includes a `use-version` key, computed as the "best"
-version of the intersection of the two sides' abilities as reported in the
-`versions` message. Both sides will use whichever `use-version` was specified
-by the Leader (they learn which side is the Leader at the same moment they
-learn the peer's `use-version` value). If the Follower cannot handle the
-`use-version` value, dilation fails (this shouldn't happen, as the Leader
-knew what the Follower was and was not capable of before sending that
-message).
+The version message payload has a key called `can-dilate` that has a
+list of versions supported by a particular version of the client (eg:
+["1", "2"]). After receiving the version message from the other
+client, each client computes a list of mutually compatible "shared"
+versions that are commonly supported by both the clients. At the
+moment, the version number is "1", so if both the clients support that
+version, we pick the dilation version as "1". If the clients cannot
+find a mutually compatible version, then dilation would fail.
+
+
 
 ## Connection Layers
 
@@ -225,7 +227,7 @@ derived key)
 
 Each side is in the "connecting" state (which encompasses both making
 connection attempts and having an established connection) starting with the
-receipt of a `please-dilate` message and a local `w.dilate()` call. The
+receipt of a `please` message and a local `w.dilate()` call. The
 Leader remains in that state until it abandons the connection and sends a
 `reconnect` message, at which point it remains in the "flushing" state until
 the Follower's `reconnecting` message is received. The Follower remains in
@@ -484,7 +486,7 @@ that object.
 Each time an L3 connection is established, the side will immediately send all
 L4 messages waiting in the outbound queue. A future protocol might reduce
 this duplication by including the highest received sequence number in the L1
-PLEASE-DILATE message, which would effectively retire queued messages before
+PLEASE message, which would effectively retire queued messages before
 initiating the L2 connection process. On any given L3 connection, all
 messages are sent in-order. The receipt of an ACK for seqnum `N` allows all
 messages with `seqnum <= N` to be retired.