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 <b...@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 <laol...@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.dro...@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@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev