Specify OHTTP relay <-> directory opt-in mechanism

[nothingmuch]

Instead of having relays maintain a list of directories they are authorized to relay for, directories could opt in via a TXT record or a .well-known/ URI.

This relaxes the anti-DoS semantics of OHTTP (where the concern is a malicious client getting a relay to DoS random servers on the open internet) from per-endpoint opt-in to per-protocol opt-in, which seems appropriate in this context.

Upon receiving an OHTTP request, a payjoin specific OHTTP relay would first check that the host is opting in to receiving OHTTP requests from such relays for the purpose of facilitating payjoin transactions.

[DanGould]

We must write the OHTTP mailing list with any solution we come up with in case others might be interested.

[DanGould]

Is there any difference beetwen the TXT record approach and the .well-known/ URI approach with regard to discrimination based on the source of the request? It seems like it would be easier to discriminate based on e.g. an request's IP address at a .well-known/ URI, but only because I have a limited understanding of getting a TXT request from your own DNS registry

[nothingmuch]

Hmm, still mulling this over. Technically yes, as depending on whether or not a relay uses a recursive resolver to obtain the TXT record, whereas to delegate fetching over HTTP i suppose a relay could use another relay.

But i'm still struggling to figure out why this would really matter? Is the scenario under consideration a directory forcing clients to only use specific relays assuming other honest relays would self censor based? Since this is about protecting the relay directory from honest but cooptable relays, I just don't really see the concern, as the directory could just drop, corrupt or reject requests from specific relays and be even more disruptive that way, and a malicious relay could ignore this stuff.

[nothingmuch]

https://github.com/orgs/payjoin/discussions/486

[nothingmuch]

RFC 9540 specifies the gateway be at /.well-known/ohttp-gateway. Until now this was just /, so the directory URI was treated as both the base URI and the HTTP gateway.

This raises the question of the degree to which the payjoin crate should be involved in this, since it's somewhat agnostic to the mechanics of sending the encapsulated request, in my current approach to dealing with this I was mostly ignoring this question, but today it came up in our call.

The best idea I have for this is introducing a struct Directory(Url) with convenience methods, and utilizing that both for this purpose, and for the purpose of constructing the subdirectory URIs.