Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrappers, helpers, and syntactic sugar on BDK #266

Closed
danielnordh opened this issue Nov 29, 2022 · 4 comments
Closed

Wrappers, helpers, and syntactic sugar on BDK #266

danielnordh opened this issue Nov 29, 2022 · 4 comments
Labels
discussion Issue requires some discussion first language: swift

Comments

@danielnordh
Copy link

danielnordh commented Nov 29, 2022

Following up from discussions in discord on this subject, I thought I'd think through the case for adding some convenience methods particular for Swift, and SwiftUI.

Anyone building a product with bdk-swift will have to write a certain amount of boiler plate code to get going.
Anything that we can do to reduce that, without sacrificing flexibility, could help new developers get up and running faster.
I am myself not completely convinced on the right way forward here, so this is mostly for discussion.

I see three potential approaches here:

  1. No extra convenience classes, methods or syntactic sugar in bdk-swift, but instead a great 'reference class' code example for working with bdk in SwiftUI
  2. A 'fat' convenience class that makes it REALLY easy, with minimal boiler plate for the developer (basically the reference class from 1, but built in)
  3. A 'minimal' convenience class that doesn't deviate much from normal bdk setup but provides optional helpers that almost everybody using SwiftUI will need

Having already built 2 as a separate package (bdkmanager-swift) I am now looking more into 3, or even 1.
This is to make less assumptions of every developer's needs, more flexibility etc.

What almost every developer needs to do:

  • Initialise a wallet
  • Sync
  • Keep balance and transactions up to date, and update UI
  • Send bitcoin

Proposal - A minimal, optional, convenience class
Here is an example of what a minimal approach like 3 could mean. An additional class in bdk-swift called BDKManager, WalletManager or similar.

This would be completely optional to use.
It would NOT cut down on setup boiler plate, but would provide sync and send code and automatic UI updates when balance and transactions update.

public class BDKManager: ObservableObject {
    @Published public var wallet: Wallet
    @Published public var balance: Balance?
    @Published public var transactions: [TransactionDetails]?

    private var blockchain: Blockchain

    // Sync the loaded wallet once
    public func sync() {
       ... (also updates Balance and Transactions)
    }

    // Send an amount of bitcoin (in sats) to a recipient, optional feeRate
    public func sendBitcoin(recipient: String, amount: UInt64, feeRate: Float) -> Bool {
       ...
    }
}

From my own experience so far, these are the core requirements that it would be useful to have out of the box.
Initial setup boiler plate can be taken care of with a good example instead of wrapping in fancy helpers.

For now I'm obviously doing all this outside of bdk-swift, but if there is interest in some integration in this direction I'm happy to help, and refine any kind of thinking here.

@thunderbiscuit
Copy link
Member

@danielnordh we have just merged the descriptor templates PR, which should help a lot with providing correct defaults for startup with keys and descriptors for the 3 most common use cases!

I'm also playing around with some of the extra things devs might want, and I'll be looking at your library. See #265 for extra details.

As discussed a bit on the Discord server, I do think that some of that boilerplate (like sending sync calls to background threads/coroutines) can only be done in the specific languages and could not be added to the bindings "directly", so that's the sort of thing I also want to take a look at. Feel free to open specific issues on my sugar library repo if you have ideas on what would be useful. In the meantime I'll see what's in BDKManager and pull some stuff out into Kotlin if I can.

@danielnordh
Copy link
Author

In the meantime I'll see what's in BDKManager and pull some stuff out into Kotlin if I can.

I have recently refactored BDKManager from a standalone package to a simpler class inside my wallet repo.
There isn't much there that is unnecessary anymore.

https://github.com/bdgwallet/dailywallet/blob/main/dailywallet/BDK/BDKManager.swift

@thunderbiscuit
Copy link
Member

Transferring my comment from #265:

To move the discussion forward on this, I have started a "sugar" library that would work on bdk-android and bdk-jvm. The repo is here.

At the moment it does 2 things but I'd love to add more.

  1. Adding a .sat and .btc values on the common Int, Long, Float, Double units to provide simple checks for values and allow to express them in either satoshis or bitcoin, while inlining the actual ULong value.
  2. Adding an infix function called before that allows comparison between two transactions and returns a boolean.

Examples:

// example 1
TxBuilder()
    .addRecipient(Address(faucetAddress).scriptPubkey(), 1000.sat)
    .feeRate(1.2f)
    .finish(wallet)

TxBuilder()
    .addRecipient(Address(faucetAddress).scriptPubkey(), 0.004.btc)
    .feeRate(1.2f)
    .finish(wallet)

// example 2
val txList = wallet.listTransactions()
val tx1: TransactionDetails = txList[0]
val tx2: TransactionDetails = txList[1]

if (tx1 before tx2) {
    println("tx1 is older than tx2")
}

@thunderbiscuit thunderbiscuit changed the title Should bdk-swift have syntactic sugar? Wrappers, helpers, and syntactic sugar on BDK Feb 3, 2023
@thunderbiscuit thunderbiscuit added the discussion Issue requires some discussion first label Feb 3, 2023
@thunderbiscuit
Copy link
Member

We recently merged a blog post about the scope and vision for the BDK bindings. I believe this will help clarify our intentions of what we plan to support and what will be left to the application layer or other libraries layer.

I will close this issue as it's gone stale over the past few months, and most of our feature requests have either been answered by enabling them at the bdk Rust layer (taproot descriptor templates for example) or explaining why we don't intend on widening the scope outside of the bdk/rust-bitcoin/miniscript API.

Thank you to everyone who pitched into this discussion over the past year! Lots of lessons learned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Issue requires some discussion first language: swift
Projects
Archived in project
Development

No branches or pull requests

3 participants