Allow configuration of a default rendezvous server for use with Sign in with QR

[hughns]

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

Here's what your changelog entry will look like:

✨ Features

• Allow configuration of a default rendezvous server for use with Sign in with QR (#11638). Contributed by @hughns.

[t3chguy]

Shouldn't this have a user opt-in like the default STUN server does? What about privacy/terms acceptance for GDPR/etc

[hughns]

Shouldn't this have a user opt-in like the default STUN server does? What about privacy/terms acceptance for GDPR/etc

The assumed consent model is that whomever deploys and operates a build of Element Web that makes use of this config option would need to ensure that their terms of service cover such a use case.

The immediate use case is where a homeserver operator is also providing the Element Web installation. Therefore, the appropriate consent is handled the same as if the rendezvous server is built-in to the homeserver. This is because the default_rz_server would only be used in Element Web after the user has signed in to the homeserver (and therefore accepted any terms).

As such, I don't believe an opt-in mechanism is needed at this time.

[t3chguy]

The assumed consent model is that whomever deploys and operates a build of Element Web that makes use of this config option would need to ensure that their terms of service cover such a use case.

But that isn't how other things work in the Element Web client. The person deploying Element Web chooses the HS and can even enforce it by use of https://github.com/vector-im/element-web/blob/develop/docs/config.md disable_custom_urls but the terms of the server will still be presented to the user.

Element Web running entirely on the user's device means it doesn't need its own privacy/terms, but as soon as you're reaching out to a server that changes.

This is because the default_rz_server would only be used in Element Web after the user has signed in to the homeserver (and therefore accepted any terms).

What protections are there to ensure the rz and hs are of the same operator? Given that HS can be changed (even if disable_custom_urls is specified) by use of a full MXID @bob:server_name on the login screen.

[t3chguy]

I think at the very least it'd need to be a map akin to enable_presence_by_hs_url given that an single RZ probably shouldn't be used for all HSes.

[hughns]

I think at the very least it'd need to be a map akin to enable_presence_by_hs_url given that an single RZ probably shouldn't be used for all HSes.

I will refactor to use this approach.

[t3chguy]

Such an approach is also considered tech debt and will likely need a chat with the WAT whether its appropriate for the record. Why isn't this done via a Synapse plugin or similar which listens to the RZ routes and advertises support via the versions/capabilities API?

[hughns]

Making draft as the feedback from the maintainer as that solution is unacceptable.

[Johennes]

Closing as we've aligned on pursuing #11655 instead.