Damian Mee [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-12 📝 Original message: While I don't partake in ...
📅 Original date posted:2021-10-12
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211012/ec257326/attachment-0001.html>;
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211012/ec257326/attachment-0001.html>;