Skip to content

Meeting Notes 2023 04 03

Jump to bottom
Elias Rohrer edited this page Apr 3, 2023 · 1 revision

Releases

Roadmap Progress

  • Developer support

    • Conor: want to bring attention to 156 on the lightningdevkit.org repo: https://github.com/lightningdevkit/lightningdevkit.org/pull/156 will be trying to get this finished soon, esp given the amount of api changes from 114
    • Rejiggers our tutorial docs to be in-inline with how we’d expect someone to approach building a node. Will be seeking feedback.
    • Jeff: it throws me that the tutorials aren’t in the sidebar.

  • Payment protocols

    • Progress on stateless offers, should be reviewable with just a minor thing outstanding
    • Route blinding pathfinding PR should be updated today

  • Language bindings

    • Jurvis uploaded a maven package for android for LDK Node
      • Trying to get ldk node into our project, but hard to get people to put a git submodule, integrate into existing build tools. Ended up making sense to upload ldk node to central maven. I have my own local version, but hoping to upstream it. Mostly based on what bdk’s already doing, got thunderbiscuit to take a look. Still a few outstanding things from tnull to do. We need some help getting the pgp keys set up…
      • Matt: tnull was looking into this. Afaict, no way to do multi user uploads to maven central, username/pw, and some kind of pgp verification, but no way to enroll a pgp key. Can’t tell if it’s TOFU or just any pgp key with your email address on it. No docs, seems like nonsense. So not sure what we’re going to do
      • Tnull: you can add another user, but need to do it via a Jira ticket. And no 2fa, and not sure maven central is verifying the pgp keys
      • Jurvis: think they have a whitelist of key servers

  • Taproot support

    • The PR with the message types is nearing merge
    • Last PR before we can test interop is under way

  • Anchor outputs

    • There were a series of PRs that the BumpEventHandler depended on. Those are merged, working now on getting through some feedback from the event handler PR itself. Should have an update this week
    • That’s most it for anchor support. We want to add some small code around opening/accepting, so you don’t open too many channels w/o having some onchain balance to back them up. Plan is for this to all be done by 115, but the config flag won’t be flipped til 116, which is when you’ll actually be able to use the public api. But once 115 releases, if you want to start testing stuff, you can just build with the anchors config flag (should be noted in release notes/discord)

  • LSP

    • Nick slainey: Zmnscpxj has been pushing on the LSP spec. Transport layer part is trending towards using bolt8, and hoping to settle JIT channel spec too, nearly there.
    • Graham from voltage built an LSP, not sure if he’s looked at the spec. Will talk to him soon, he’s talking about doing the wrapped invoices method, but we’re going for the route hints method
    • 1 q: is LDK Node going to be integrating the client side of the LSP spec?
    • Tnull: yes, definitely. It’s a SoB project i’ll be mentoring, with several potential candidates interested atm.
      • Hoping to implement the client spec directly against the spec. Otherwise, we’ll implement against an available LSP server.
      • Any timeframe when you’d implement the server end, or have a mock we could build against for testing?
      • Nick: once we have LSPS3 stable, will start implementing that in earnest. Wonder if SoB project might be a little longer than when we’re going to start working on it, jurvis wants to integrate it into his work asap
      • Jeff: SoB tends to be enough for 2-3 PRs, depending on content ofc
      • Tnull: may be nice to have LSP stuff in a separate crate. Lightning transport layer – nice to have ser types for that in some generic rust LSP crate or sth. Could maybe help in that the SoB mentee wouldn’t have to do everything
      • John cantrell: when we start, we’ll start with message implementation, not sure if it makes sense for us to create a repo for that and the mentee can contribute there…?
      • Tnull: at least the more generic parts could live in an OSS repo. SoB starts in ~a month. Hope the spec is pretty ready by then
      • Jcantrell: yeah we should be done by then, hoping to move fast.
      • Jurvis: a separate crate would be beneficial for us. We’re not going to have our mobile nodes talk directly to the LSP
      • Tnull: let’s create a shared repo under lightningdevkit with all the basic types/message handling/exposing custom message handler
      • Jcantrell: makes sense. In terms of process of creating the repo/getting commit access, not sure, but overall yes

  • VSS (Versioned Storage Service)

    • Gursharan: adding encryption and testing

  • LDK Node

    • Tnull: Payment storage PR is ready from my side. I put the kvstore interface in there. Getting closer to release now, starting to include minor refactors of the API to make things uniform. With additional help on the bindings end, we could even release with uniffi bindings from the start, it looks like
    • Tnull: in terms of vss, we want to store everything there except the seed, which s currently provided in-memory or as a file on disk. Everything else would be persisted by the kvstore interface to whatever the backend is (currently a new FilesystemPersister, planning to add Sqlite). This ensures that users can write their own backends against the kvstore interface, and not care about different locations for diff data

  • Dual funding channels

    • Jurvis: will give an overview based on the past 3 meetings with dunxen. The q is how to get to splicing/DF channels, since there’s some overlap, so we’re figuring out how to split up the work.
    • 2 PRs open, 1794 and 2077, from dunxen, that should free us up to work on interactive tx constructor, flow for channel negotiation, etc. i’m not cued in on technical details atm, but this dependency graph allows us to think about the work needed in terms of partitions. Subject to change.
    • Meetings 7pm utc wednesday, see #splicing on the discord
    • Notes: https://docs.google.com/document/d/1kf-0ROffMtga-8dTDH7S42XHw6jvu729hZj1seUhVag/edit?usp=sharing

  • Splicing (new)

Dependent Projects

Spec

Misc

  • review begs?
Clone this wiki locally