Repository navigation
Audit network disruption recovery experience #1007
Description
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)
Activity
0xZaddyy commentedon Jan 22, 2026
@DanGould i'm picking this up.. :)
zealsham commentedon Jan 23, 2026
@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 commentedon Jan 23, 2026
The receiver may be able to choose from multiple directories. The sender has no such luck. correct.