aboutsummaryrefslogtreecommitdiff
path: root/doc/proposals
diff options
context:
space:
mode:
Diffstat (limited to 'doc/proposals')
-rw-r--r--doc/proposals/2022-01-how-to-use-proposal-folder31
-rw-r--r--doc/proposals/2022-01-no-quick-tree-head-endpoint32
2 files changed, 63 insertions, 0 deletions
diff --git a/doc/proposals/2022-01-how-to-use-proposal-folder b/doc/proposals/2022-01-how-to-use-proposal-folder
new file mode 100644
index 0000000..941a504
--- /dev/null
+++ b/doc/proposals/2022-01-how-to-use-proposal-folder
@@ -0,0 +1,31 @@
+Proposal: how to use the doc/proposals folder
+
+Background
+---
+It is a bit inconsistent to have some proposals in archive and others in
+doc/proposals. This happened because:
+ 1. Our process is to persist pads in the archive. Some proposals were pads.
+ 2. The proposals in doc/proposals were a bit more structured. It added
+ overhead that we felt was not necessary to have yet.
+
+Proposal
+---
+ 1. Move proposals that were persisted in the archive to doc/proposals as is.
+ To keep it simple, only move proposals that have "proposal" as part of their
+ persisted name.
+ 2. Update affected links so that they are not broken, should not be many.
+ 3. In the future we put all types of proposals in doc/proposal, regardless
+ of if they are related to the Sigsum protocol or something else (like this
+ document). Notably this includes pads that are to be persisted by the chair
+ after our weekly meets.
+ 4. The main criteria is that a document in doc/proposals proposes something.
+ There is no particular format for a proposal's content, other than being
+ plaintext viewable.
+ 5. To keep the listing clean we continue to prefix proposals with
+ YYYY-MM-<name>. The date refers to when the document was initially added.
+
+Notes
+---
+A notable pro with this is that it is easy to update a proposal if we realize
+that something is missing after persisting it. Our archive is not meant to have
+updates.
diff --git a/doc/proposals/2022-01-no-quick-tree-head-endpoint b/doc/proposals/2022-01-no-quick-tree-head-endpoint
new file mode 100644
index 0000000..3a31a04
--- /dev/null
+++ b/doc/proposals/2022-01-no-quick-tree-head-endpoint
@@ -0,0 +1,32 @@
+Proposal: no quick tree-head endpoint
+
+Refer to
+
+ https://git.sigsum.org/sigsum/tree/archive/2022-01-18-tree-head-endpoint-observations
+
+for background.
+
+This proposal suggests that we only have two tree head endpoints.
+ 1. get-tree-head-to-cosign -> signed tree head. This is the tree head that
+ witnesses are currently cosigning. This endpoint is only meant to be used
+ by witnesses.
+ 2. get-tree-head-cosigned -> cosigned tree head. This is the finalized tree
+ head that witnesses have finished cosigning. The list of cosignatures is
+ thus fixed.
+
+The to-cosign and cosigned tree heads are rotated every $n minutes. A typical
+value of $n is likely going to be five (5). It might be lower if witnesses
+accept to work more.
+
+Pros:
+ * Less complex API. It has fewer endpoints and no choice between a "quick"
+ or "slow" get-tree-head-cosigned endpoint. No choices means easier tooling,
+ fewer mistakes.
+ * It might be reasonable to speed up the "slow" endpoint by other means, see
+ above.
+
+It is also worth pointing out another pro that we already got from removing the
+get-tree-head-latest endpoint. A submitter is forced to wait a bit, even for a
+signed tree head. This makes it less appealing to "go with a signed tree head
+because its fast". The name of the only signed tree head endpoint also
+discourages usage by submitters.