[👣 TRACKING] 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.

Tracking Sequence

• Don't copy URI path & query to gateway request ohttp-relay#46
• RFC 9540 directory and receiver #549
• Opt-in to traffic from arbitrary relays in directory #569
• Implement RFC 9540 ohttp-relay#47
• Gateway opt in mechanism ohttp-relay#58
• Specify OHTTP gateway for opt-in respecting ohttp-relay #570
• specify the allowed_purposes opt in mechanism both
  • in isolation and
  • in BIP 77
• update payjoin-test-services/Cargo.toml after ohttp-relay release
  • Bump 0.0.10 ohttp-relay#64
• Update payjoin-directory
• instruct ohttp relay runners to updates

[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.

[DanGould]

a struct Directory(Url) would have what methods on it exactly? Some way to get the base path and .well-known/ohttp-gateway path for some requests?

[nothingmuch]

a struct Directory(Url) would have what methods on it exactly? Some way to get the base path and .well-known/ohttp-gateway path for some requests?

Forgot to reply, that evolved into payjoin/ohttp-relay#53 in the end

[DanGould]

Released in payjoin 0.23.0