persisted pads from meeting minutes

1 files changed, 59 insertions, 0 deletions

diff --git a/archive/2021-08-24-checkpoint-otherdata b/archive/2021-08-24-checkpoint-otherdata
new file mode 100644
index 0000000..94caca0
--- /dev/null
+++ b/archive/2021-08-24-checkpoint-otherdata
@@ -0,0 +1,59 @@
+Background
+	* The current checkpoint format leaves the [otherdata] section undefined
+	* (The format of [otherdata] is inferred from a log's unique identifier)
+
+Impact on believers
+	* None, makes sense that each ecosystem knows their own format
+
+Impact on witnesses
+	* If witnesses disregard [otherdata] while cosigning: none
+	* Otherwise: may complicate witness configuration and support for [otherdata]
+
+The problem in more detail
+	* (Let's not focus on if these extensions are good ideas or not.  It's an example.)
+	* Suppose ecosystem A uses a checkpoint extension that adds a timestamp
+		* First line of otherdata: <timestamp> <diff>
+		* "A witness must only sign a checkpoint if its timestamp is in [now-diff, now]"
+	* Now ecosystem B comes along
+		* "We want timestamp verification too as in ecosystem A"
+		* "Some witnesses support that, just pass 'ecosystem A' as log metadata"
+		* (A little hacky but works)
+	* Now ecosystem C comes along
+		* "We want a timestamp as in ecosystem A and B"
+		* "We also want a secondary root hash because we operate a log-backed map"
+		* Unless witnesses change they will not understand 'ecosystem C' as log metadata
+		* This is unfortunate if witnesses actually do understand the timestamp part :<
+
+Prediction
+	* If [otherdata] catches on, each log ecosystem will do their own thing
+	* This may lead to compatibility issues like the one described above
+
+Mitigation
+	* A well-defined [otherdata] format that is generally useful would go a long way
+
+Example: an unordered key-value format
+	* Identifier: 'checkpoint key-value format'
+		* Might be communicated on the first line in [otherdata]
+			* Would affect the current checkpoint format
+		* Might be communicated as external checkpoint metadata
+			* Would not affect the current checkpoint format
+			* Would probably be good with a 'recommended usage' section though
+				* "If you want witnesses to look into [otherdata], think about X else Y"
+	* Grammar
+		* Each line is composed of <key>=<value>
+			* A line is an extension that is named <key>
+			* A key must not contain '='
+			* A line must adhere to the usual checkpoint v0 restrictions, e.g., no '\n'
+
+What we gained from this example:
+	* Witnesses that peek into [otherdata] would probably have used a common format
+	* Ecosystem A would probably have used that format to define a timestamp extension
+		* verified-timestamp=<timestamp> <diff>
+	* Ecosystem C could come along and set their [otherdata] to:
+		* map-hash=<root hash>
+		* verified-timestamp=<timestamp> <diff>
+	* Now a witness that speaks 'checkpoint key-value format' and which enforces the 'verified-timestamp' extension can do that regardless of if they know 'map-hash'
+
+Conclusion
+	* Allowing witnesses to peek into [otherdata] can get messy.
+	* We can probably avoid this mess by having a recommended or forced [otherdata] usage