Skip to content

Meeting Notes 2023 01 23

Elias Rohrer edited this page Jan 23, 2023 · 1 revision

Releases

2023 Priorities

Roadmap Progress

  • Developer support
  • Payment protocols
    • Async payments
      • Hoping to open all the channelmanager retry PRs soon and garner review over the next couple weeks
    • Offers
      • Jeff has a fuzzing PR out
      • Working on stateless offers, should be trivial
  • Language bindings
    • Adapting to the latest bindings may be annoying due to change to camelCase and other changes
  • Taproot support
    • Taproot depends on anchors so we've been making progress on that
    • We had the open channel support merged last week (nothing exposed yet til the full patchset is merged)
    • Taproot itself: we've been making a set of refactorings in LDK. had a couple merged last week. Getting close to working on taproot signer, since we're introducing a new TaprootSigner trait, that the InMemorySigner will be implementing. Will be something that VLS needs to do.
    • Spec front: no major updates
    • Waiting on LND to do some interop and have some PRs to review at the spec level, but nothing major
  • Anchor outputs
  • LSP
    • Updated original ChannelRequest spec to add some granular states
    • Deezy.io has implemented the spec. we (Synonym) will proceed with implementing it as well in a few weeks and encouraging breez as well
  • VSS (Versioned Storage Service)
    • PR for impl of get & put with postgres based impl is up. That contains the logic for optimistic locking and global versioning
      • Needs approach review, then will write tests
  • LDK Node
    • Good progress, merged event handling PR
    • Wallet PR is getting close as well as tx sync against esplora
    • Jeff to review
  • Dual funding channels
  • Splicing (new)

Dependent Projects

Spec

Misc

  • BitcoinZavior: been dabbling with LDK recently. Such as bundling LDK Node in rust and bundling it as a flutter package (been coordinating with tnull on this). I've shared this package in the LDK Node channel and some people have tried it
    • The architecture i'm using for this is very similar to BDK Flutter, which is starting to be adopted
      • Not using the binaries produced as output of ffi project. That's the architecture used by most flutter packages. It's bc we have the rust code, and for flutter there is the flutter-rust bridge, which lately has become quite good
      • So it has the same api as LDK Node in rust
    • Major issue is that a lot of wrapper code is needed.
    • Measured perf of different approaches to bindings - For react-native, prefer swift/android binaries. For flutter, prefer to use the rust interface directly.
  • review begs?
Clone this wiki locally