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 >>> <http://ipsit.bu.edu/documents/ieee-it3-web.pdf> >>> - Practical Set Reconciliation >>> <http://ipsit.bu.edu/documents/BUTR2002-01.ps> >>> >>> >>> 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
