docs: update lamport timestamps to uint64, pegged to current time (#196)

Lamport timestamps should remain close to current time (in milliseconds)
for new joiners to be able to have their messages ordered reasonably
close to other messages in the channel.

This means that:
- the `timestamp` field should be large enough to accommodate
millisecond resolution timestamps, i.e. `uint64` (see
https://github.com/vacp2p/rfc-index/pull/195 for reasoning)
- the lamport timestamp should be updated before sending _each_ message
to `max(timeNowInMs, current_lamport_timestamp + 1)`.

The current spec only indicated that Lamport timestamps should be
_initialised_ to current time, which means that the logical timestamp
would soon drift from current time.

vac/raw/sds.md

@@ -81,7 +81,7 @@ message Message {
   string sender_id = 1;           // Participant ID of the message sender
   string message_id = 2;          // Unique identifier of the message
   string channel_id = 3;          // Identifier of the channel to which the message belongs
-  optional int32 lamport_timestamp = 10;    // Logical timestamp for causal ordering in channel
+  optional uint64 lamport_timestamp = 10;    // Logical timestamp for causal ordering in channel
   repeated HistoryEntry causal_history = 11;  // List of preceding message IDs that this message causally depends on. Generally 2 or 3 message IDs are included.
   optional bytes bloom_filter = 12;         // Bloom filter representing received message IDs in channel
   optional bytes content = 20;             // Actual content of the message
@@ -112,6 +112,10 @@ Each participant MUST maintain:
 
 * A Lamport timestamp for each channel of communication,
 initialized to current epoch time in millisecond resolution.
+The Lamport timestamp is increased as described in the [protocol steps](#protocol-steps)
+to maintain a logical ordering of events while staying close to the current epoch time.
+This allows the messages from new joiners to be correctly ordered with other recent messages,
+without these new participants first having to synchronize past messages to discover the current Lamport timestamp.
 * A bloom filter for received message IDs per channel.
 The bloom filter SHOULD be rolled over and
 recomputed once it reaches a predefined capacity of message IDs.
@@ -144,8 +148,11 @@ the `lamport_timestamp`, `causal_history` and `bloom_filter` fields.
 
 Before broadcasting a message:
 
-* the participant MUST increase its local Lamport timestamp by `1` and
-include this in the `lamport_timestamp` field.
+* the participant MUST set its local Lamport timestamp
+to the maximum between the current value + `1`
+and the current epoch time in milliseconds.
+In other words the local Lamport timestamp is set to `max(timeNowInMs, current_lamport_timestamp + 1)`.
+* the participant MUST include the increased Lamport timestamp in the message's `lamport_timestamp` field.
 * the participant MUST determine the preceding few message IDs in the local history
 and include these in an ordered list in the `causal_history` field.
 The number of message IDs to include in the `causal_history` depends on the application.
@@ -250,7 +257,8 @@ participants SHOULD periodically send sync messages to maintain state.
 These sync messages:
 
 * MUST be sent with empty content
-* MUST include an incremented Lamport timestamp
+* MUST include a Lamport timestamp increased to `max(timeNowInMs, current_lamport_timestamp + 1)`,
+where `timeNowInMs` is the current epoch time in milliseconds.
 * MUST include causal history and bloom filter according to regular message rules
 * MUST NOT be added to the unacknowledged outgoing buffer
 * MUST NOT be included in causal histories of subsequent messages