payjoin
Document and reference best practice for OHTTP Relay selection
Our payjoin-cli implementation only uses one OHTTP Relay by configuration, and BullBitcoin Mobile selects one from those available at random
However, if a request fails due to an unresponsive OHTTP Relay, we've delivered no mechanism to retry on another relay. We ought to build this into payjoin-cli so that downstream implementations have a good idea of what they need to build for reliability and to preserve privacy.
interesting !, so we plan to create a list of relays and if one fails we will retry for the other relays, am I missing something ? and do we need to document the approach first or should get started with it ?
Yes @Gmin2 this is exactly the problem.
We desperately need a strategy there for reliability. Even if there are multiple relays, if there's no strategy to handle connection failure and move on to the next it doesn't really matter. This problem arose when pj.bobspacebkk.com did maintenance early in the week.
We need a reference implementation in payjoin-cli to demonstrate best practices, can just get started.
I think this would look like:
- payjoin-cli accepts a list of
ohttp_relays in config, instead of a single relay. - Whenever payjoin-cli sender/receiver makes a request, pick one ohttp_relay from the provided list at random to post the OHTTP payload
- If a connection error occurs from the HTTP request that isn't a status code, try another relay from the list
- If the request fails with all provided relays there's likely something else wrong so error and exit
- (optional) provide a default list of ohttp_relays with all currently known/trusted relays?
