🌏 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 (@[email protected])

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 #[email protected] 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.

[gary-kim]

Does modifying the receiveMessages endpoint for allowing remote servers to receive messages sound okay? I think it will be better than creating a separate API since most of the code/functionality is shared anyways.

[nickvergessen]

What do you mean?

[gary-kim]

So when someone on a remote server tries to read their messages, the user's server will send a request to the server hosting the chat to the same API as used by clients normally but with the shared secret. Then the server hosting the chat can use that to authenticate and send back messages in the same format it sends it to clients.

spreed/lib/Controller/ChatController.php

Line 383 in b5fa5cf

public function receiveMessages(int $lookIntoFuture,

I will go ahead and implement it. Can also discuss further in the PR.

[nickvergessen]

No we are not proxing the messages. The clients will directly contact the remote server and ask for the messages.

Also there is currently an open PR about federation which should be the next bit we work on:
#6663

[nickvergessen]

More steps in #7464

[nickvergessen]

Common flow

User/Server	Action	PR
UserA	Creates ConversationA	☑️
UserA	Invites remote user UserB@ServerB	☑️
ServerA	Sends OCM share to ServerB	☑️
ServerA	Shows invitation as system message	☑️
ServerB	Shows notification to UserB	#7464
UserB	Sees invitation	#7464

Accept

User/Server	Action	PR
UserB	Accepts invitation	#7464
ServerB	Sends OCM response to ServerA	☑️
UserA	Sees in the ChatA that UserB@ServerB accepted	#7464

Decline

User/Server	Action	PR
UserB	Declines invitation	#7464
ServerB	Sends OCM response to ServerA	☑️
UserA	Sees in the ChatA that UserB@ServerB declined	#7464
UserA	UserB@ServerB is removed from the participant list	☑️

[nickvergessen]

• Remote rooms with pending invites are deleted as there is no attendee in the database table when background jobs run

[nickvergessen]

Mostly done, so closing this overview

[Thatoo]

Does that mean this issue could be closed #21 or it's a different issue?

[nickvergessen]

It's one step towards it