diff options
| -rw-r--r-- | archive/2022-01-25-notes-on-gossamer | 25 | ||||
| -rw-r--r-- | doc/proposals/2022-01-how-to-use-proposal-folder | 31 | ||||
| -rw-r--r-- | doc/proposals/2022-01-no-quick-tree-head-endpoint | 32 |
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. |