# Архитектура Федеративного Прокси-Хранилища (Remote Proxy Storage)

Для экономии места и обеспечения суверенитета данных, медиафайлы в федерации Knot Messager **не дублируются** на сервере-получателе.

## 1. Механизм работы

1.  **Отправка (Sender)**:
    *   Пользователь на `Server A` загружает файл. Файл сохраняется в S3/Local Storage сервера А.
    *   В федеративном пакете передается метаданные: `{ "fileId": "uuid", "proxyUrl": "https://server-a.com/api/federation/v1/proxy/uuid" }`.

2.  **Прием (Recipient)**:
    *   `Server B` получает сообщение. Он **не скачивает** файл себе.
    *   Для своего клиента Server B генерирует внутреннюю ссылку: `https://server-b.com/api/files/remote/server-a.com/uuid`.

3.  **Просмотр (Client-Recipient)**:
    *   Когда клиент на Server B хочет посмотреть картинку, он делает запрос на свой `Server B`.
    *   `Server B` выступает как **Streaming Proxy**: он делает запрос к `Server A` (подписав его системным ключом), получает поток байтов и стримит его клиенту.

## 2. Безопасность и Валидация

*   **Auth Signature**: Прокси-запрос между серверами обязательно подписывается RSA. Без валидной подписи Server А не отдаст файл.
*   **Privacy**: Только серверы участников чата могут проксировать файлы.
*   **Zero-Knowledge**: Если файлы зашифрованы E2EE, проксирующий сервер все равно видит только поток зашифрованных байтов.

---

## Задачи на текущую итерацию:

1.  **Federation Endpoints**: Добавить `GET /v1/proxy/{id}` (отдача своего файла другому серверу).
2.  **Storage Module**: Добавить `RemoteFileController`, который умеет запрашивать файл у другого сервера и стримить его.
3.  **Messaging Integration**: При получении MediaMessage сохранять ссылку на удаленный прокси-хост.
