Audit network disruption recovery experience

[DanGould]

Network disruption results in a brittle experience, but it doesn't have to. There can be sufficient backup directory, ohttp-relay servers so that client code can fall back seamlessly.

Ensure that client code is working and, ideally, tested in our reference. We must demonstrate for downstream implementations how to ship a delightful experience.

Tangential to this issue [#1005, #968], I also wonder if implementers could parallelize requests to multiple ohttp relays instead of trying them sequentially, and process whatever response returns first.

Originally posted by @spacebear21 in #1005 (comment)

if the [http] client should later be cached or re-used so that it can get a performance edge or if that only makes sense for custom clients and not the one we ship with io

Originally posted by @DanGould in #1005 (comment)

[0xZaddyy]

@DanGould i'm picking this up.. :)

[zealsham]

Network disruption results in a brittle experience, but it doesn't have to. There can be sufficient backup directory, ohttp-relay servers so that client code can fall back seamlessly.

@DanGould a little confused on how this is supposed to work for the directory, for the relay part, it is pretty straight forward as implemented by #1294 , however for the directory how does this work. The directory of choice is set by the receiver during the generation of the payjoin url and except will allow the payjoin url to have mutiple directories in the payjoin-url i don't see how the fallback will work

[DanGould]

The receiver may be able to choose from multiple directories. The sender has no such luck. correct.