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.

Sign up for GitHub

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

Jump to bottom

Send payjoin #84

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Send payjoin #84

wants to merge 1 commit into from

Conversation

DanGould
Copy link

@DanGould DanGould commented Feb 3, 2023

Draft logic for sending payjoin. This is NOT a complete design by any means, just a PoC draft to start a conversation and demonstrate the parameters of an integration.

@icota how feasible does payjoin seem too pursue?

Regarding the design

First, create_payjoin makes an http request which should proxy through http_tor. Payjoin endpoints are often .onion services. Should payjoin functions rather be exposed to a Dart file which then consumes the logic to create the request? native wallet ffi should probably not have a reqwest dependency.

Second, errors are handled with panics here. 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.

I'm curious too hear any feedback you may have

@icota icota closed this Feb 6, 2023
@icota icota reopened this Feb 6, 2023
@icota
Copy link
Collaborator

icota commented Feb 6, 2023 •
edited

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).

@icota icota linked an issue Feb 6, 2023 that may be closed by this pull request
Send Payjoin #83
Open
@icota
Copy link
Collaborator

icota commented Feb 6, 2023 •
edited

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Send Payjoin
2 participants
@DanGould @icota