On 05/05/2018 10:22 AM, Andrew Gallagher wrote: > >> On 5 May 2018, at 15:00, brent s. <b...@square-r00t.net> wrote: >> >> (a) is taken care of by recon already (in a way), > > According to a list message from earlier today it is not. If the delta is > small, recon proceeds. If it is large, it breaks catastrophically. There is > no (current) way to test nicely. >
sorry, should have clarified- i mean the "generating deltas" part of (a). >> but the problem for >> (b) is the "standard place" - SKS/recon/HKP/peering is, by nature, >> unfederated/decentralized. sure, there's the SKS pool, but that >> certainly isn't required for peering (even with keyservers that ARE in >> the pool) nor running sks. how does one decide the "canonical" dump to >> be downloaded in (b)? > > There can be no canonical dump of course. Each peer can provide its own dump > at a well known local URL. This is even more important if and when we allow > divergent policy. hrm. i suppose, but i'm under the impression not many keyserver admins run their own dumps? (which i don't fault them for; the current dump i have in its uncompressed form is 11 GB (5054255 keys). granted, you don't see new keyserver turnups often, but still -- that can be a lengthy download, plus the fairly sizeable chunk of time it takes for the initial import.) -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel