When is the next release of this coming out Kix? Is there anything you need help with to get it done?

While I did implement the most important things it's possible I missed something so a deep review would be helpful. Especially from someone independent.

We could and probably should derive/implement more things:

• Clone for Uri
• rewrite derive on Param to print string or bytes (hex encoded?)
• Probably also (Partial)Eq and Hash

Is there some technical reason why bip21 does not use thiserror? If the docs for thiserror are correct then the derived code should be the same (I have not looked at the generated code myself though).

Thiserror deliberately does not appear in your public API. You get the same thing as if you had written an implementation of std::error::Error by hand, and switching from handwritten impls to thiserror or vice versa is not a breaking change.

I'm interested to understand you reasoning.

Thanks

For now can look at @DanGould's

https://github.com/chaincase-app/payjoin/blob/master/payjoin/src/uri.rs

See rust-bitcoin/rust-bitcoin#1843

This crate also upper-cases BITCOIN:, should lower it.

Modern use of bip21 depends on an unbounded and undefined list of additional parameters beyond those defined by the bip21 spec and implemented in this crate. Supporting and maintaining them all is an increasingly difficult task.

Take MutinyWallet's Waila BIP21 decoder for example. It supports lightning, b12 (bolt12), pj, and pjos (both for Payjoin) parameters. However, there is now demand for sp and ohttp parameters in order to support Silent Payments and Payjoin V2 respectively. Who knows what will come next?

I'm thinking about how to combine distinct Uri parameter Extras without re-implementing each combination decoder from scratch for each combination. Waila doesn't take advantage of downstream dependencies, like the payjoin crate's bip21 parameter PayjoinExtras de/encoder for pj, pjos, and ohttp parameters. Instead, it duplicates source code that needs to be maintained independently. Wouldn't it be nice to depend on the existing, tested implementation inside of a shared decoder instead of duplicating source?

I long for a solution where de/encode logic lives in respective dependency crates and is composable downstream. I want to pull an off-the-shelf decoder like waila that I know handles most everything with tested production dependencies, or otherwise compose those dependencies to address application-specific needs.

It would be even better if, once Extras were composed, a generic bip21::UriBuilder could help me serialize a BIP21 supporting all of the parameters composed in Extras.

I have no proposed solution yet. The first step is to write down the problem to see if anyone else shares it.