refactor(iroh-relay)!: Remove relay_endpoint config option & rename /derp route to /relay

[matheus23]

Description

• Removes relay_endpoint config option from ServerBuilder
• Makes iroh-relay accept both /derp and /relay as paths for relaying
• Makes /relay the default path used in the iroh-net client

TODO:

• Test both URLs

Breaking Changes

• iroh_net::relay::http::ServerBuilder: Removed relay_endpoint function

Notes & open questions

Closes #2378

✅ Merge this after #2387

Change checklist

• Self-review.
• Documentation updates if relevant.
• Tests if relevant.
• All breaking changes documented.

[dignifiedquire]

any chance we can have a small test, to make sure both urls work?

[matheus23]

Yes! Had that planned but forgot about it?

I remember looking into it, probably means I'll need to make the URL it dials configurable in the code - possibly passing it in at the ClientBuilder level or so.

Which also reminds me: Would it make sense to include the /relay bit in the RelayUrl? I.e. a relay URL would be e.g. something like ws://relay.iroh.net/relay instead of ws://relay.iroh.net.

[dignifiedquire]

Which also reminds me: Would it make sense to include the /relay bit in the RelayUrl? I.e. a relay URL would be e.g. something like ws://relay.iroh.net/relay instead of ws://relay.iroh.net.

I think this would actually be really good, as it would allow more interesting deployments setups

[dignifiedquire]

actually though, I am not sure, as we hit other endpoints on a relay server, so that URL would be somewhat confusing

cc @ramfox @flub for some thoughts

[matheus23]

Let's continue the discussion here.
However, if it turns out we'll want to do this - I'll create an issue ✌️

[flub]

actually though, I am not sure, as we hit other endpoints on a relay server, so that URL would be somewhat confusing

cc @ramfox @flub for some thoughts

Yeah, I think RelayUrl should be a "root" under which we expect to find several paths. E.g. the client code does relay_url.join("derp"), relay_url.join("generate_204") etc. So if someone is using https://example.com/some/path/ I expect them to have done some reverse-proxy stuff to host it all under a path prefix. Does that make sense?

So I would not put the /relay or /derp into the RelayUrl.

[flub]

LGTM but I wonder if this should be split up in two PRs: the server-side and switching the client. We need to be pretty sure that we have deployed the new relay server before we release with the client switched. I'd even do them in two subsequent releases. /cc @Arqu

[matheus23]

I wonder if this should be split up in two PRs: the server-side and switching the client

Good idea. Probably not hard to do.
That'd also test that the "new" relay works with the old code (at least it'd test that for a week).

[matheus23]

I split out #2441

[flub]

So this is just bikesheeding, but nesting /relay/probe is a bit odd, given the other handlers are all on the root (I appreciate this was copied from tailscale). I'd move this to /probe so it is on the same level as /generate_204 etc. We can definitely do this for the new route. We can even remove /derp/probe if we want as it's not yet used (hi https-probe that still lives in a half-dead branch 😓 ).

[matheus23]

I'll keep it in this PR as a refactor instead of a change - let's talk about moving it when we're making use of it :)