x raid [ARCHIVE] on Nostr: 📅 Original date posted:2021-11-23 📝 Original message: what i can imagine is ...
📅 Original date posted:2021-11-23
📝 Original message:
what i can imagine is each team should provide boxes and channel liquidity
as stake on mainnet for tests before announce a public realise as to feel
the pain first hand instead of having several K´s of plebs confused and at
worst have funds in channelclosed etc. but mostly for helping in smooth
transitioning into future envisioned mass.
If teams rather outsource the running of boxes with channels on mainnet for
impl release and rc versions they would of course be able to, but close to
home for managing analysis of the team impl themselves is what I would
recommend.
Can also see that each box loglines are collected at one central point
whereby requests can be made for comparing interoperability per unix.ts
identified by box.
(thats alot of data You say --not really in Big Data terms, question is
where to set a proper cap in time for collections ? a week ? a month ?)
I think i might have a solution for the central point collector that could
be run by an outside of impl teams perimeter. (sponsored?)
/xraid
On Tue, Nov 23, 2021 at 11:35 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning again x-raid,
>
> Are you proposing as well to provide the hardware and Internet connection
> for these boxes?
>
> I know of one person at least who runs a node that tracks the C-Lightning
> master (I think they do a nightly build?), and I run a node that I update
> every release of C-Lightning (and runs CLBOSS as well).
> I do not know the actual implementations of what they connect to, but LND
> is very popular on the network and LNBIG is known to be an LND shop, and
> LNBIG is so pervasive that nearly every long-lived forwarding node has at
> least one channel with *some* LNBIG node.
> I consider this "good enough" in practice to catch interop bugs, but some
> interop bugs are deeper than just direct node-to-node communications.
> For example, we had bugs in our interop with LND `keysend` before, by my
> memory.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/2a4afb38/attachment-0001.html>;
📝 Original message:
what i can imagine is each team should provide boxes and channel liquidity
as stake on mainnet for tests before announce a public realise as to feel
the pain first hand instead of having several K´s of plebs confused and at
worst have funds in channelclosed etc. but mostly for helping in smooth
transitioning into future envisioned mass.
If teams rather outsource the running of boxes with channels on mainnet for
impl release and rc versions they would of course be able to, but close to
home for managing analysis of the team impl themselves is what I would
recommend.
Can also see that each box loglines are collected at one central point
whereby requests can be made for comparing interoperability per unix.ts
identified by box.
(thats alot of data You say --not really in Big Data terms, question is
where to set a proper cap in time for collections ? a week ? a month ?)
I think i might have a solution for the central point collector that could
be run by an outside of impl teams perimeter. (sponsored?)
/xraid
On Tue, Nov 23, 2021 at 11:35 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning again x-raid,
>
> Are you proposing as well to provide the hardware and Internet connection
> for these boxes?
>
> I know of one person at least who runs a node that tracks the C-Lightning
> master (I think they do a nightly build?), and I run a node that I update
> every release of C-Lightning (and runs CLBOSS as well).
> I do not know the actual implementations of what they connect to, but LND
> is very popular on the network and LNBIG is known to be an LND shop, and
> LNBIG is so pervasive that nearly every long-lived forwarding node has at
> least one channel with *some* LNBIG node.
> I consider this "good enough" in practice to catch interop bugs, but some
> interop bugs are deeper than just direct node-to-node communications.
> For example, we had bugs in our interop with LND `keysend` before, by my
> memory.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211123/2a4afb38/attachment-0001.html>;