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 <hu...@flowcrypt.com> 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 <hu...@flowcrypt.com> > 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 <hu...@flowcrypt.com> >> 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 <m...@flanga.io> 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 <andr...@andrewg.com> >>>> wrote: >>>>> >>>>> >>>>> > On 13 Jul 2018, at 22:43, Moritz Wirth <m...@flanga.io> 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 >>>>> Sks-devel@nongnu.org >>>>> https://lists.nongnu.org/mailman/listinfo/sks-devel >>>> >>>> >>>> > > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel