Federation support

[fancycode]

Needs nextcloud/spreed#12604

[coveralls]

Pull Request Test Coverage Report for Build 10263387860

Details

• 659 of 882 (74.72%) changed or added relevant lines in 6 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+1.0%) to 58.364%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
clientsession.go	25	32	78.13%
api_signaling.go	62	79	78.48%
hub.go	67	125	53.6%
federation.go	500	641	78.0%

Files with Coverage Reduction	New Missed Lines	%
room.go	1	84.29%
grpc_remote_client.go	2	75.57%

Totals
Change from base Build 10262210080:	1.0%
Covered Lines:	10495
Relevant Lines:	17982

---

💛 - Coveralls

[fancycode]

@danxuliu this is ready for merging from my side, could you please do a test with your Talk changes and see if everything is working as expected? Thanks!

[SystemKeeper]

I played around with it today, what I noticed:

• When I first join the signaling controller without federated information
• Then join the signaling controller with federated information (so still the same conversation)

The second join kills the first session on the Nextcloud server, so joining a call then fails, because I don't have an active session on the nextcloud server.
While I can see that it might be intended this way, it was totally unexpected to me. Is it intended or should the second join just "overwrite" the first one (without killing the session in Nextcloud?)?

The second thing I noticed, when I join the same room twice fast (this time both requests do have federated information attached), I sometimes got "no_such_room" back and only the second join worked.

[SystemKeeper]

• When I first join the signaling controller without federated information
• Then join the signaling controller with federated information (so still the same conversation)

The second join kills the first session on the Nextcloud server, so joining a call then fails, because I don't have an active session on the nextcloud server.

It seems unrelated to the fact with/without federated information, when I try to join the same server again, a leave is sent to the nextcloud instance and then my join request fails and I get brute-force protected on top. While I can work around some cases, we still can end up in the case where a duplicated join happens (that's why we added already_joined back then). Is there a chance to make that more resilient?

[fancycode]

@SystemKeeper duplicate federated join requests are now handled in 5d4efe8

[SystemKeeper]

@SystemKeeper duplicate federated join requests are now handled in 5d4efe8

Tested and works, thanks!

[fancycode]

The expiration honors any caching headers set (since #780) instead of using a hardcoded cache duration of one hour. The default is one minute if no caching headers are returned.

Could you please check the response when you query the capabilities manually?

curl -ik -H "OCS-ApiRequest: true" -H "Accept: application/json" https://server.domain.tld/ocs/v2.php/cloud/capabilities

Anyway, if something is not working correctly, please open a new issue as this is unrelated to the federation changes.

[fancycode]

@SystemKeeper FYI, rebased on latest master containing #783 in case you want to do some more testing.