<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Thu, 10 Dec 2020 19:59:46 +0000<br>From: Andrew Gallagher <<a href="mailto:andrewg@andrewg.com" target="_blank">andrewg@andrewg.com</a>><br>To: SKS Development and Deployment discussion <<a href="mailto:sks-devel@nongnu.org" target="_blank">sks-devel@nongnu.org</a>>,<br>        GnuPG Users <<a href="mailto:gnupg-users@gnupg.org" target="_blank">gnupg-users@gnupg.org</a>><br>Subject: Re: [Keyserver] Hockeypuck 2.1.0 released<br>Message-ID: <<a href="mailto:de8589f0-adb4-6cab-f909-2528bc33d4cc@andrewg.com" target="_blank">de8589f0-adb4-6cab-f909-2528bc33d4cc@andrewg.com</a>><br>Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>How do you handle the gradual degradation of sync as different operators<br>implement divergent blacklists?<br></blockquote><div><br></div><div>This might be a controversial opinion, but I would allow it to happen.</div><div><br></div><div>Even if reconciliation cannot provide perfect consistency in such a world, it is still useful as a gossip protocol to distribute new keys and signatures.<br></div><div><br></div><div>My prediction (given keyserver operator buy-in) is, some cohorts of like-minded keyserver operators will coordinate on their settings. Peers in these cohorts will keep relatively more closely in sync and propagate key material faster amongst themselves, than with those that have different policies that cause them to diverge more widely. Peers across these more divergent cohorts may still peer at a lower frequency, so key material accepted by both may still propagate.</div><div><br></div><div>-Casey<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A<br>On 10/12/2020 17:07, Casey Marshall wrote:<br>> I've released Hockeypuck 2.1.0<br>> <<a href="https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0" rel="noreferrer" target="_blank">https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0</a>> [0], which</blockquote><br></div>