The bitcoind method of payjoin-cli's App trait uses the values in AppConfig and returns a bitcoin rpc client handle, which the other trait methods use.
This issue is mainly to document some WIP that is currently on hold as per call yesterday, so that we don't forget it.
This is suboptimal:
- due to the reliance on
AppConfig, which once payjoin-cli has additive features would actually be two distinct types (but for this purpose duck typing equivalent), no default implementation is given in the trait which results in duplication
- the RPC api is low level for this purpose, which makes it hard to read and compare the v1 and v2 implementations of the
App trait
A new struct that wraps the RPC API, and provides methods tailored for payjoin (e.g. all of the details to generate an address, handle the psbt workflow and serialization) would improve (2).
I don't yet have a clean solution for (1). Extracting the bitcoin specific config data from AppConfig into a shared BitcoinConfig type for example seems like it'd be the cleanest approach to reduce that duplication but this would either break the serialization compatibility or introduce a bunch of boilerplate for backwards compatibility. I suspect backwards incompatibility is justified in this case, since the main purpose of payjoin cli is as a reference implementation, i.e. it should prioritize readability.
The
bitcoindmethod of payjoin-cli'sApptrait uses the values inAppConfigand returns a bitcoin rpc client handle, which the other trait methods use.This issue is mainly to document some WIP that is currently on hold as per call yesterday, so that we don't forget it.
This is suboptimal:
AppConfig, which once payjoin-cli has additive features would actually be two distinct types (but for this purpose duck typing equivalent), no default implementation is given in the trait which results in duplicationApptraitA new struct that wraps the RPC API, and provides methods tailored for payjoin (e.g. all of the details to generate an address, handle the psbt workflow and serialization) would improve (2).
I don't yet have a clean solution for (1). Extracting the bitcoin specific config data from
AppConfiginto a sharedBitcoinConfigtype for example seems like it'd be the cleanest approach to reduce that duplication but this would either break the serialization compatibility or introduce a bunch of boilerplate for backwards compatibility. I suspect backwards incompatibility is justified in this case, since the main purpose of payjoin cli is as a reference implementation, i.e. it should prioritize readability.