added start on README version 3

1 files changed, 41 insertions, 19 deletions

diff --git a/README.md b/README.md
index a1e8b9c..6a078ca 100644
--- a/README.md
+++ b/README.md
@@ -44,41 +44,63 @@ uptime, stability, etc.  In the meantime you may get your hands dirty by running
 STFE locally.  Rough documentation is available
 [here](https://github.com/system-transparency/stfe/blob/main/server/README.md).
 
-## What should be considered?
+## What was considered?
+### Gossip-audit model
 Simply adding something into a transparency log is a great start that has merit
 on its own.  But, to make the most of a transparency log we should keep the
 following factors in mind as the ecosystem bootstraps and develops:
-1. Client-side tooling should ultimately fail-close if a signed checksum is not
-transparency logged.  This requires a reliable and available log ecosystem.
-This is easier to achieve if there are multiple independent log operators.
-2. Client-side tooling should verify that the signed checksums appears in a log.
-This requires inclusion proof verification.  STFE forces this by never issuing
+1. Clients should verify that the signed checksums appear in a log.  This
+requires inclusion proof verification.  STFE forces this by never issuing
 so-called _promises to log_ as in [Certificate
 Transparency](https://tools.ietf.org/html/rfc6962).<sup>[2](#footnote-2)</sup>
-3. Client-side tooling should verify that the log is append-only.  This requires
-consistency proof verification.
-4. Client-side tooling should convince themselves that they see the same append-only
-log as everyone else.  This requires a well-defined gossip-audit model.
+2. Clients should verify that the log is append-only.  This requires consistency
+proof verification.
+3. Clients should convince themselves that they see the same append-only log as
+everyone else.  This requires a well-defined gossip-audit model.
 
 That last point is often overlooked.  While transparency logs are verifiable in
 theory due to inclusion and consistency proofs, _it is paramount that the
 different parties interacting with the log see the same entries and
 cryptographic proofs_.  Therefore, we built a proactive gossip-audit model
-directly into STFE: _witness cosigning_.<sup>[3](#footnote-3)</sup>  The idea is that many independent
-witnesses _cosign_ the log's STH if and only if they see a consistent
-append-only log.  If enough reputable parties signed-off the log's cryptographic
-state, you can be pretty sure that you see the same log (and thus the same
-checksums) as everyone else.
+directly into STFE: _witness cosigning_.<sup>[3](#footnote-3)</sup>
+The idea is that many independent witnesses _cosign_ the log's STH if and only
+if they see a consistent append-only log.  If enough reputable parties run
+witnesses that signed-off the same STH, you can by corollary be pretty sure that
+you see the same log (and thus the same checksums) as everyone else.
 
 Moreover, if you already rely on witness cosigning for security, all you need
 from, say, a software publisher, is an artifact, a public verification key, a
-cosigned STH, and an inclusion proof up to that STH.  That is excellent
-because client-side verification becomes completely non-interactive!
+cosigned STH, and an inclusion proof up to that STH.  To clarify why that is
+excellent: client-side verification becomes completely non-interactive!
+
+### Ecosystem robustness
+Our long-term aspiration is that clients should _fail-close_ if a checksum is
+not transparency logged.  This requires a _robust log ecosystem_.  As more
+parties get involved by operating compatible logs and witnesses, the overall
+reliability and availability improves for everyone.  An important factor to
+consider is therefore the _minimal common denominator_ to transparency log
+checksums.
+
+STFE uses a leaf type that contains just enough information to establish a
+context for clients and monitors:
+1. What entity should the checksum be attributed to (follows from signature and
+namespace).
+2. What does the checksum refer to so that the data can be located (identifier).
+
+Additional metadata needs can be included in the data that the checksum covers,
+and the data itself can be stored in a public unauthenticated archive.  It would
+be more difficult to build compatible logs if everyone wanted their own leaf
+type.  Similarly, log APIs and data formats should ideally suit all.  We are
+still thinking about that.
+
+### Spam mitigations
+Important factors: leaf is small, leaf is signed.
 
 ##
 <a name="footnote-1">1</a>:
-The academic literature documents this challenge quite well with regards to
-Certificate Transparency.  See, for example, the work of
+The lack of gossip-audit models that prevent and/or detect _split-views_ is
+documented quite well with regards to Certificate Transparency.  See, for
+example, the work of
 [Chuat _et al._](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7346853),
 [Nordberg _et al._](https://tools.ietf.org/html/draft-ietf-trans-gossip-05), and
 [Dahlberg et al.](https://sciendo.com/article/10.2478/popets-2021-0024).