Re: [Sks-devel] SKS apocalypse mitigation

[Gabor Kiss]

> I think all SKS servers should attempt to recon with as many other
> servers as they can find. The tools exist to walk the network from a
> known starting point or points and enumerate all responsive hosts. Why
> not have each SKS server walk the network and update the in-memory copy
> of its membership on an ongoing basis? If a previously unknown server
> does try to recon, what's the harm? So long as it recons successfully it
> should go into the list with all the rest.
> 
> That way the membership file as it exists now is just a starting point,
> like the DNS root hints. No more begging on the list for peers. Just
> pre-seed your membership file with a selection of the most stable SKS
> sites (e.g. the ones coloured blue on the pool status page) and within
> an hour you're peering with the entire pool, and them with you.

Okay, brain storming in progress. :-)

Keep the similarity to the DNS.
Don't collect millions of unwanted keys in advance.
Wait until a user request comes then ask discovered peers
for the key wanted, merge the results then send it back to the user.
Also store the key into local database and provide it for other
key servers if they ask you.

Requests may be "iterative" or "recursive" (words are stolen from DNS).
Users send recursive request: "I don't care how many peers
you ask, but tell me the key with all signatures."
A cross server request is iterative: "Send me what you have, no more."
This is to avoid endless storm of circulating requests.

How to maintain a pool of servers like above? How to measure their
quality?
It is more dificult than simply comparing number of locally
stored keys. There will be a dedicated key PMK. Monitoring station issues 
new signatures 3-4 times a day to random subset of pool members
then recursively asks all pool members and aspirants if they
could retrieve all the new sigs on PMK.

To be continued ... :)

Gabor