Release FFI Integration #1

[DanGould]

Great to see PDK FFI come to life so quickly. Thanks for stepping up and leading this effort @BitcoinZavior. You dropped this 👑

Integration Candidates

The first integration candidates have both express desire for payjoin support and compatibility with the UniFFI approach in this repository.

I see Four.

1. SatSale (Python)

SatSale's payjoin request is headed by volunteers who have expressed willingness for this approach and to do the work. Like BTCPayServer, SatSale is already hosted behind a secure server and would be a great candidate for both sender and receiver integrations, but we could start with send since many integrations could make use of it.

@nickfarrow @kristapsk how does this sound?

2. Blixt (React Native)

Blixt has already begun to entertain payjoin integration tradeoffs. Because it's an LND node under the hood, the integration could borrow from nolooking which also deploys a payoin sender based on PDK.

Blixt runs in a mobile environment, so receiving payjoin is difficult until Serverless Payjoin lands. While blixt should in time support sending and receiving, a send-only initial rollout would be light work for PDK interface.

3. Zeus (React Native)

Payjoin is on the Zeus roadmap and users are calling for PDK integration. I think a Zeus integration would be similar very similar to Blixt or nolooking, at least for LND rpc. Zeus may also desire or require CLN support which would be a bit more work. Nolooking's abstractions were built with this discrepancy in mind, so it's mostly a difference in the glue code required to support CLN, too.

Again, receive support would be a heavy lift before Serverless Payjoin since Zeuis is in a mobile setting.

4. Electrum (Python)

Electrum has had a payjoin integration issue open since 2020. A PDK Electrum Plugin could be a good first step toward a more complete integration and would deliver payjoin capabilities to many tens of thousands of active users.

However, they have raised concerns with the fact that this is not "pure python" and there would need to be adependency audit. I think the latter is a surmountable challenge since these dependencies are for the most part shared by the biggest players in the space, like CashApp and we're choosing to build on a tried and tested XDK + UniFFI architechture. The former seems to be somewhat arbitrary and a matter of user demand more than anything, but I can understand it.

An Electrum plugin might be easy to develop but delivery may be more of a challenge than the first two. We'll see.

API to Expose

The majority of the send module, Uri and PjUri validation should be exposed in order to support these first integrations. Downstream implementations may have their own Psbt types, so PSBT parameters passed via byte vector or string according to BIP 174 spec may be more appropriate interfaces than a bound Rust type.

A reference implementation in production supports sending from this API (see original PR) but is still beta and will have changes. In particular, sender fee parameterization is a work-in-progress.

Ultimately the send API works as-is while ergonomic changes continue to be developed.

More Languages: WASM, C, C# and beyond

Stable language bindings on the same high level FFI deinition are in demand for projects outside of those covered by UniFFI

@michael1011 expresses desire for a shared TypeScript interface bound to wasm. Perhaps that could be supported by wasm_bindgen and a shared TypeScript definition used by both wasm & react native. Nunchuk would be able to use C bindings. Wasabi has expressed desire to support payjoin receipt on a number of occasions and may consider PDK if C# UniFFI bindings were available .

@BitcoinZavior how do these languages fit into he bigger picture of language bindings for PDK? What resources can they share with this repository, and what needs to stay separate?

[BitcoinZavior]

Thanks @DanGould for the detailed background

The UniFFi interface will enable the building of language bindings for Kotlin, Swift and Python. Kotlin language bindings can then be used to create native binaries for native Android app development. Similarly, Swift will be used to create native binaries for native iOS app development.
UniFFi wrapper will also enable building language bindings for Python which can be used for Python application development.
The Android and iOS binaries will also be used to create a React Native package by adding a RN wrapper.
The UiFFi interface will also be used to create Dart wrapper which will help in creating a Flutter package using Flutter Rust Bridge.

The below schematic shows the process that will be followed:

1. and 4. SatSale and Electrum should be able to use the Python bindings when they are created.

2. and 3. Blixt and Zeus will need to wait for the React Native package to be created. Or they can also use the Android and Swift bindings to add an RN wrapper in Blixt and Zeus. Another option is that Zeus and Blixt help and contribute to building the RN package, this will reduce the time to create the package and also help both Zeus and Blixt reduce the effort that would be required to use the native binaries.

I understand this doesn't address all the questions in the issue, but I will get to it shortly 👍

[kristapsk]

1. SatSale (Python)

SatSale's payjoin request is headed by volunteers who have expressed willingness for this approach and to do the work. Like BTCPayServer, SatSale is already hosted behind a secure server and would be a great candidate for both sender and receiver integrations, but we could start with send since many integrations could make use of it.

@nickfarrow @kristapsk how does this sound?

This could probably be a way for SatSale to integrate payjoin.

Note that only receiving support is needed, as SatSale does not have sending functionality itself, you receive bitcoins directly to your Bitcoin Core wallet, which you then use for sending (there is also xpub mode using mempool.space, but that's watch-only and payjoin will not work with that).

[DanGould]

LNBits might also be a good python candidate. Every voltage node ships with LNBits.

[BullishNode]

Bull Bitcoin wallet is candidate for integration via Flutter.

[BitcoinZavior]

Splendid news regarding Bull Bitcoin, indeed!
Flutter is most certainly in our plans, and we shall give it due consideration following Python. 👍