Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

[robots.txt fan]

On Wednesday, February 6, 2019 8:28 PM, Robert J. Hansen <address@hidden> wrote:
> It's a lack of community consensus on what a redesign should look like.

That can be changed. I do not know anything about the source code of this 
project, so forgive my naivety.

Is it possible to develop a keyserver thar uses the same interface as the 
current one? Meaning that GnuPG-Clients don't need to change and current 
keyservers can recon with the new keyservers (since they are not all upgraded 
simultaniously)?

Of course, that while also being able to not accept large keys. A first step 
might be limiting UIDs to a certain size, but then one could just generate lots 
of UIDs, or if you also limit the number of UIDs per key, they could generate 
lots of keys.

Furthermore, what would be nice if content could be deleted. I'm thinking about 
GDPR requests from people who do not want their data online anymore, or illegal 
content coded into UIDs or User Attribute Packets. Perhaps this can be 
implemented through a blacklist of fingerprints that synchronises.

Are there any more problems that need to be fixed? Like seriously, everyone 
please write the problems they have with SKS.

To answer my first question, I guess that it is possible to implement a 
keyserver with the same interface for GPG users that can still recon with older 
servers. The older servers might try to send them keys that are on the 
blacklist or are large, but the new server can reject those keys of course.