Hi Hart, all,

Hope this is the right forum for feedback: if I should be on the wiki or inside the Google Doc just let me know and I’ll shift over.

By and large, looks great, and I appreciate the clear thought that has gone into making this a practical and actionable structured project.  

I have a handful of comments/questions:

1. The tiering between 2 and 3 is not completely clear to me in one regard: specifically, we’re talking firmly in tier 2 about things in that are used (widely?) in practise, but then tier 3 goes right to science experiments.  What do we do with things like leading post-quantum algorithms that are relatively well known and trod but are not yet standards approved and are still being refined?  Would such things default to tier 3 and then be promoted when we’re happy with the implementation?  Or default to tier 2 and then be taken out if they’re judged dangerous?

2. I appreciate (and agree with) the intent of the ‘overwhelming consensus’ requirement for doing important things, but as time goes on and people come and go I’m concerned that such loose language could cause unnecessary controversy at some point.  Why not define this more concretely as 2/3 super majority or similar as it is later on in the doc? Note that this also implies a requirement to manage the voting eligibility of members, but ‘twas ever thus.

3. Since sub-projects are defined essentially as creating code modules for people to incorporate into their super projects, we should assume that dependent super projects will incorporate a number of these modules in order to satisfy all their Crypto-related needs.  It follows therefore that there’s a clear need to ensure that (most of) those modules follow a consistent architectural pattern, implement the same API Design philosophy, and very strictly agree on the semantics and data typing of parameters that may be shared, or at least commonly expressed, between them.  Apart from the obvious programming sanity requirement here, we’ve all seen plenty of cases where plugging together 2 secure things makes one big insecure thing.  Who/what role will do this?  It’s good that the sub projects are independent and self-governing most of the time but Inthink something like an API Council is required here. 

4. Assuming this proposal will at some point become  enshrined and semi-public, it would probably be polite to replace the “incredibly foolish” language.  You’re right, but still.  Optics.

5. I want a Golang version.  Would that be a subproject shim, or just a separate output of the one base lib project?

5a. I’d like a discussion about safe languages in general, but that can happen in slower time.

6. What tier of Project is the dunking booth?  It doesn’t seem to quite fit any consistent set of the criteria for any band.

Jon