> 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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel