Federated servers compatibility between Talk 19 and Talk 20

nextcloud / spreed

🗨️ Nextcloud Talk – chat, video & audio calls for Nextcloud

https://nextcloud.com/talk

GNU Affero General Public License v3.0

1.6k stars 428 forks source link

Federated servers compatibility between Talk 19 and Talk 20 #12805

Open danxuliu opened 1 month ago

danxuliu commented 1 month ago

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 - :heavy_check_mark:
- Federated participants would not be shown as active.
Federated Talk 20 joins a room against Talk 19 host - :grey_question:
- TODO: This should be tested
Federated Talk 20 gets signaling settings from a Talk 19 host - :exclamation:
- 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 commented 1 month ago

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 commented 1 month ago

In this regard, should federation-v2 be a local feature in the capabilities? https://github.com/nextcloud/spreed/blob/361a3fa2d8a6a3a172593dc6da1c20d0e64b5e0b/lib/Capabilities.php#L107

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

nickvergessen commented 1 month ago

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

SystemKeeper commented 1 month ago

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 commented 1 month ago

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?