[Lightning-dev] Removing lnd's source code from the Lightning specs repository

lisa neigut niftynei at gmail.com
Tue Oct 12 23:03:52 UTC 2021


Love the idea of moving the specs etc to github.com/lightning, thanks so
much for generously offering to donate this Laolu. Strong ACK from me.

Given how difficult the existing org is wrt ownership etc, moving to a new
one makes a lot of sense to me.

Thanks Fabrice for bringing this up so we could discuss it and get a better
understanding of the difficulties with the existing situation.

- nifty

On Wed, Oct 13, 2021 at 00:48 Damian Mee <btc at meedamian.com> wrote:

> While I don't partake in the conversations too often, I just want to say I
> strongly support Olaoluwa suggestion.  AFAIAA there's a lot of automations,
> dependencies, dockerfiles, or direct links to files that rely on the
> location of lnd github repo, and I'm sure not all of it would be able to
> handle Github redirect gracefully.  While accessing spec is mostly a
> human/browser activity, where dealing with redirects is much easier.
>
> Plus, github.com/lightning/spec, github.com/lightning/bolts, and/or
> github.com/lightning/rfc would all be trivial to remember, and quick to
> type.
>
> On Tue, Oct 12, 2021 at 2:57 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
>
>> Hi Fabrice,
>>
>> > I believe that was a mistake: a few days ago, Arcane Research published
>> a
>> > fairly detailed report on the state of the Lightning Network:
>> > https://twitter.com/ArcaneResearch/status/1445442967582302213.  They
>> > obviously did some real work there, and seem to imply that their report
>> > was vetted by Open Node and Lightning Labs.
>>
>> Appreciate the hard work from Arcane on putting together this report. That
>> said, our role wasn't to review the entire report, but instead to provide
>> feedback on questions they had. Had we reviewed the section in question,
>> we
>> would have spotted those errors and told the authors to fix them. Mistakes
>> happen, and we're glad it got corrected.
>>
>> Also note that lnd has _never_ referred to itself as the "reference"
>> implementation.  A few years ago some other implementations adopted that
>> title themselves, but have since adopted softer language.
>>
>> > So I'm proposing that lnd's source code be removed from
>> > https://github.com/lightningnetwork/ (and moved to
>> > https://github.com/lightninglabs for example, with the rest of their
>> > Lightning tools, but it's up to Lightning Labs).
>>
>> I think it's worth briefly revisiting a bit of history here w.r.t the
>> github
>> org in question. In the beginning, the lightningnetwork github org was
>> created by Joseph, and the lightningnetwork/paper repo was added, the
>> manuscript that kicked off this entire thing. Later lightningnetwork/lnd
>> was
>> created where we started to work on an initial implementation (before the
>> BOLTs in their current form existed), and we were added as owners.
>> Eventually we (devs of current impls) all met up in Milan and decided to
>> converge on a single specification, thus we added the BOLTs to the same
>> repo, despite it being used for lnd and knowingly so.
>>
>> We purposefully made a _new_ lightninglabs github org as we wanted to keep
>> lnd, the implementation distinct from any of our future commercial
>> products/services. To this day, we've architected all our paid products to
>> be built _on top_ of lnd, rather than within it. As a result, users always
>> opt into these services.
>>
>> As it seems the primary grievance here is collocating an implementation of
>> Lightning along with the _specification_ of the protocol, and given that
>> the
>> spec was added last, how about we move the spec to an independent repo
>> owned
>> by the community? I currently have github.com/lightning, and would be
>> happy
>> to donate it to the community, or we could create a new org like
>> "lightning-specs" or something similar. We could then move the spec (the
>> BOLTs and also potentially the bLIPs since some devs want it to be within
>> its own repo) there, and have it be the home for any other
>> community-backed/owned projects.  I think the creation of a new github
>> organization would also be a good opportunity to further formalize the set
>> of stakeholders and the general process related to the evolution of
>> Lightning the protocol.
>>
>> Thoughts?
>>
>> -- Laolu
>>
>> On Fri, Oct 8, 2021 at 5:25 PM Fabrice Drouin <fabrice.drouin at acinq.fr>
>> wrote:
>>
>>> Hello,
>>>
>>> When you navigate to https://github.com/lightningnetwork/ you find
>>> - the Lightning Network white paper
>>> - the Lightning Network specifications
>>> - and ... the source code for lnd!
>>>
>>> This has been an anomaly for years, which has created some confusion
>>> between Lightning the open-source protocol and Lightning Labs, one of
>>> the companies specifying and implementing this protocol, but we didn't
>>> do anything about it.
>>>
>>> I believe that was a mistake: a few days ago, Arcane Research
>>> published a fairly detailed report on the state of the Lightning
>>> Network: https://twitter.com/ArcaneResearch/status/1445442967582302213.
>>> They obviously did some real work there, and seem to imply that their
>>> report was vetted by Open Node and Lightning Labs.
>>>
>>> Yet in the first version that they published you’ll find this:
>>>
>>> "Lightning Labs, founded in 2016, has developed the reference client
>>> for the Lightning Network called Lightning Network Daemon (LND)....
>>> They also maintain the network standards documents (BOLTs)
>>> repository."
>>>
>>> They changed it because we told them that it was wrong, but the fact
>>> that in 2021 people who took time do do proper research, interviews,
>>> ... can still misunderstand that badly how the Lightning developers
>>> community works means that we ourselves badly underestimated how
>>> confusing mixing the open-source specs for Lightning and the source
>>> code for one of its implementations can be.
>>>
>>> To be clear, I'm not blaming Arcane Research that much for thinking
>>> that an implementation of an open-source protocol that is hosted with
>>> the white paper and specs for that protocol is a "reference"
>>> implementation, and thinking that since Lightning Labs maintains lnd
>>> then they probably maintain the other stuff too. The problem is how
>>> that information is published.
>>>
>>> So I'm proposing that lnd's source code be removed from
>>> https://github.com/lightningnetwork/ (and moved to
>>> https://github.com/lightninglabs for example, with the rest of their
>>> Lightning tools, but it's up to Lightning Labs).
>>>
>>> Thanks,
>>>
>>> Fabrice
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/ceeabee8/attachment.html>


More information about the Lightning-dev mailing list