Federated servers compatibility between Talk 19 and Talk 20

[danxuliu]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

From #12604

• Federated Talk 19 joins a room against Talk 20 host - ✔️
  • Federated participants would not be shown as active.
• Federated Talk 20 joins a room against Talk 19 host - ❔
  • TODO: This should be tested
• Federated Talk 20 gets signaling settings from a Talk 19 host - ❗
  • Moreover, the request would be throttled.
  • Maybe a new endpoint like settings/federation should be added to get the settings from the remote server, so in case a bad request is returned the federated server can know that the remote server is not Talk >= 20 and return federation settings?

[nickvergessen]

so in case a bad request is returned the federated server can know that the remote server is not Talk >= 20

We are fetching capabilities and could check for federation-v2?

[SystemKeeper]

In this regard, should federation-v2 be a local feature in the capabilities?

spreed/lib/Capabilities.php

Line 107 in 361a3fa

public const LOCAL_FEATURES = [

Currently it is not and when a room on 20 is added to 19, I get federation-v2 in the room capabilities.

[nickvergessen]

Arg, basically all federation-v* will have to be?

[SystemKeeper]

I think it depends a bit on the feature. If we will ever have a feature that only the remote server needs to support (and the clients), that would also be fine to have non-local? For federation-v2 I think it should be a local one, as we need local server support for calling.

[SystemKeeper]

I have been thinking about this a bit. The federation-v2 capability is a bit problematic, because we need to check both sides on the clients. It needs to be checked locally, that our server supports calling, but also remotely, that the remote server supports calling. We currently don't have a way of specifying that we need to check both sides. So, should this be purely decided in the clients? Or do we need an additional REMOTE_FEATURES array or something?