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

Expose Interface for FFI #44

Closed
DanGould opened this issue Mar 31, 2023 · 4 comments
Closed

Expose Interface for FFI #44

DanGould opened this issue Mar 31, 2023 · 4 comments
Labels

Comments

@DanGould
Copy link
Contributor

DanGould commented Mar 31, 2023

pure functions which take bytes as arguments and return bytes are simple to bind to. Right now we use rust typestate which is easy to reason about but hard to bind to. Perhaps static functions could be exposed as a feature, and the typestate could be built off of the static functions to make this library easy to consume downstream.


The BDK approach to FFI is documented here https://hackmd.io/@bdk/bindings-everywhere

After talking to @thunderbiscuit, it sounds like UniFFI handles callback interfaces without too much problem. They don't necessarily need to be static. The biggest bindings want with that approach is to support WASM bindings (like this example) in combination with the bitcoin-frontier demonstratedg mobile/python UniFFI bindings.

see: LtbLightning/payjoin-ffi#1

@DanGould DanGould moved this to Todo in Payjoin Roadmap 📝 Apr 2, 2023
@DanGould DanGould changed the title Static Function Interface for FFI Expose Interface for FFI May 10, 2023
@DanGould
Copy link
Contributor Author

@Kixunil had a comment on this topic over email

Are you doing FFI within the same crate? Cause I think it's better to have a separate wrapper crate for that so that pure rust code doesn't need to pull in C compiler and other garbage.

This idea sounds right to me. Plainly I'm not sure what the best way to go about this is because I have not exposed rust via FFI before.

@Kixunil
Copy link
Contributor

Kixunil commented May 10, 2023

My last project actually had WASM bindings so I have a fresh experience. :)

What I ended up doing is to wrap the types used by the internal Rust library in a higher-level API that is easier to use from JS. E.g:

#[wasm_bindgen]
pub struct Invoice(bip21::Uri /* checked, no extras */);

#[wasm_bindgen]
impl Invoice {
    pub fn link(&self) -> String {
        self.0.to_string()
    }

    pub fn qr_code_data(&self) -> String {
        format!("{:#}", self.0)
    }
}

@thunderbiscuit
Copy link

I agree with the sentiment that binding should live in separate repositories. There is a fair amount of wrapping that often needs to take place no matter what technique/tool is used. Easier to treat the Rust library as an internal implementation detail of the bindings lib.

@DanGould DanGould moved this from Todo to In Progress in Payjoin Roadmap 📝 Jul 27, 2023
@DanGould DanGould added the ffi label Jul 31, 2023
@DanGould
Copy link
Contributor Author

@BitcoinZavior now that https://github.com/LtbLightning/payjoin-ffi exists, is this issue closed?

@DanGould DanGould closed this as completed Mar 7, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in Payjoin Roadmap 📝 Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

No branches or pull requests

3 participants