persisted pads from meeting minutes

3 files changed, 88 insertions, 0 deletions

diff --git a/archive/2022-01-25-notes-on-gossamer b/archive/2022-01-25-notes-on-gossamer
new file mode 100644
index 0000000..7bfc862
--- /dev/null
+++ b/archive/2022-01-25-notes-on-gossamer
@@ -0,0 +1,25 @@
+We got a tip from Grgoire[m] to take a look at
+
+	https://gossamer.tools/
+
+because the FAQ and overall use-case sounded Sigsum related.
+
+Below is a brief summary after navigating their documentation for ~15m.
+	* Some of their standpoints are similar to Sigsum.  For example, they are
+	pointing out that CT is complex and that the use of Ed25519 is good. [1]
+	* Their security goals cannot be satisified by a transparency log.  See the
+	definition of "append-only" and "availability". [2] They use a backend
+	called Chronicle [3] to create a Blakechain [4].  It looks a bit like a
+	blockchain.  Events are chained linearly.  It is unclear how consensus or
+	gossip is solved, but not PoW/PoS/etc.
+	* The gist of their use-case is to sign messages with different
+	types of actions. [5]  If these actions become public, good things can
+	happen. There are applications to WordPress and the PHP world. [1]  A
+	claimant model + Sigsum can probably be used if the threat model is changed
+	to work with transparency logs.
+
+1: https://gossamer.tools/page/questions
+2: https://github.com/paragonie/libgossamer/blob/master/docs/specification/Overview.md#security-goals-and-desired-properties
+3: https://github.com/paragonie/chronicle
+4: https://github.com/paragonie/blakechain
+5: https://github.com/paragonie/libgossamer/blob/master/docs/specification/Protocol.md#serialization-formats
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.