This is awesome, thank you @DanGould. Obviously we'd love to have BIP78 in Envoy.

I think it makes sense to have payjoin in a separate (Dart) package/(Rust) crate combo, especially cause, from a UI perspective, I think this is a two step process that can be separate from wallet.

1. After scanning the BIP21 we'd use the payjoin "bindings" to payjoin::Uri::try_from() and, if we have a winner, surface some info about the payjoin to the user.
   Some stuff needs to be handled: like if the PJ server is an .onion address and we're not connected to Tor we can offer the user the option to enable it (maybe just for this payment?)
2. If the user decides to PJ we'd use use payjoin to fetch the PSBT. We'd pass the Tor proxy address if need be and probably talk to the server with something blocking from http_tor (it uses reqwest internally)

We can get away with blocking in Rust cause a payjoin can be instantiated in a separate Dart isolate (threads basically).

FWIW I think UI and "backend" work here can be totally decoupled.

I see an error_return Psbt dummy used for data transport. Is this for the c bindings? Production code should obviously not panic like this PoC does.

On the FFI boundary instead of panicking we return some sentinel value (not very Rusty but it's FFI). We check for that value on Dart side and handle it in the UI. We also use last_error_message which is a string representation of the Rust error.

Assigned