Call recordings are attributed to "remote account" in the Files activity stream

[bakiburakogun]

Describe the bug

Every call recording that is stored by the recording backend shows up in the Files activity stream as created by "remote account" instead of the participant who started the recording:

"remote account" created Recording 2026-08-23 23-23-09.mp4

The file itself lands in the correct user's Talk recording folder and the record_file_stored notification reaches the correct user, so only the attribution is wrong. Federation is not involved here, there are no trusted servers configured on this instance.

Root cause

The recording backend uploads the file to POST /ocs/v2.php/apps/spreed/api/v1/recording/{token}/store, which is a #[PublicPage] endpoint authenticated only by the recording shared secret (RecordingController::validateBackendRequest()), so there is no active user during the request.

RecordingService::store() then writes the file with $recordingFolder->newFile(), which triggers the OC_Filesystem::post_create hook. OCA\Activity\CurrentUser::getUserIdentifier() finds no session user, no share token and no X-NC-Nickname header, and falls back to an empty string. OCA\Activity\FilesHooks::addNotificationsForFileAction() therefore uses the created_by subject with an empty actor, and OCA\Files\Activity\Provider replaces the empty {user} placeholder with "remote account":

https://github.com/nextcloud/activity/blob/master/lib/CurrentUser.php (fallback to '')
https://github.com/nextcloud/server/blob/master/apps/files/lib/Activity/Provider.php (// External user via public link share branch)

The same applies to the transcript and summary files written in RecordingService::storeTranscript().

Steps to reproduce

1. Set up the High Performance Backend and the recording server, enable call recording.
2. Start a call, record it and stop the recording.
3. Open Activity (or the Activity tab of the recording file) as the user who started the recording.

Expected behaviour

The activity entry names the user the recording belongs to, like any other file that user creates.

Actual behaviour

The activity entry says "remote account" created Recording ....mp4.

Server configuration

• Nextcloud: 34.0.3
• Talk: 24.0.4
• Recording backend: nextcloud-talk-recording 0.2.1
• Signaling: nextcloud-spreed-signaling 2.1.1 (4 node cluster, Debian 12)
• Web/application servers: Oracle Linux 9, PHP 8.4, PostgreSQL

Additional information

I have a fix that sets the owner as active user while the file is written and restores the previous user afterwards. Pull request is linked below.

[nickvergessen]

That's unintentional yeah. To be honest, I never saw the activity of a recording to begin with :D

[bakiburakogun]

Sorry for leaving this so long without an answer.

The short status is that it needed a change outside Talk, which is why it went quiet.

The attribution cannot be fixed in the recording service alone. OCA\Activity\CurrentUser::getUID() reads the user from the session, and there is no session during the store request, so whatever Talk does with the actor never reaches the activity entry. OC\Activity\Manager already honours IManager::setCurrentUserId(); the activity app simply never asked it. That is nextcloud/activity#2889, which is approved and whose database test matrix is green.

The Talk side is #19078. It was reworked on 29 August after the review there: no more touching IUserSession, it sets the actor through the activity manager around the operations that create nodes, and restores it in a finally. Until #2889 lands that call is a no-op, so the pull request is deliberately sitting behind it rather than waiting on anything from your side.

One correction to my own report while I am here: the last line of the description above says the fix "sets the owner as active user while the file is written and restores the previous user afterwards". That was the first attempt and it is no longer what the pull request does — the session swap was the wrong tool, as the review pointed out.

And one thing that will still be wrong after both land, so it does not come as a surprise later. On the chunked upload path the file is written by the recording backend through the public share created in requestUpload(), in a request Talk takes no part in, so nothing set in this process can reach it. What #19078 covers there is the recording folder, which is created by Talk and was also unattributed — that is the part that produced the "remote account" created Recording ....mp4 and <token> line for the first recording in a conversation. The uploaded file itself would need the public-share upload to be handled separately, which felt like its own change rather than something to attach to this one.

Nothing needed here, I just did not want to leave your comment sitting unanswered for another two weeks.