Yuval Kogman

> How should we be handling the case of a URI containing both `pj` _and_ `req-pj`? Should we add another variant to `InternalPjParseError` similar to `InternalPjParseError::DuplicateParams`? Hmm, on the one...

That would still raise an error, which would need to be mapped to the `InternalPjParseError`, so I think the question stands. In the current API this would be handled as...

> but I think sorting out how to handle that should be done in `rust-payjoin` Not sure I agree, the API already assumes parameters are deserialized into a struct, i.e....

I believe these additional strings are appropriate, both in general (domain separators considered a good practice) and in particular, because although this might be superfluous in BIP 77 due to...

Yes, again both in general and in particular, especially now that both messages appear in the same namespace (i.e. the directory is a key value store where short IDs are...

fwiw the `ser` and `de` modules are `pub mod`, so they are part of the public API. if the deserialization impl was generalized from `Uri` to a pub trait that...

- PUT for v1 backwards compatible replies is not described but should be. - #1025 - HTTP status codes

- `req-pj` - in spec but not implemented - `&pjv2=` (receiver opt out of bip 78 compatibility)

in some cases i also saw a reset by peer instead of the error leaking, which is even worse as that borgs the error

No, but those PR get us closer to fixing this. The `BadRequest` variant of `HandlerError` fortunately does not send the internal `anyhow::Error` in the body, so this is not a...