Roadmap dix.su¶

Приоритизированный список направлений развития платформы.
Основан на анализе конкурентного ландшафта, пользовательских сценариях и техническом долге.

Статус документа

Живой документ — обновляется по мере изменения приоритетов. Статусы: 🔴 Критично · 🟡 Важно · 🟢 Желательно · ✅ Готово · 🚧 В работе · 📋 Запланировано

1. UDP-туннели¶

Приоритет: 🔴 Критично
Статус: 📋 Запланировано

Проблема. WebSocket-транспорт работает поверх TCP. UDP не поддерживается в принципе (features_and_gaps.md). Закрытые сценарии: Minecraft Bedrock/Java, DNS-серверы, VoIP/SIP/RTP, IoT-протоколы (CoAP, DTLS), WireGuard, медиастриминг.

Конкурентный контекст. fxTunnel (от $5/мес), LocalToNet, playit.gg, Pangolin — поддерживают UDP. Для части аудитории это блокирующий gap.

Предлагаемая архитектура.

device_client  ←—WebSocket—→  dixu_proxy  ←—UDP—→  внешний порт

Отдельный UdpListener на сервере выделяет публичный UDP-порт из диапазона (например, 20000–30000) и форвардит дейтаграммы через существующий WebSocket-канал (фреймирование: длина + payload). Клиент декодирует и отправляет на локальный UDP-порт устройства.

Ограничение: UDP stateless — нет гарантий доставки и порядка. Для большинства UDP-приложений это норма (они и так работают с потерями), но нужно документировать явно.

Оценка. ~3–4 недели: серверный UdpForwarder, расширение протокола device_client, UI-поддержка нового типа туннеля.

2. HTTP Request Inspector¶

Приоритет: 🟡 Важно
Статус: 📋 Запланировано

Проблема. Для dev-аудитории отладка webhook'ов и API-запросов без inspector — неудобство. ngrok, Portr, Packetriot, fxTunnel (платные планы) — все имеют.

Минимальная реализация (MVP).

В dixu_proxy добавить промежуточный слой для HTTP-туннелей: буферировать входящий запрос → проксировать на устройство → сохранять в кольцевой буфер (последние N запросов) в памяти per-slug.

Dashboard получает запросы через LiveView/WebSocket в реальном времени. Отображает: метод, URL, заголовки, тело запроса, статус ответа, время ответа.

Replay. Повторная отправка сохранённого запроса: POST /api/tunnels/:slug/replay/:request_id. Полезно при разработке без необходимости вручную генерировать запросы.

Ограничения MVP: только HTTP (не TCP), только пока туннель активен (буфер in-memory), не сохраняется в БД.

Оценка. ~2 недели на MVP без replay; +1 неделя на replay.

3. Метаданные устройства при подключении¶

Приоритет: 🟡 Важно
Статус: 📋 Запланировано

Проблема. Пользователь видит в кабинете «Туннель активен», но не знает с какого устройства, с каким IP, на какой ОС запущен клиент. При нескольких устройствах или после автозапуска — невозможно понять что к чему.

Решение. При установке WebSocket-соединения device_client отправляет в первом сообщении (или как часть существующего handshake) блок метаданных:

{
  "type": "hello",
  "slug": "my-server",
  "token": "...",
  "device": {
    "hostname": "raspberrypi",
    "os": "linux",
    "os_version": "Debian GNU/Linux 12 (bookworm)",
    "arch": "arm64",
    "local_ips": ["192.168.1.100", "10.0.0.5"],
    "client_version": "1.4.2",
    "started_at": "2026-09-27T10:30:00Z"
  }
}

Сбор на стороне device_client:

hostname — os.Hostname() (Go) / :inet.gethostname() (Elixir)
os / os_version — /etc/os-release на Linux, sw_vers на macOS, winver на Windows
arch — runtime.GOARCH / System.arch()
local_ips — net.InterfaceAddrs(), фильтр: только IPv4, без loopback и link-local
client_version — embed при сборке через ldflags
started_at — время старта процесса

Хранение. В таблице tunnel_sessions (или device_connections): поле device_meta jsonb. Обновляется при каждом подключении. Не хранить дольше активной сессии по умолчанию (приватность).

Dashboard. При активном туннеле показывать:

● Активен с 27 сент. 10:30
  raspberrypi · Debian 12 · arm64
  192.168.1.100

Оценка. ~1 неделя: изменения в device_client, протоколе, БД, UI.

4. `dixsu-find` — диагностика запущенного клиента¶

Приоритет: 🟡 Важно
Статус: 📋 Запланировано

Проблема. Пользователь видит «Туннель уже активен — остановите текущее подключение на устройстве прежде чем настраивать новое», но не знает как именно был запущен клиент: как systemd-сервис, OpenRC, Docker, или просто в терминале.

