If it is a technical challenge and Kristian as head (pool maintainer),
why does he not ask publicity
the hockeypuck author, dkg and the sequoia-team, for help?
As an example, if I would be Kristian I would do so, set-up with my
pool gang a hockeypuck
test-net (bootstrapped with a handful of pub ke
> On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users
> wrote:
>
> there can
> be no consensus achieved between privacy loving EU citizens and (US
> based) SKS operators
Most SKS operators are (were?) based outside the US. This is primarily a
technical challenge, not a political one.
A
I can only speak for myself and see that when it comes to SKS that there can
be no consensus achieved between privacy loving EU citizens and (US
based) SKS operators, while Mailvelope and Hagrid respect the users wishes.
With that being said I am out and better let Mr Barr and Mr de Kerchove decid
On 23/10/2020 13:23, Andrew Gallagher wrote:
> * Hints could take the form of fake preferred-keyserver subpackets, in a
> similar manner to fake "fpr:DEADBEEF" user-id packets that have been
> previously discussed to support UID-less key refresh on legacy systems
> (could both be combined in a sing
On 23/10/2020 10:14, Bernhard Reiter wrote:
> So yes, I also believe that improvements to hockeypuck or a fresh
> implementation could step by step get the public keyserver network up again.
I've thought about this quite a bit after my previous attempts to
reconcile recon with selective retention
Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> I stand by my points that hockeypuck can solve the issues
To me
it makes sense to preserve a decentalised network of public keyservers [1].
In my post
Preserving non-central and privacy with a "permission recording keyserver"
[R
