Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Daniel Roesler]

Does anyone in the pool run hockeypuck? How compatible is its recon
with others running sks-keyserver?

Daniel

On Sat, Jul 14, 2018 at 5:52 AM, Human at FlowCrypt <address@hidden> wrote:
> One more apology - there does seem to be recent activity when you look at
> the repo owner: https://github.com/hockeypuck
>
> Though not loads of activity, still more code contributions than the SKS
> repo: https://bitbucket.org/skskeyserver/sks-keyserver/commits/all
>
> It may be worth considering.
>
> On Sat, Jul 14, 2018 at 12:19 PM, Human at FlowCrypt <address@hidden>
> wrote:
>>
>> Sorry, I hadn't noticed that you linked specifically the conflux
>> (reconciliation code). That is indeed a good start if someone wanted to take
>> the time to understand it.
>>
>> On Sat, Jul 14, 2018, 20:16 Human at FlowCrypt <address@hidden>
>> wrote:
>>>
>>> Hockeypuck has not had any commits in years, if I saw correctly.
>>>
>>> It cannot process some of the keys (maybe for a good reason, but it will
>>> clog the recon mechanism nevertheless, I suppose).
>>>
>>> I think it was a great effort, but apparently not maintained.
>>>
>>> If the recon process could be updated with mechanism where some
>>> implementations could seamlessly choose not to import certain keys, I think
>>> hockeypuck would be a great alternative. It may need to be forked.
>>>
>>>
>>> On Sat, Jul 14, 2018, 19:33 Moritz Wirth <address@hidden> wrote:
>>>>
>>>> Though I am not sure, https://github.com/hockeypuck/conflux may be worth
>>>> a look.
>>>>
>>>> If somebody has a short How-To for installing hockeypuck (and importing
>>>> a keydump..), I am happy to test if it is more stable than sks :)
>>>>
>>>> Best regards,
>>>>
>>>> Moritz
>>>>
>>>>
>>>> Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt:
>>>>
>>>> I would have loved to write an alternative SKS implementation that
>>>> addresses the issues we were seeing recently. However, this:
>>>>
>>>> Set Reconciliation with Nearly Optimal Communication Complexity
>>>> Practical Set Reconciliation
>>>>
>>>>
>>>> is preventing me from doing so. I'm a software engineer, not a
>>>> mathematician, and I have little willingness to attempt implementing an
>>>> algorithm nobody understands.
>>>>
>>>> I wish the title said "simple" and "resilient" rather than "with nearly
>>>> optimal communication complexity", and the contents matched the title.
>>>>
>>>> The pool of engineers willing and able to get us out of this mess would
>>>> be much larger.
>>>>
>>>> On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher <address@hidden>
>>>> wrote:
>>>>>
>>>>>
>>>>> > On 13 Jul 2018, at 22:43, Moritz Wirth <address@hidden> wrote:
>>>>> >
>>>>> > FWIW, has anybody even started working on a fix for any of the bugs?
>>>>>
>>>>> There has been a fair bit of discussion, but no consensus has been
>>>>> reached, apart from a general agreement that major changes to the recon
>>>>> model will be required, and that these will be necessarily
>>>>> backwards-incompatible. That’s generally where the discussion dries up.
>>>>>
>>>>> I get the impression that everyone is holding fire until there is some
>>>>> sign that one particular form of breakage will be more broadly acceptable
>>>>> than the others.
>>>>>
>>>>> A
>>>>>
>>>>> _______________________________________________
>>>>> Sks-devel mailing list
>>>>> address@hidden
>>>>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>>>>
>>>>
>>>>
>
>
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>