Skip to content

Meeting Notes 2022 07 11

Jump to bottom
Elias Rohrer edited this page Aug 8, 2022 · 2 revisions

Releases

  • 0.0.109 (https://github.com/lightningdevkit/rust-lightning/milestone/25)
    • No major features
    • Bindings:
    • Shipped for java and TS, swift should be available soon^TM
  • 0.0.110 (https://github.com/lightningdevkit/rust-lightning/milestone/27)
    • Async persisting is one of the major features
    • Matt: it may slip again
    • Buncha stuff open that may merit a release
    • Prefer to land a buncha open stuff, get review on it, then revisit the list for 110 and try not to take too long, cut release in ~2 weeks or so, which means async kv not happening. Gnna try to do prereqs for it, but big proj. Claimable balances needs review, gonna give wilmer some responses soon.
    • Check out “seeking code review” tag
    • Jcantrell: intercepting htlcs – was hoping to get into 110.
    • Matt: think that’s ready for a 2nd reviewer
    • If we’re trying to get it in end of next week, should make it. Slipped on stuff getting 2nd reviewer
    • Ariard: was thinking of using this for next review club

Roadmap Progress

  • Developer support
    • Conor: open for some basic installation introduction, minus swift.
    • Wondering about progress on cocoapods, that’d be good
    • Hoping to release phantom nodes blog post
    • Feel free to give feedback on that, posted on discord
    • Jeff: planning to read thru LdkLite proposal
    • Tnull: feedback welcome. Had some discussions w potential users, will try to make at least some parts configurable from the get go. Not too much more complicated to make at least some parts configurable, so someone else can plug their pathfinding and data persistence
    • Matt: have questions about the pathfinding part, like do they want gossip sync on there or…? And more
    • Tnull: they also wanted on demand channels, like lsp functionality. Think that’s not v1, but can at least make it easier to adapt to that in the future
    • Conor: what about non blocking / supporting async w v1?
    • Tnull: may go with event/queue thing, w simpler Future tag, get an event id from every method that takes a long time and can be used to check the status later. Dont think native rust futures will translate in the bindings, so sth like that will be easier for now. Not sure i wanna expose actual ldk events, but i don’t wanna duplicate them, but some will be dup from LDK side..
    • Matt: would be a lil manual but not that hard if we go down the route of having a lil return value you can poll, and if you have some callback from rust side to pull your things, can map that to futures interface. But yes a lil manual code in native lang there, eg creating js feature and completing it later, that’d have to be js.
    • Matt: Dont think it makes sense to map rust async/await directly. Also its runtime stuff doesn’t map neatly. But creating a simple Future class should be easy to map, basically similar to your event id thing above
  • Payment protocols
  • Language bindings
    • No updates
  • Taproot support
    • Arik: finishing up rapid graph sync blog post and stuff, will be getting to this
  • Anchor outputs
    • wilmer: not a ton to report, had a working PoC of bumping commit txs thru event path in ldk sample. So working on those changes and unrelated test failures, also got bogged down on review last week
  • Lightning Service Provider (LSP)
    • John carvalho: last call went well, cdecker was there. Now had some other ppl from blockstream and now matt in the chat arguing, also had jcantrell submitting his proposal for merging two types of lsp specs to be request vs JIT interception method. Lots of debate but increased understanding of the use case. Things progressing, going well. We do add the meeting notes and there was a recording in the repo, so feel free to join the telegram to get info on that
    • Nick slaney:
    • Carvalho: representation of eclair/lnd not too strong in the group, may have to tag ryan gentry/eclair to get a response
    • Questions arising around supporting mpp in this spec, requires issuing an invoice to the lsp rather than end user, and lsp picks payment secret/signs invoice, etc, and no ability for the sender to communicate to end user (eg putting custom tlvs in the onion)
    • Question about requiring a BOLTs update over this too
    • Jcantrell: why not allow everyone to choose?
    • Matt: complexity blows up

Dependent Projects

  • validating-lightning-signer (https://gitlab.com/lightning-signer/validating-lightning-signer)
    • Ksedgwick: lately working on cln integration and sensei on ldk side. Stackworks has been helping us streamline our feature layout w rust crate packaging, nice to have actual users.
    • Also refining how we think about balance/accounting ledger entries needed
    • SoB intern working on drivers
    • qq: encountered sth about 0-fee anchor htlcs? Is that soon?
    • Matt: cln does not yet support it, ldk anchors will only support it cuz it fixes other issues. I assume cln will eventually support it. Ask them where they are on spending anchors
  • Sensei (https://github.com/L2-Technology/sensei)
    • JC: not much, working on remote networking/pathfinding, then moved onto lsp stuff we already talked about. Proposals for handling intercepts, and implementing it in ldk (open PR rn). Hopefully once we get that in and start to settle on lsp specs, i can get an impl done.
  • Synonym (https://github.com/synonymdev/ldk-node-js)
    • Alex the guy working on the wasm impl, he’s AFK today, but been communicative in the discord so can sync w him there.
    • Corey is here from our mobile team, no qs/blockers yet
    • Made our own RN lib, planning to release wallet in Sept/Oct

Spec (https://github.com/lightning/bolts/issues/1007) - not held

Misc

  • review begs?
Clone this wiki locally