payjoin/rust-payjoin

Which crate is this issue for? No response Motivation The v1 roundtrip fuzz target creates a sender context at fuzz/fuzz_targets/roundtrip/v1.rs:119: let (request, v1_ctx) = sender.create_v1_post_request(); After producing a receiver proposal, it passes the proposal back to that sender context at fuzz/fuzz_targets/roundtrip/v1.rs:149: let _ = v1_ctx.process_response(&proposal.psbt().serialize()); This directly calls V1Context::process_response, defined at payjoin/src/core/send/v1.rs:209. Lines 214-216 contain the relevant parsing and validation path: let res_str = std::str::from_utf8(response).map_err(|_| InternalValidationError::Parse)?; let proposal = Psbt::from_str(res_str).map_err(|_| ResponseError::parse(res_str))?; self.psbt_context.process_proposal(proposal).map_err(Into::into) The method: Parses the response as UTF-8 at line 214. Parses the resulting string as a base64 PSBT at line 215. Calls sender-side process_proposal at line 216. Psbt::serialize() returns raw binary PSBT

From some post merge discussion I don't want to get lost. #1295 (comment) I think it would be helpful to come to a consensus on how we want to organize and document our gitignore. Though not mission critical I think a well organized gitignore can sometimes be helpful to make sense of all the generated files strewn about in a large repo. Here are the docs in case there is some useful knowledge to be gleaned from there https://git-scm.com/docs/gitignore Some things to consider. Should we have one large gitignore separated in blocks for each workspace or should each workspace have its own gitignore? How much documentation should we expect to explain why some files are ignored?

Which crate is this feature request for? ohttp-relay, payjoin-cli Please describe the feature you'd like to see added. While well-known, the reqwest HTTP client unfortunately has a huge dependency tree that makes it not a great fit for security critical applications such as Bitcoin-related programs. To this end, the rust-bitcoin ecosystem had a while back discussed to maintain a shared, saner, HTTP async-compatible client library and by now it is released in the form of bitreq (see also https://github.com/rust-bitcoin/corepc/tree/master/bitreq). Quite a few projects are now committed to making the switch ASAP (us at LDK are currently switching over everything, bitcoin-payment-instruction has made the switch already, there are open issues/PRs for BDK, etc). Reports from the libraries making the switch speak for themselves, for example, Breez SDK recently reported that dropping reqwest resulted in ~120 fewer transient dependencies and ~5m less binary size. It would be great if this lib