1 files changed, 32 insertions, 0 deletions
diff --git a/doc/proposals/2022-07-replace-shard-hint-with-untrusted-timestamp.md b/doc/proposals/2022-07-replace-shard-hint-with-untrusted-timestamp.md
new file mode 100644
index 0000000..aa66d5e
--- /dev/null
+++ b/doc/proposals/2022-07-replace-shard-hint-with-untrusted-timestamp.md
@@ -0,0 +1,32 @@
+# Proposal
+
+Replace "shard_hint" with "untrusted_timestamp".
+
+A log requires untrusted_timestamp to contain an integer, seconds
+since epoch, in the span [now()-24h, now()] ie which is not in the
+future and not older than 24h.
+
+# Background
+
+add-leaf's "shard_hint" argument protects against entries being
+"replayed" between logs, notably including between two shards of a
+given log, eg MyLog2022 and MyLog2023.
+
+# Motivation
+
+- The current design with shard hint makes it possible for anyone to
+  replay entries in log A to log B at any time after they've been
+  submitted to log A (assuming the two logs are configured with
+  overlapping shard hint intervals).
+
+- Bonus: Getting rid of the name "hint" which is not very intuitive.
+
+# Rationale
+
+- One problem with replayed entries is that anyone can consume a
+  submitter's rate limit in another log long after it was actually
+  submitted.
+
+- Another problem with replayed entries which we do not address here
+  is filling up a log operators disk. This is mitigated with stricter
+  rate limiting, see "rate_limit".