🌏 Federated Conversations Overview

[gary-kim]

See 🌏 Testing federation while there is no frontend yet for testing steps

Progress on implementing federated Nextcloud Talk rooms.

This implementation will have each room on a single server so each participating server will only communicate with the server hosting the room (This does mean that the room will be inaccessible regardless of the server the user is on if the server hosting the room is not available).

Required

• API compatibility checker
  • Capability handling [RFC] Capability handling in federated conversations #10680
  • Publish OCM resource feat(federation): Register the OCM resource #10692
• Remote message access API
• Remote message send API
• Remote user list + presence API
• Remote API authentication
• Add messages from other instances in the client receive messages API
• Send messages to instance hosting the room
• Remote call attendance
  • Remote signaling
  • Remote Talk configuration info
  • Handling CSP issues
• Keeping track of remote servers (current through is to use server_url but how to handle if that changes?) Implement Recieving Room Shares #5775
• Request join system?
• Remote moderators?
• Token shares (for various ROS shares)
  • Probably public link shares at first. Can add proxying through remote server later.
• Sending Shares Implement Recieving Room Shares #5775
• Receiving Shares Add sending room shares support #6105
• Validation by remoteAttendeeId + accessToken might be ambiguous, maybe we should keep the invites in the DB with an accepted flag and add the remoteServer there? Fix "Validation by remoteAttendeeId + accessToken might be ambiguous" #10766
• Send sendRemoteUnShare when removing participant fix(federation): Send disinvite on remote user removal and remove invite #11464
• Federation is not checking if the target user is allowed to use talk

Integration tests

• Test that it doesn't work when federation is not enabled
• Test remote participant is added to participant list
• Test invite is sent
• Test accepting an invite (any change for the inviter?)
• Test declining an invite (is the remote participant removed?)
• Test requesting the room as a remote participant
• Test if remote participants can see the participant list

Bugs

• Database has unique index on token which needs to be extended to token+server_url

@nickvergessen

[nickvergessen]

Remote message send API

I guess we use this for it:
https://github.com/nextcloud/server/blob/cb057829f72c70e819f456edfadbb29d72dba832/apps/cloud_federation_api/appinfo/routes.php#L35-L40

Remote API authentication

We introduced "pins" for users recently for SIP calling. It's a string field 32 chars long. Maybe we can use that? Ah would prevent them from having a phone pin later on. So I guess we need a new field.

Add messages from other instances in the client receive messages API

Since messages are pulled on a per room basis this should also be done on the source instance

Handling CSP issues

We could just reload the page when opening such a conversation as an easy workaround. The big issue is not the remote server, we could loop over the conversations of the user. But the STUN/TURN/HPB as well which are needed for remote calls.

Federated Room ID. Probably (@token@cloud.example.com)

That would conflict with the federated cloud ids of users. But do we need it for now?

[nickvergessen]

Request join system?

I guess we just use OCM for that too. The big question is if we want to have to accept users. Could also say room is either public or not. If it is people can add themselves, if not they can't.
"Open conversations" are not supported for now I guess 👯

[gary-kim]

That would conflict with the federated cloud ids of users. But do we need it for now?

Trying to figure out how to identify remote rooms in the database (the federated cloud IDs for users would also be useful for identifying each user in the room). Maybe we could use #token@cloud.example.com to avoid the conflict?

[nickvergessen]

Well so the only place where the remote info would be needed is the rooms table and there we could just add a column server_url or something. everything else works based on the integer room id from that table 🤔

[gary-kim]

Sounds fine. There's other places like how to make the room URL for remote rooms but that does not have to be easily readable so.

[nickvergessen]

• Database has unique index on token which needs to be extended to token+server_url

[nickvergessen]

Database has unique index on token which needs to be extended to token+server_url

Actually that might not even work, as the token also needs to be in the URL and be unique there.
So maybe we have to store the room with a different local token which then is still unique and basically you get the remote_url and remote_token from the API and if that is there (or the type reflects it) you use that to communicate with the remote server, but locally you always interact with the local token.