Решение. Скрипт dixsu-find (или встроенная команда device_client status) который:

Проверяет systemd: systemctl list-units | grep dixsu
Проверяет OpenRC: rc-status -a | grep dixsu
Проверяет Docker: docker ps | grep device_client
Проверяет plain-процесс: pgrep -a -f device_client
Показывает PID, uptime, конфиг-файл, slug
Показывает активные соединения к серверам dix.su: ss -tnp | grep dix.su
Даёт команду для остановки в каждом из найденных вариантов

Итоговый вывод скрипта:

=== dix.su Tunnel Diagnostics ===

► systemd service: dixsu-device-client
  Active: active (running) since 2026-09-27 08:12:01
  PID: 1337, uptime: 2h14m
  Stop: systemctl stop dixsu-device-client

► Network connection:
  192.168.1.100:54321 → 217.114.43.49:443 (ESTABLISHED)

No other dix.su processes found.

Реализация. Shell-скрипт dixsu-find.sh, распространяется вместе с документацией и через dix.su/downloads/. Также добавить подкоманду device_client find / device_client status в Go/Elixir клиент.

Оценка. Shell-скрипт — 1–2 дня.

5. Desktop-клиент / Daemon mode¶

Приоритет: 🟢 Желательно
Статус: 📋 Запланировано

Проблема. fxTunnel имеет Desktop GUI (Wails). У dix.su — только CLI и Android CIFS-клиент.

Подходы по возрастанию сложности:

5a. Daemon + systemd/launchd installer (минимум, ~1 нед.). Команда device_client install создаёт unit-файл и запускает сервис. device_client uninstall — удаляет. Решает большую часть проблемы «как запускать постоянно».

5b. System tray (tray icon, ~2–3 нед.). Минимальный tray-агент (Tauri или wails) — иконка в трее, пункты: «Статус / Остановить / Перезапустить / Открыть кабинет». Без полноценного окна.

5c. Full Desktop GUI (~1–2 мес.). Полноценное приложение с логами, конфигурацией, управлением туннелями. Сравнимо с fxTunnel GUI.

Рекомендация: начать с 6a (installer) — даёт максимальный UX-эффект при минимальных затратах.

6. Упрощение self-hosted деплоя¶

Приоритет: 🟢 Желательно
Статус: 📋 Запланировано

Проблема. fxTunnel: один Docker-образ, один порт-диапазон, один конфиг-файл. dix.su: многоконтейнерный стек (nginx, dixu_proxy, modulauth, postgres, redis, certbot, docsite), сложный первый запуск.

Направления: - dixsu-infra/quickstart/ — минимальный docker-compose только с core-сервисами (без docsite, screenshotter) - make setup — интерактивный wizard: домен → токены → запуск - Документ deployment.md с чётким разделением «минимальный» vs «полный» стек

Сводная таблица¶

#	Задача	Приоритет	Оценка	Статус
1	UDP-туннели	🔴 Критично	3–4 нед	📋
2	HTTP Request Inspector	🟡	2–3 нед	📋
3	Метаданные устройства в «Подключениях»	✅	—	✅
4	`dixsu-find` диагностический скрипт	🟡	1–2 дня	📋
5a	Daemon installer (systemd/launchd)	🟢	1 нед	📋
5b	System tray	🟢	2–3 нед	📋
5c	Full Desktop GUI	🟢	1–2 мес	📋
6	Упрощение self-hosted деплоя	🟢	1–2 нед	📋

Уже реализовано (конкурентные преимущества)¶

Функция	Статус
E2E Private Mode (Phase 1+2)	✅ Задеплоено
Device-first модель + dashboard	✅ Реализовано
HTTP + TCP (SSH/RDP/VNC/DB)	✅ Реализовано
Профиль/визитка (dix.su/p/slug)	✅ Реализовано
Репутация и отзывы (Otzovik)	✅ Реализовано
Android CIFS Documents Provider	✅ v2.4.0
Резервный mgmt-туннель	✅ Задокументировано
Короткие ссылки с авторством	✅ Реализовано
Anti-abuse (rate-limit, slug bruteforce)	✅ Реализовано
Биллинг (T-Bank/RU)	✅ Активно

Обновлено: 2026-09-27. Основано на сравнительном анализе с alternatives.md.

Roadmap dix.su¶

1. UDP-туннели¶

2. HTTP Request Inspector¶

3. Метаданные устройства при подключении¶

4. dixsu-find — диагностика запущенного клиента¶

5. Desktop-клиент / Daemon mode¶

6. Упрощение self-hosted деплоя¶

Сводная таблица¶

Уже реализовано (конкурентные преимущества)¶

4. `dixsu-find` — диагностика запущенного клиента¶