# RDP FIDO — что нового

Клиент и шлюз обновляются вместе: клиент предлагает новую версию при запуске,
шлюз обновляется из клиента после сессии, подтверждённой ключом (галочка
«Автоматически обновлять шлюз на этой машине»). Скачать:
[RdpFido-Setup.exe](https://accounts.new-imobile.com/updates/RdpFido-Setup.exe)
(хост или клиент), [RdpFidoClient-Setup.msi](https://accounts.new-imobile.com/updates/RdpFidoClient-Setup.msi),
[RdpFidoGate-Setup.msi](https://accounts.new-imobile.com/updates/RdpFidoGate-Setup.msi).
English: [CHANGELOG.en.md](CHANGELOG.en.md).

## 1.24.1 — 05.10.2026

- **Клиент, перезапущенный при открытой сессии, не поднимает ложную тревогу.**
  Шлюз держит порт открытым для адреса, пока с него идёт сессия, а клиент
  помнил о своих сессиях только до закрытия: после обновления (или закрытия и
  нового запуска) с открытым окном mstsc плитка краснела — «Порт RDP отвечает
  без ключа», хотя отвечал он только этому компьютеру. Теперь клиент при
  запуске находит оставшиеся окна mstsc и возвращает плиткам «Подключено»:
  щелчок поднимает то же окно, а не открывает второе подключение (которое
  выбивало первое), при закрытии окна порт закрывается сразу. Проверка порта
  пропускается и тогда, когда соединение туда держит что угодно на этом
  компьютере — вторая плитка для той же машины или mstsc, запущенный руками.
  Настоящую утечку (порт отвечает, а соединения отсюда нет) клиент показывает
  как прежде.
- **Окно сессии помещается на экран.** Оно было одной высоты для всех
  протоколов — по самому длинному, FIDO Stream, — и при масштабе 150% кнопки
  «Сохранить» и «Отмена» уходили за нижний край экрана. Теперь высота — по
  выбранному протоколу, без пустого места (у консоли SSH убрана и пустая
  строка домена), а если и так не помещается, настройки протокола встают
  второй колонкой справа.
- **Помощник в консоли SSH показывает модели сервера.** В настройках под
  шестерёнкой модель приходилось вписывать по памяти. Теперь после ввода
  адреса (для Claude — и ключа) под полем «Модель» появляется список моделей,
  которые есть на сервере; название по-прежнему можно ввести вручную. Адрес
  сервера, совместимого с OpenAI, набранный без `/v1` (`http://адрес:1234`),
  исправляется сам. Сохранённый ключ уходит только на тот адрес, для которого
  он сохранён.
- **Плитки SSH — на своей вкладке, компактные, со своей картинкой.** В окне
  клиента две вкладки: «Рабочие столы» (RDP и FIDO Stream) и «SSH» (сессии с
  протоколом «Консоль SSH»); на каждой — число сессий. Переключаются клавишей
  Tab (или Ctrl+Tab, или щелчком); клиент помнит, на какой вкладке его закрыли.
  Плитка SSH втрое меньше плитки рабочего стола и стоит плотнее: снимка экрана
  у консоли нет, поэтому слева небольшая картинка, рядом имя, адрес и когда
  подключались. Картинку можно поставить свою: правый щелчок → «Картинка
  плитки…» (или кнопка «Снимок» на вкладке SSH) — PNG, JPEG, BMP, GIF, ICO;
  «Убрать картинку» возвращает букву. «Добавить» на вкладке SSH сразу
  предлагает консоль SSH. Реклама бесплатного тарифа осталась на вкладке
  рабочих столов. К кнопкам и поиску с клавиатуры — Shift+Tab.
- Только Windows, и всё это — клиент: шлюз не менялся. Linux-пакеты остаются
  1.24.0; список моделей в консоли на Linux появится со следующей сборкой
  пакетов.

## 1.24.0 — 04.10.2026

- **SSH и другие порты за тем же ключом (шлюз на Linux).** `rdpfido-gate
  ports add 22` закрывает порт так же, как RDP: он открывается тем же
  подтверждением ключом (или кодом) и только для адреса, с которого оно
  пришло. Уже установленные соединения не рвутся, `unlock` и `arm` действуют
  и на эти порты. В клиенте для Linux — `rdpfido open СЕССИЯ` (только открыть
  порты) и `rdpfido ssh СЕССИЯ` (открыть и запустить ssh). Через облако
  по-прежнему идёт только RDP; шлюз на Windows список пока не учитывает.
- **Консоль SSH** — окно с терминалом и панелью: сохранённые пароли вводятся в
  консоль щелчком или сами по запросу (например, пароль sudo), сохранённые
  команды — для сессии или для всех, помощник ИИ (Claude или сервер,
  совместимый с OpenAI) предлагает команды и по настройке вставляет или
  выполняет их, а с разрешения видит консоль. В клиенте Windows — плитка с
  протоколом «Консоль SSH» (щелчок → ключ → консоль) или «Консоль SSH…» в
  меню любой плитки; порт SSH, файл ключа и параметры ssh задаются в
  свойствах сессии. В Linux — `rdpfido console СЕССИЯ` и
  `--ssh-port/--ssh-key/--ssh-opt` у `rdpfido add|edit`. На Windows консоль
  встроена в `RdpFidoClient.exe` и приходит с обновлением, в Linux входит в
  пакет клиента. Подробно: [CONSOLE.md](CONSOLE.md).
- **Помощник в консоли: промпты, история, время ожидания.** Промпты сессии —
  постоянные заметки (описание системы, версия Ubuntu): отмеченные флажком
  уходят модели с каждым запросом, состояние флажка сохраняется. Разговоры
  хранятся по сессиям — прежний можно открыть и продолжить или начать новый.
  Время ожидания ответа модели задаётся в настройках помощника (10–3600 с).

## 1.23.0 — 30.09.2026

- **Вход по одноразовому коду вместо ключа.** Шлюз пускает одним способом,
  его выбирают при установке: ключом FIDO (как раньше, по умолчанию) или
  6-значным кодом из любого приложения-аутентификатора (Google Authenticator,
  Microsoft Authenticator, Aegis…) — для тех, у кого ключей нет. MSI шлюза
  спрашивает при новой установке («Как будут входить пользователи?»; без
  окна — `GATEAUTH=totp`); `setup --auth totp`, `Install-Gate.ps1
  -AuthMethod totp`; потом `RdpFidoGate.exe auth fido|totp` (на Linux
  `rdpfido-gate auth …`) переключает режим и перезапускает шлюз. Обновление
  режим не меняет.
- Регистрация на шлюзе с кодами — как регистрация ключа: код регистрации из
  `code`, дальше клиент показывает QR-код и секрет, первый код из приложения
  подтверждает. `totp add ИМЯ` заводит учётку на самом шлюзе и печатает
  QR-код в консоли; `totp test N КОД` проверяет код. Один код принимается
  один раз.
- Код открывает только RDP (Windows по-прежнему спрашивает пароль): FIDO
  Stream и обновление шлюза из клиента остаются за ключами. Неверные коды
  тормозятся по адресу и по всему шлюзу (30 за 10 минут — вход по коду
  замирает на 10 минут). Клиентам старше 1.23 предлагается обновиться.

## 1.22.2## 1.22.2 — 29.09.2026

- **Шлюз переживает медленный брандмауэр Windows при загрузке.** При
  холодной загрузке служба брандмауэра Windows может отвечать на первый вызов
  шлюза дольше 20 секунд; шлюз сдавался, останавливался и на установках до
  1.20 больше не перезапускался — RDP оставался закрыт, пока службу не
  запустят руками. Теперь при старте шлюз ждёт брандмауэр до двух минут
  (сторож зависшего брандмауэра по-прежнему завершает процесс после 90 секунд
  в одном вызове) и всё это время сообщает о ходе запуска диспетчеру служб,
  так что `Start-Service` больше не выдаёт ошибку. Установка и обновление
  поверх существующей службы заново задают политику перезапуска при сбое —
  при обновлении она могла не примениться (дескриптору не хватало права,
  нужного для `SC_ACTION_RESTART`). Неудачный старт пишет в журнал настоящий
  код ошибки вместо «Операция успешно завершена».
- Включает 1.22.1 (ниже). Только Windows: Linux-пакеты остаются 1.22.0.

## 1.22.1 — вошла в 1.22.2 (отдельно не выпускалась)

- **`RdpFidoGate.exe code --keep [--role lead|watch] [--key-ttl 24h]`**
  (на Linux `rdpfido-gate code --keep …`) выдаёт *постоянный* код
  регистрации: многоразовый, не сгорает при регистрации, не истекает до
  `code --clear`. Каждый ключ, зарегистрированный по нему, получает роль и
  срок жизни `--key-ttl` (по умолчанию 24 часа; истёкшие ключи удаляет жнец
  шлюза). Обычный одноразовый код не тронут и работает рядом (`code` или
  приглашение в общий сеанс постоянный код не отменяют); `status` и
  `check-code` его показывают, `/v1/hello` отдаёт `standingCode: true` и
  держит `enrollmentOpen`, пока он есть. Ограничение частоты попыток
  регистрации остаётся, каждая регистрация по постоянному коду пишется в
  журнал с адресом. Сделано для публичных демо-машин (docs/DEMO.md); на
  машине, которой дорожите, не включать. Пока на шлюзе не выполнили
  `code --keep`, ничего не меняется.

## 1.22.0 — 28.09.2026

- **RDP FIDO Cloud в клиенте: подключение к шлюзу за NAT без пробросов.**
  Шлюз, привязанный к облаку, получает адрес вида `<id>.g.<домен>` (порт
  443) — его вводят как адрес сервера и шлюза, всё остальное как раньше:
  тот же ключ, тот же закреплённый отпечаток сертификата, та же проверка.
  Через облако шлюз вместо правила брандмауэра выдаёт билет туннеля на
  окно доступа, и клиент проводит RDP через хаб: слушатель на `127.0.0.1`,
  `mstsc` (на Linux — xfreerdp) подключается к нему, а байты идут к хабу в
  зашифрованных записях (ECDH + AES-256-GCM поверх TLS и NLA самого RDP).
  Хаб видит только адреса и объёмы. Туннель живёт, пока открыто окно RDP;
  слушатель держится всё время жизни билета и принимает до четырёх
  подключений тем же билетом — `mstsc` разрывает соединение и подключается
  заново после своих диалогов и при автопереподключении (хаб и шлюз считают
  использования, шлюз к тому же требует адрес, которому билет выдан). Шлюз
  сообщает в `auth/finish` отпечаток сертификата своего RDP-слушателя
  (`rdpCertSha256`, `rdpCertSha1`), и клиент перед запуском `mstsc`
  закрепляет его для `127.0.0.1` (`HKCU\…\Terminal Server
  Client\Servers\127.0.0.1\CertHash` — то, что пишет галочка «больше не
  спрашивать»): вопрос о подлинности не появляется, `authentication level`
  остаётся 2; Linux-клиент передаёт xfreerdp `/cert:fingerprint:sha256:…`.
  В статусе и на плитке — «через
  облако»; в диалоге сессии — подсказка про адрес и публичное имя шлюза
  при проверке.
- Клиент называет свою версию в запросах к шлюзу (`clientVersion`); шлюз
  через облако отвечает понятным сообщением клиенту старше 1.22
  (`client_too_old`) и когда его связь с облаком сейчас разорвана
  (`cloud_unavailable`).
- Без облака (шлюз не привязан, ответ без `tunnel`) клиент работает ровно
  как 1.21.
- **Облако как опция — сторона шлюза.** Шлюз можно привязать к хабу RDP FIDO
  Cloud (своему `rdpfido-cloud` или облаку Imobile): `RdpFidoGate.exe cloud
  link ХАБ КОД` (Linux: `rdpfido-gate cloud link`), `cloud unlink`, `cloud
  status`. Пока не привязан, шлюз не делает ни одного исходящего соединения
  и работает ровно как раньше. Привязанный держит одно соединение к хабу с
  переподключением (1 → 60 с) и принимает через него HTTPS клиентов в свой
  же слушатель, подставляя настоящий адрес клиента (страны, лимиты,
  привязка challenge к адресу — как обычно). RDP через облако открывается
  **не правилом брандмауэра, а билетом туннеля** на окно доступа (до
  четырёх подключений, только с адреса клиента):
  ответ `auth/finish` несёт `tunnel`, порт 3389 снаружи закрыт как и был.
  `/v1/hello` сообщает `cloud {linked, connected, publicHost, publicPort}`,
  реле хаба добавляются к своим в `stream/open`. Клиентам старше 1.22 через
  облако шлюз отвечает `client_too_old`; при отвалившемся соединении с хабом
  — `cloud_unavailable` (503). Состояние — в `cloud-state.json`.
  `RdpFidoGate.exe cloud selftest` гоняет протокол на встроенном макете хаба
  (Windows и Linux).
- **Облако Imobile — закрытый сервис.** В 1.22.0 облачный режим работает с
  вашим собственным хабом `rdpfido-cloud` (self-hosted: бинарь, юнит и
  `install.sh` — в архиве `rdpfido-cloud-1.22.0-linux-x86_64.tar.gz` рядом с
  Linux-пакетами, описание — `README-cloud.ru.md`) или с облаком Imobile.
  Облако Imobile не открывается всем: шлюз к нему подключает Imobile по
  договорённости, а для знакомства наружу даётся демо-доступ для подключения
  (демо-машины через облако). Без привязки к хабу шлюз и клиент работают
  как раньше.
- **Облако:** кабинет хаба `rdpfido-cloud` — организации, участники, роли, права «участник → шлюз» с условиями (дни, часы, страны, срок), подписанные манифесты прав для шлюзов, журнал, веб-интерфейс на `adminPort` и JSON-API; вход через учётную запись Imobile или свои логины (`rdpfido-cloud user`). См. `docs/CLOUD-CABINET.md`.
- **Совместный доступ к потоку — сторона зрителя.** К одному сеансу FIDO
  Stream подключаются несколько участников, управляет один. Вьювер
  показывает, у кого управление (подсказка в углу при каждой смене), а
  пока оно не у вас — плашку «Только просмотр — Ctrl+Alt+R: запросить
  управление» и ничего не отправляет хосту; мышь над картинкой становится
  указкой, которую видят все (кружок с именем, свой цвет у каждого).
  Ведущему на запрос всплывает «<имя> просит управление: Передать (Enter)
  / Отклонить (Esc)», через 30 с без ответа — отказ. В меню сеанса:
  «Участники…», «Запросить управление», «Передать управление ▸ <имя>»,
  «Вернуть управление хосту», «Пригласить…» (код регистрации для гостя с
  ролью «сможет вести» или «только смотреть», с адресом шлюза и сроком,
  кнопка «Копировать»). Оверлей (Ctrl+Alt+O) показывает
  `participants: N, control: <имя>`. На Linux то же клавишами:
  Ctrl+Alt+R, Ctrl+Alt+Shift+P/H/I, Enter/Esc; `rdpfido stream` печатает
  события участников. Со стороной 1.21 всё как раньше.
- Клиент передаёт в `stream/open` `share: true` и `role: lead` и отдаёт
  вьюверу `participant`/`inviteToken` из ответа; от шлюза 1.21 их нет — и
  вьювер ведёт себя как прежде.
- Для проверки без хоста 1.22: `RdpFidoViewer.exe … --demo-share` /
  `rdpfido-viewer … --demo-share` (или `RDPFIDO_VIEWER_DEMO_SHARE=1`)
  разыгрывают общий сеанс из трёх участников.
- **Совместный доступ в FIDO Stream.** К одному экрану подключаются
  несколько участников (до 8, по умолчанию 4), управляет ровно один:
  первый подключившийся с правом «управлять» — ведущий, остальные смотрят,
  слушают и водят указкой; зритель просит управление, ведущий передаёт
  или отклоняет (без ответа за 30 с запрос гаснет); человек за хостом
  забирает управление сочетанием Ctrl+Alt+Shift+H, а `RdpFidoGate.exe
  stream control host|<id>` назначает ведущего принудительно. Ввод, буфер
  обмена, файлы, микрофон и настройки качества принимаются только от
  ведущего — на хосте, а не в окне клиента. Кадр захватывается и
  кодируется один раз; у каждого участника свои ключи, порт и правило
  брандмауэра. Ведущий отключился — управление у хоста или у первого в
  очереди (`"streamLeaderLeft"`); вернувшийся ведущий получает его обратно.
- **Приглашение на лету.** Ведущий создаёт код приглашения на 15 минут
  (`/v1/stream/invite`); гость регистрирует ключ этим кодом и получает роль
  «смотреть» или «управлять» и срок действия (по умолчанию 8 часов), после
  которого шлюз удаляет ключ сам. Роль есть и у обычных ключей:
  `key-role <номер|метка> lead|watch`, `keys` показывает её.
- Шлюз: `"streamShared"`, `"streamMaxParticipants"`, `"streamLeaderLeft"`,
  `"inviteTtlSeconds"` в `gate.json`; `stream participants`; UDP-порты
  потока — базовый..базовый+7 (было +3). Ответ `stream/open` несёт
  `participant` и `inviteToken`. Сторона 1.21 работает как раньше.

## 1.21.0 — вошла в 1.22.0 (отдельно не выпускалась)

- **Передача файлов в FIDO Stream, в обе стороны и между разными ОС.**
  Перетащите файлы или папки в окно потока — они окажутся на хосте в
  «Загрузки\RDP FIDO» (на Linux — `~/Загрузки/RDP FIDO`, по XDG). То же в
  меню сеанса: «Отправить файлы на хост…». Обратно: всё, что положить на
  хосте в `Загрузки\RDP FIDO\Outbox`, приезжает на ваш компьютер в ту же
  папку «RDP FIDO», а на хосте переезжает в `Outbox\Sent`. Windows↔Linux
  в любых сочетаниях: имена в UTF-8, пути с любыми разделителями, время
  изменения сохраняется, бит исполнения — на Linux.
- **Передача не мешает работе.** Файлы идут третьим надёжным каналом
  потока, который отправляется только когда не ждут ни видео, ни звук, ни
  ввод, и со своим ограничением скорости: регулятор поднимает её, пока
  задержка на пути не растёт, и режет вдвое, как только растёт — раньше,
  чем это заметит регулятор видео. Картинка и отклик остаются прежними,
  файл берёт остаток полосы; на локальной сети — десятки мегабайт в
  секунду. Ход передачи виден в заголовке окна и в меню (там же «Отменить
  передачу файлов»); каждый законченный файл объявляется подсказкой.
- **Защита.** Файлы попадают только в папку «RDP FIDO»: имена очищаются
  (`..`, диски, запрещённые символы, имена устройств), совпадения получают
  суффикс «(2)». Хост может запретить файлы целиком: `"streamFiles": false`
  в `gate.json` (на вьювере — `--no-files`). Пока файл не дошёл целиком,
  он лежит рядом как `.part` и удаляется при обрыве.
- Со сторонами версии 1.20 поток работает как раньше, просто без файлов
  (клиент сообщит «хост не принимает файлы»).

## 1.20.0 — 26.09.2026

- **RDP FIDO для Linux.** Шлюз `rdpfido-gate` для Ubuntu, Astra Linux и
  РЕД ОС: закрывает порт xrdp своими правилами nftables (или iptables, если
  nftables нет) для IPv4 и IPv6 и открывает его только адресу, прошедшему
  проверку FIDO-ключом, — те же проверки и тот же протокол, что у шлюза для
  Windows. `sudo rdpfido-gate setup` делает всё сразу: сертификат, служба,
  xrdp стартует только после шлюза, порты в ufw/firewalld, код регистрации.
- **Клиент для Linux**: окно `rdpfido-gui` и командная строка `rdpfido`.
  Ключи — любые FIDO2 USB/NFC (через libfido2), подключение — FreeRDP,
  пароли — в связке ключей рабочего стола. Подключается к шлюзам на Windows
  и на Linux.
- **С Windows на Linux.** Windows-клиент сам узнаёт, что на той стороне
  xrdp, и подключает mstsc без NLA (xrdp её не умеет; TLS остаётся), не
  пытаясь обновить Linux-шлюз файлом для Windows.
- **Исправлено (важно для безопасности, касается и шлюза на Windows).** Ключ,
  удалённый командой `remove-key`, продолжал открывать порт до перезапуска
  службы, а при следующем использовании любого ключа служба записывала его
  обратно в список. Теперь удаление действует сразу. Обновите шлюз.
- **Исправлено (касается и шлюза на Windows).** Две одновременные
  авторизации с одного адреса могли оставить правило брандмауэра, которое
  никто не отслеживал и которое поэтому не закрывалось до перезапуска
  службы. Теперь такого не бывает — проверено нагрузкой до 150 авторизаций в
  секунду.
- Linux-шлюз закрывает порт RDP уже при загрузке, до сети и до xrdp; если
  это не удалось, xrdp не запускается. Порт 3389 в ufw/firewalld открывается
  только под защитой шлюза, а `uninstall` возвращает ufw/firewalld в прежнее
  состояние.
- Регистрация ключа с Linux-клиента может сразу сверить отпечаток шлюза
  (`rdpfido enroll … --fingerprint`, поле в окне) — код регистрации не
  уйдёт подставному серверу.
- Шлюз (и на Windows): служба и командная строка больше не могут
  одновременно переписать `gate.json` и потерять изменения друг друга.
- **FIDO Stream на Linux — в обе стороны.** Linux-машина может отдавать
  свой рабочий стол потоком (агент в пакете шлюза: захват X11, H.264, звук,
  ввод, геймпады) и смотреть поток с Windows или Linux (`rdpfido stream`,
  кнопка «Поток» в окне, `rdpfido-viewer`). Windows-клиент открывает поток на
  Linux-машину так же, как на Windows. Порты потока открываются только
  адресу, подтвердившему вход ключом. Подробности — [LINUX.md](LINUX.md).
- **Срок работы без обновления — один год.** Каждая версия работает год с
  даты выпуска, затем требует обновления. Клиент перестаёт подключаться:
  Windows-клиент сам скачивает и ставит новую версию, Linux-клиент называет
  команду обновления пакета. Шлюз по-прежнему проверяет ключ, но не открывает
  доступ, пока его не обновят: Windows-клиент при этом сразу отправляет шлюзу
  новую версию и подключается снова, Linux-шлюз обновляется пакетом (команда —
  в сообщении и в `status`). За 30 дней до срока — предупреждения. Перевод
  часов назад срок не продлевает. Регистрация ключей и аварийный `unlock`
  работают и после срока.
- Клиент для Windows больше не считает повреждённым список сессий,
  сохранённый с меткой BOM (PowerShell, старый «Блокнот»).

## 1.19.3 — 20.09.2026

- **Больше нет ложного «ПОСТОРОННИЙ ДОСТУП К RDP!» за пробросом порта.** Раз
  в минуту клиент проверяет, что порт RDP не отвечает без ключа. Если хост
  доступен через проброс (netsh portproxy, SSH- или программный релей,
  некоторые роутеры), соединение принимает сам проброс, и проверка поднимала
  красную тревогу, хотя порт RDP за ним был закрыт. Теперь клиент считает порт
  открытым, только получив настоящий ответ RDP на начало сеанса. Порт, который
  действительно открыт без ключа, по-прежнему вызывает тревогу. Меняется
  только клиент, шлюз обновлять не нужно.

## 1.19.2 — 20.09.2026

- **Меню сеанса вернулось — и всё остальное, что потеряла 1.19.** 1.19.0 и
  1.19.1 были собраны из линии разработки, в которую не попали четыре более
  ранних выпуска, поэтому обновление до 1.19 молча убрало: меню в окне потока
  (Ctrl+Alt+Shift+M) и его горячие клавиши, панель у верхнего края в полном
  экране, Ctrl+Alt+Del на хост, исправления положения указателя, «разрешение
  хоста по моему экрану» и исправление шлюза, из-за которого подключение
  потока открывало RDP-порт. Всё это возвращено вместе со всем, что добавила
  1.19 (точная частота монитора, оверлей метрик, AV1 / 10 бит / HDR, Opus,
  реле, геймпад).
- **Обновите и шлюз.** Две линии заняли одни и те же два внутренних номера
  сообщений под разное. С клиентом 1.19.0–1.19.1 и шлюзом 1.18.1 подключение
  нажимало на хосте Ctrl+Alt+Del и раз в секунду просило сменить видеорежим.
  В 1.19.2 оба номера выведены из оборота; пока обе стороны не станут 1.19.2,
  поток работает с возможностями 1.18 (без AV1, 10 бит, HDR и точной частоты)
  — и ничего хуже.
- Выпуски теперь проверяются взглядом на само окно потока — тестовая таблица
  должна прийти неперевёрнутой и в цвете, меню должно открыться, — а скрипт
  публикации отказывается собирать из дерева, где нет чего-либо выпущенного
  раньше.

## 1.19.1 — 20.09.2026

- **FIDO Stream показывал чёрное окно.** Сессия подключалась, заголовок окна и
  оверлей сообщали нормальную частоту кадров, но сама картинка оставалась
  чёрной — на любой машине, с любым кодеком и настройками качества: вьювер
  отбрасывал прямоугольник с видео ещё до отрисовки. Исправлено; вместе с ним
  снова виден и удалённый указатель мыши. Меняется только клиент — шлюз ради
  этого обновлять не нужно.

## 1.19.0 — 16.09.2026

- **120 / 144 / 240 Гц.** Поток идёт с точной частотой вашего монитора
  (143,856 Гц так и остаются 143,856, а не 144): хост захватывает и кодирует в
  этом ритме по таймеру с субмиллисекундной точностью, а вьювер показывает
  кадр либо сразу после декодирования («Сразу»: минимальная задержка,
  разрешён разрыв), либо на следующем обновлении экрана («Плавно»: без
  разрывов и повторов). «Автоматически» выбирает «Плавно», когда частота
  потока совпадает с частотой монитора. Мышь передаётся событие за событием с
  её собственной частотой опроса (1000 Гц включительно); события, скопившиеся
  пока окно было занято, объединяются без добавления задержки. Программные
  кодеры ограничены 60 к/с.
- **Оверлей метрик и трасса.** Ctrl+Alt+O показывает, на что уходит каждая
  миллисекунда: захват, преобразование, кодирование, сеть и сборка,
  декодирование, ожидание обновления экрана, показ; битрейт, потери, доля FEC
  и восстановления, NACK, RTT, задержка в очереди, размер датаграммы, реле;
  частота и дрожание показа; оценка «клик → фотон» — клики и нажатия
  помечаются, и ищется первый кадр, захваченный хостом после их ввода (время
  отклика самого монитора не входит). Ctrl+Alt+T пишет CSV-трассу (строка на
  кадр со всеми отметками времени, строка в секунду со счётчиками канала,
  строка на событие) в `%LOCALAPPDATA%\RdpFidoClient\traces`; сессия может
  стартовать с включённым оверлеем или записью трассы.
- **AV1, 10 бит, 4:4:4 и HDR.** Новые настройки сессии «Кодек» (авто / H.264 /
  HEVC / AV1) и «Цвет» (авто / 8 бит / 10 бит / 4:4:4 / HDR). AV1 кодируется
  на NVENC (RTX 40) и на AV1-кодерах Intel Arc и AMD RDNA3, декодируется на
  NVDEC или аппаратном декодере. 10-битные HEVC/AV1 убирают полосы в
  градиентах; 4:4:4 сохраняет чёткость тонкого текста. При включённом HDR в
  Windows на хосте и HDR-мониторе у клиента рабочий стол дублируется в FP16,
  на видеокарте переводится в 10-битный PQ BT.2020 и показывается как HDR
  (на SDR-мониторе — с тон-мэппингом). Всё автоматически понижается до того,
  что умеют обе стороны; «Автоматически» берёт AV1 или HEVC, когда узкое
  место — канал, и H.264, когда — компьютеры.
- **Звук Opus.** Звук хоста передаётся Opus 128 кбит/с (режим restricted low
  delay, кадры 10 мс), микрофон — 48 кбит/с; потерянный пакет восстанавливается
  из встроенного FEC следующего. libopus 1.5.2 (BSD-3) собран внутрь
  исполняемых файлов; старые версии остаются на ADPCM.
- **Реле для симметричных NAT.** Когда напрямую не достучаться ни до одной
  стороны, поток идёт через ваше реле: `rdpfido-relay` для Linux-VPS
  (`src/relay`, `make install`, systemd-юнит) или `RdpFidoGate.exe relay serve`
  на Windows. Реле перечисляются в `gate.json` шлюза (`"streamRelays":
  [{"address": "relay.example.com:7443", "name": "eu-1"}]`); обе стороны
  пробуют их и берут ближайшее, дав прямым путям фору 1,5 с. Реле пересылает
  только сквозно зашифрованные датаграммы и ключей не имеет.
- **Настройка для WAN.** Контроль перегрузки масштабирует пороги задержки по
  базовому RTT (12 мс в локальной сети, до 50 мс через континенты), бюджет на
  восстановление растёт с RTT, FEC — на длинных путях. MTU discovery поднимает
  датаграмму с 1200 до 1472 байт, когда путь это выдерживает (меньше, но
  крупнее шардов), перепроверяя каждые 30 с и откатываясь при смене пути.
- Совместимо по протоколу с 1.15–1.18: старые версии игнорируют новые
  сообщения.

## 1.18.1 — 13.09.2026

- **Подключение FIDO Stream больше не открывает RDP-порт.** Авторизация потока
  заодно открывала разрешение на RDP, которым поток не пользуется; недожившее
  RDP-соединение могло удерживать его открытым, и клиент рисовал на плитке
  ложную тревогу «RDP открыт всем».
- **Разрешение хоста по вашему экрану** (выключено по умолчанию; галочка в
  параметрах сессии и пункт в меню сеанса): хост переключается в режим вашего
  монитора или в наибольший с теми же пропорциями и возвращает прежний по
  окончании сеанса.

## 1.18.0 — 16.09.2026

- **Геймпад в FIDO Stream.** Подключите XInput-геймпад (Xbox One/Series,
  Xbox 360, большинство геймпадов с переключателем «X») к клиенту: на хосте
  он появляется как контроллер Xbox 360, игра ничего не замечает, вибрация
  возвращается на ваш геймпад. До четырёх геймпадов на сессию. Как и
  клавиатура, геймпад управляет хостом только пока окно потока впереди.
- **На основе ViGEmBus.** Виртуальный контроллер — открытый драйвер ViGEmBus
  от Nefarius Software Solutions (лицензия BSD-3), тот же, на котором работают
  Sunshine, Apollo и DS4Windows. Проект архивирован в конце 2023 года; его
  последний выпуск (драйвер 1.21.442.0, подпись Microsoft/WHQL) ставится на
  текущие сборки Windows 10/11 x64 без тестового режима и с включённым HVCI.
  Пакет вшит в `RdpFidoGate.exe`: `setup` его устанавливает, шлюз, обновлённый
  на месте, ставит его при следующем запуске службы, а `uninstall` удаляет
  только драйвер, который поставил этот шлюз — ViGEmBus, принесённый другой
  программой, остаётся. `RdpFidoGate.exe gamepad status|install|remove`
  управляет им; `RdpFidoGate.exe stream gamepad-test` проверяет весь путь на
  хосте (подключение, XInput его видит, вибрация возвращается, отключение)
  без вьювера. Если драйвер поставить не удалось, шлюз и поток работают,
  просто геймпад на этом хосте ничего не делает.
- Оба установщика кладут рядом с программой `THIRD-PARTY-LICENSES.txt`
  (ViGEmBus, заголовки ViGEmClient, заголовки кодеков NVIDIA).
- `gate.json`, сохранённый с меткой порядка байтов UTF-8 (Блокнот, Windows
  PowerShell), больше не останавливает службу; номера шагов `setup` теперь
  видны в журнале Windows Installer.

## 1.17.2 — 12.09.2026

- **Указатель попадал мимо.** Агент хоста не учитывал DPI: при масштабе экрана
  больше 100 % абсолютные координаты мыши ложились на экран меньше
  захваченного; а при захваченной мыши вьювер ставил указатель хоста по
  размеру видео, а не хоста, и в уменьшенном потоке он не доезжал.

## 1.17.1 — 12.09.2026

- **Меню сеанса и горячие клавиши.** Ctrl+Alt+Shift+M открывает меню в окне
  потока: захват мыши, полный экран, баланс качества, Ctrl+Alt+Del,
  отключение. Горячие клавиши на трёх модификаторах, которые не занимает ни
  одна игра: +Z мышь, +X полный экран, +D Ctrl+Alt+Del, +Q отключиться.
  Ctrl+Alt+End шлёт Ctrl+Alt+Del, как mstsc. В полном экране у верхнего края
  выезжает панель.
- Окно потока было чёрным на машинах без видеокарты.

## 1.17.0 — 11.09.2026

- **Один файл на сторону.** Агент хоста FIDO Stream теперь встроен в
  `RdpFidoGate.exe`, окно потока — в `RdpFidoClient.exe`. Оба установщика и
  автообновление приносят всё, что нужно потоку; вручную больше ничего
  копировать не надо. Шлюз запускает себя командой `stream serve` в сеансе
  пользователя, клиент — командой `viewer` в дочернем процессе, поэтому
  падение декодера или драйвера закрывает только окно потока.
- На установленном хосте доступны команды диагностики
  `RdpFidoGate.exe stream encoders`, `stream encoders --bench`,
  `stream selftest` и `stream audio-devices`.
- Самообновление при открытом потоке: старый файл сначала переименовывается,
  потом копируется новый, поэтому обновление больше не срывается, пока идёт
  стрим.
- **Шлюз восстанавливается после зависшей службы брандмауэра Windows.** Если
  вызов в службу брандмауэра не возвращается, сторожевой поток завершает шлюз
  через 90 с, и диспетчер служб перезапускает его — вместо ответа «рабочий
  поток брандмауэра не ответил вовремя» на каждый запрос, пока кто-нибудь не
  заметит. Гранты, записанные из потока брандмауэра, истекают по расписанию,
  даже если вызывающая сторона перестала ждать; удаление правил не теряется.

## 1.16.1 — 11.09.2026

- HEVC декодируется на видеокарте безопасным путём: NVIDIA NVDEC на NVIDIA,
  аппаратный DXVA-декодер на Intel и AMD. Программное расширение HEVC от
  Microsoft не используется (оно падает), поэтому вьювер без подходящей
  видеокарты переходит на H.264, а не падает, и пишет причину в `client.log`.
- Декодер H.264 Media Foundation теперь тоже работает на видеокарте (DXVA).

## 1.16.0 — 10.09.2026

- **Кодер и декодер выбираются в сессии.** «Кодер (хост)»: Автоматически /
  NVIDIA NVENC (напрямую) / Аппаратный (любая видеокарта) / Программный
  (процессор); «Декодер»: Автоматически / Аппаратный (GPU) / Программный
  (CPU). NVENC работает напрямую через драйвер, аппаратный вариант — кодер
  любого производителя через Media Foundation (Quick Sync, AMF), программный —
  H.264 Microsoft.
- `encoders --bench` измеряет каждый бэкенд на синтетических кадрах без экрана
  и сети.
- Два исправления задержки: ожидание захвата экрана больше не блокирует поток
  кодера, а настройки низкой задержки кодера NVIDIA применяются там, где он их
  учитывает. Кодирование 2560×1600 — с 60 мс до 6,5 мс на кадр; задержка «из
  конца в конец» в локальной сети — с 380 мс до 25–45 мс.

## 1.15.0 — 10.09.2026

- **FIDO Stream** — второй режим подключения рядом с RDP для игр и другой
  работы, где важнее всего задержка «клик — фотон». Видео, звук и ввод идут
  по UDP: AES-256-GCM на ключах из ECDH, привязанного к билету, который шлюз
  выдаёт только после подтверждения ключом FIDO2; код Рида–Соломона (FEC)
  вместо ретрансляций; надёжный канал для ввода; контроль перегрузки.
- Хост: захват DXGI Desktop Duplication, аппаратное кодирование (NVENC /
  Quick Sync / AMF через Media Foundation) с путём пикселей D3D11 без копий,
  звук WASAPI, внедрение ввода скан-кодами. Вьювер: аппаратное декодирование,
  вывод D3D11 flip без вертикальной синхронизации, raw input, захват мыши
  (Ctrl+Alt+Home), полный экран (Ctrl+Alt+Enter), отключение (Ctrl+Alt+End).
- Один ползунок **«Баланс»** от «плохой канал» до «слабые компьютеры» с
  режимом «Авто»; звук в обе стороны, включая микрофон; хост сам дозванивается
  до клиента через большинство NAT по кандидатам адресов, переданным через
  HTTPS-канал шлюза. UDP 7441 открывается только для подтверждённого адреса и
  только на время сессии.

## 1.14.0 — 03.09.2026

- **Один объединённый установщик** `RdpFido-Setup.exe` задаёт единственный
  вопрос — это хост (к нему подключаются) или клиент (с него подключаются) — и
  ставит нужную половину. Без диалогов: `RdpFido-Setup.exe host|client`.
  Клиент остаётся пакетом «на пользователя» (без прав администратора), шлюз —
  «на машину» (служба).

## 1.13.0 — 01.09.2026

- Шлюз поставляется как MSI, `RdpFidoGate-Setup.msi`: включает удалённый
  рабочий стол с NLA, привязывает сертификат к порту 7440, регистрирует службу
  и показывает одноразовый код регистрации ключа на последней странице, на
  языке Windows. Тихо: `msiexec /i RdpFidoGate-Setup.msi /qn`.

## 1.12.x — 30.08.2026

- Подписанные лицензия и манифест обновлений, баннеры с картинками по выбору
  сервера с офлайн-ротацией, контроль порта RDP, неудачные вызовы шлюза
  записываются в `client.log`.