Files and Photos in Federated Chat

[TamimWahage]

Summary

Enable users in federated Talk conversations to share files and photos across Nextcloud instances with the same experience they have in local (non-federated) conversations.

Motivation / Problem Statement

Nextcloud Talk federation allows users on different instances to communicate in shared rooms. However, sharing files or photos in these conversations is currently not supported. This is a significant gap: file sharing is one of the most-used features in Talk, and its absence in federated rooms makes federation substantially less useful for real collaboration.

Proposed Behavior

Action	Expected result
User A (Instance A) shares a file in a federated room	User B (Instance B) receives a message with a file attachment card
User B clicks the file	The file opens via a cross-instance share link (OCM or direct share URL)
User A shares a photo/image	User B sees an inline image preview
File is deleted or share revoked on Instance A	The link degrades gracefully (404 / revoked state shown)
User B downloads the file	Download goes via Instance A's share endpoint; no file copy stored on Instance B

Technical Scope

1. Sending side — when a file message is sent in a federated room, the sender's instance must:

   • Create a public or user-scoped share for the file (or reuse an existing one)
   • Attach the share token / OCM resource URL to the chat message payload sent to the remote instance(s)

2. Receiving side — the receiving instance must:

   • Parse the file attachment metadata from the federated message
   • Render a file card in the chat UI (name, size, icon / thumbnail)
   • Fetch a preview/thumbnail via an OCS proxy or the sender's public thumbnail endpoint

3. Preview / thumbnail handling

   • Inline images: fetch thumbnail from sender's instance via the public share preview endpoint
   • Non-image files: show file icon + metadata (size, mime type)

4. Access control

   • The share created for the file must be at minimum "view" scoped
   • Optional: password protection, expiry — should not break the federated message card

5. Message format / protocol

   • Extend the federated message schema to carry a file object: { name, size, mimeType, previewUrl, downloadUrl }
   • Must be backwards-compatible (older instances ignore unknown fields)

6. UI components (Vue/Talk frontend)

   • Message renderer: handle file message type in federated context
   • Distinguish between local-share cards and federated-share cards where behavior differs

Out of Scope (for this issue)

• Editing/renaming files from the receiving instance
• Uploading files from the receiving side (separate issue)
• Video/audio attachments (can follow same pattern but needs separate review)
• End-to-end encryption for federated file transfers

Acceptance Criteria

• A user in a federated room can share a file from their Nextcloud and the remote participant sees a file card
• Images shared inline show a rendered preview on the remote instance
• Clicking a file card on the remote instance opens/downloads the file via the originating instance's share URL
• If the share is revoked, the card shows a clear "no longer available" state
• No file data is copied or stored on the receiving instance
• Backwards compatible: remote instances on older Talk versions degrade gracefully
• Unit + integration tests cover the new message type serialization/deserialization
• E2E test: two local Talk instances share a file in a federated room

[nickvergessen]

• We are tracking this indirectly at 🌐 Federated file sharing 📤 - Overview #11233
• Please note that the working going into 📂 Use subfolder for Talk attachments, one per conversation #4340 is seen as a pre-requirement from our side to make sure federated attachments have a chance to scale (with many files being shared at some point in a conversation)

That should already have high impact on steps 1+2. The main idea would be that a real federated share is used at the end when possible.

Inline images: fetch thumbnail from sender's instance via the public share preview endpoint

This would lead to content-security policy issues, but if the share is a normal federated file share that was received, the remote instance should be able to render it's own preview locally.

Clicking a file card on the remote instance opens/downloads the file via the originating instance's share URL

from local instance if federated share was established, public share should only be done when really required