> There are a handful of people with the background and skills to write a > next-generation keyserver. I looked into it a dozen years ago and wrote > up a whitepaper on it. I know Phil Pennock has put a lot of thought > into it. Andrew, likewise. There are easily five or six people on this > list who have the time and ability. > > What we don't have is *consensus* -- not only among ourselves, but in > the larger community. > > Let's say I decide to implement my whitepaper from 2007. It would take, > oh, call it 200 hours of work to implement. So I write it, put it out > there, and nothing happens because there's no consensus my idea is the > direction we should go. > > The problem here is not a lack of manpower or skill. > > It's a lack of community consensus on what a redesign should look like.
My 2 cents: It is no use to wait a great consensus. The working model of open source development is: 10 publishing a formal protocol description[1] 20 some peoples implement it 30 collecting experiments 40 years later other peoples write a different implemantation that is compatible with the original 50 GOTO 30 [1]: The famous paper describes the _algorithm_. A protocol description writes bit-by-bit what is transferred on the wire, what to in case of any errors, what must to do and what is optional etc. See RFCs. If there would be _competing_ implementations operators could choose which one they run. This is an evolution. Remember Sendmail. 30-40 years ago it was virtually the only (non proprietary) mail transfer agent (MTA). Eric Allman did a great job. But later other guys had different ideas. Now there is a dozen MTAs on the market and almost nobody uses Sendmail. But some do. And all these programs can talk each to other due to RFC 821 (1982). Gabor _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
