Vincenzo Palazzo [ARCHIVE] on Nostr: ð Original date posted:2023-02-11 ð Original message: On Wed Feb 8, 2023 at ...
ð
Original date posted:2023-02-11
ð Original message:
On Wed Feb 8, 2023 at 9:17 PM CET, Carla Kirk-Cohen wrote:
> Hi list,
>
> Unfortunately we had some technical issues with the recording for
> Monday's call so we're going to have to rely on my memory (a severely
> corrupted data store). Thankfully, Clara jotted down some notes as well,
> but please chime in if you attended and we've missed something out!
>
> Details for next call:
> * Monday 20 February
> * 18:00 UTC (possibly 19:00, be confirmed in a follow up email)
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/3
>
Thanks to write this down, do you think that it is a good idea
to make a public google calendar (or other kind of shared calendar)?
>4. Reputation discussions in LSP Specification
>?Some attendees have been working on a reputation system for the LSP
>specification group [8]. This system is intended to provide standard
>metrics about what makes a node good/bad to connect to in the context
>of a decentralized marketplace. While this work looks at the problem
>from a different perspective, there's a possibility to consolidate
>the efforts. It seems particularly useful in the anti-jamming case
>where a node has newly connected to you, and needs a "start state"
>reputation score. The idea of defining what qualifies as good
>behavior in the Lightning Network is useful across the board. The
>LSP specification group also has bi-weekly calls, and welcomes
>additional participants!
There is also an ongoing attempt to define a kind of standard
for the lightning network metrics started more thatn 1 year
ago, and I also discussed in Oakland (but maybe some people
was scared by the word `server`)
The source code is available here https://github.com/LNOpenMetrics
and for now the basic idea is to collect some data from different
kind of node and analyze them before taking any decision to define
any kind of protocol support via BOLT or BLIPS (I also I'm more inclined
to a BLIPS because I think that different kind of node mobile vs LSP)
can deserve different kind of metrics/reputation.
There are some data already accessible via public API (for now) https://api.lnmetrics.info
where it is possible to see some forwarding payment scoring by channels and node
uptime.
Cheers!
Vincent.
ð Original message:
On Wed Feb 8, 2023 at 9:17 PM CET, Carla Kirk-Cohen wrote:
> Hi list,
>
> Unfortunately we had some technical issues with the recording for
> Monday's call so we're going to have to rely on my memory (a severely
> corrupted data store). Thankfully, Clara jotted down some notes as well,
> but please chime in if you attended and we've missed something out!
>
> Details for next call:
> * Monday 20 February
> * 18:00 UTC (possibly 19:00, be confirmed in a follow up email)
> * https://meet.jit.si/UnjammingLN
> * Agenda: https://github.com/ClaraShk/LNJamming/issues/3
>
Thanks to write this down, do you think that it is a good idea
to make a public google calendar (or other kind of shared calendar)?
>4. Reputation discussions in LSP Specification
>?Some attendees have been working on a reputation system for the LSP
>specification group [8]. This system is intended to provide standard
>metrics about what makes a node good/bad to connect to in the context
>of a decentralized marketplace. While this work looks at the problem
>from a different perspective, there's a possibility to consolidate
>the efforts. It seems particularly useful in the anti-jamming case
>where a node has newly connected to you, and needs a "start state"
>reputation score. The idea of defining what qualifies as good
>behavior in the Lightning Network is useful across the board. The
>LSP specification group also has bi-weekly calls, and welcomes
>additional participants!
There is also an ongoing attempt to define a kind of standard
for the lightning network metrics started more thatn 1 year
ago, and I also discussed in Oakland (but maybe some people
was scared by the word `server`)
The source code is available here https://github.com/LNOpenMetrics
and for now the basic idea is to collect some data from different
kind of node and analyze them before taking any decision to define
any kind of protocol support via BOLT or BLIPS (I also I'm more inclined
to a BLIPS because I think that different kind of node mobile vs LSP)
can deserve different kind of metrics/reputation.
There are some data already accessible via public API (for now) https://api.lnmetrics.info
where it is possible to see some forwarding payment scoring by channels and node
uptime.
Cheers!
Vincent.