- C++ 95.8%
- Python 1.9%
- Objective-C++ 0.7%
- CMake 0.6%
- CSS 0.2%
- Other 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Article paragraphs wrapped in the middle of words. The logs from the previous dev build named the cause outright: the per-grapheme breaking in Ui::Text kicks in once a word is wider than the string's minimum resize width, and for article body text that width was 93px — while "сожжённых" measures 98px, "стабильную" 100px and "контринтуитивное" 98px. Every word from nine letters up crossed it, so almost every line broke mid-word. Chat text was fine because its threshold is 195px and only long URLs reach it. The number comes from ReadableTextMinWidth(), four line heights. Raise it to thirteen, about 300px. The two meanings of the value stay consistent that way: a word that would now overflow the block is still narrower than the narrowest the block can get, so nothing sticks out. Tables and code blocks compute their own minimums and are untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
| .claude | ||
| .codex/skills/tdesktop-local-release | ||
| .github | ||
| cmake@80cd031dc4 | ||
| docs | ||
| lib/xdg | ||
| snap | ||
| Telegram | ||
| .cursorignore | ||
| .devcontainer.json | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| AGENTS.md | ||
| changelog.txt | ||
| CMakeLists.txt | ||
| LEGAL | ||
| LICENSE | ||
| README.md | ||
| REVIEW.md | ||
ZaStoGram Desktop
ZaStoGram — форк Telegram Desktop, заточенный под работу в сетях с DPI‑цензурой и под приватность. Цель проекта: чтобы клиент уверенно подключался там, где обычный Telegram режут, маскировал трафик под обычный браузерный HTTPS и не терял переписку (удалённые сообщения, истории, правки).
Это неофициальная сборка. Она основана на исходниках официального клиента и сохраняет весь его функционал, добавляя сверху сетевой стелс, WSS‑транспорт и набор приватных функций.
⚠️ Используйте на свой риск. Проект не связан с Telegram FZ‑LLC. Базовый код — под GPLv3 с OpenSSL‑исключением (см. раздел «Лицензия»).
Чем отличается от обычного Telegram Desktop
| Область | Что добавлено |
|---|---|
| Обход DPI | FakeTLS‑стелс: профили ClientHello, правдоподобные повторные TLS‑подключения через поддельные билеты возобновления, маскировка старта, фрагментация ClientHello, варьирование размера TLS‑записей, пейсинг трафика, разнос попыток подключения |
| Надёжность | Классифицированный loop‑backoff переподключения (cap 8 c), деприоритизация «залипших» endpoint'ов (cooldown) |
| Транспорт | Встроенный WSS (MTProto поверх WebSocket к web‑релею Telegram) |
| Прокси | Обязательный прокси (force‑proxy) + дефолтный локальный SOCKS5 127.0.0.1:1353 |
| Приватность | Сохранение удалённых сообщений и историй (stories), скачивание любых (даже защищённых) историй, история правок сообщений |
| Скорость подключения | Убраны две клиентские задержки, найденные измерением: очередь дозвонов (было до 8 с ожидания на поздних сокетах) и невыключенный алгоритм Нейгла |
| Производительность | Ограничение числа потоков софт‑декодера видео, троттлинг под нагрузкой |
| UX | Список прокси больше не устраивает «шквал» проверок при открытии |
| Бренд | Имя и иконка ZaStoGram |
🛡️ Обход DPI — стелс MTProxy
Когда задан MTProxy (FakeTLS), клиент маскирует подключение под настоящий браузерный TLS‑хэндшейк. Всё настраивается тумблерами в окне прокси (Настройки → Продвинутые → Тип соединения → список прокси).
- Профиль ClientHello — ClientHello воспроизводит форму реального браузера/приложения:
Auto (Yandex),Auto‑rotate,Firefox,Firefox Android,Yandex,Android OkHttp. ПрофилиChrome ModernиAndroid Chromeостались в таблице, но больше не отправляются: измерением найдено, что фильтрующая сеть отвергает именно их — 3 попытки из 12 против 12 из 12 у остальных, на одном релее в одни минуты. Выбранный вручную отключённый профиль автоматически заменяется на рабочий. - Маскировка старта (startup‑cover) — первые записи разбиваются и подаются так, чтобы начало сессии не выделялось характерным паттерном.
- Фрагментация ClientHello — ClientHello дробится при отправке, чтобы DPI было сложнее собрать и распознать его целиком.
- Варьирование размера TLS‑записей — размеры записей не фиксированы, что ломает сигнатуры по длине.
- Пейсинг трафика — межзаписевые задержки на старте сглаживают «взрывной» профиль (без удушения уже установленного потока).
- Разнос попыток подключения — попытки к нескольким endpoint'ам стартуют со сдвигом, а не пачкой. Сдвиг намеренно небольшой (50 мс): измерение показало, что релеи спокойно принимают два десятка одновременных рукопожатий, а большой разнос стоил секунд на старте — подробности в разделе про задержку.
- Правдоподобные повторные TLS‑подключения — первый ClientHello к узлу и имени назначения идёт без PSK, как обычный «холодный» заход браузера. После успешного fakeTLS‑хэндшейка клиент держит небольшой локальный пул поддельных билетов возобновления с ограниченным временем жизни и при повторных подключениях отправляет один из них с нормальным возрастом. Это убирает подозрительный паттерн «каждый параллельный сокет приносит новый случайный PSK» и делает повторные подключения похожими на обычный браузерный HTTPS. Эти билеты нужны только для маскировки, не используются для шифрования MTProto и не сохраняются на диск.
Надёжность подключения
- Loop‑backoff — классифицированные таймауты переповтора, привязанные к прокси, с верхней границей, чтобы не зацикливаться на мёртвом узле и не спамить коннектами.
- Endpoint cooldown — endpoint, который только что отвалился, временно понижается в приоритете (а не выбрасывается), чтобы клиент пробовал живые маршруты, не теряя резервные.
🌐 WSS‑транспорт
Встроенный MTProto‑over‑WebSocket (чистая реализация на QSslSocket + RFC 6455): настоящий TLS → HTTP‑upgrade (GET /apiws) → бинарные WS‑фреймы, внутри которых идёт обфусцированный MTProto‑поток. Подключается к официальным web‑релеям Telegram (kws2/kws4.web.telegram.org) для DC2/DC4.
Включается тумблером «Route via WSS (web, DC2/DC4 only)». Полезен там, где прямой TCP к DC блокируется, но веб‑Telegram работает. Может ходить как напрямую, так и через заданный SOCKS‑прокси.
Альтернатива встроенному WSS — внешний локальный прокси (telegram_proxy из zapret‑набора) на 127.0.0.1:1353, к которому клиент подключается по SOCKS5 (см. ниже).
🔌 Прокси: обязательный + дефолтный
- Force‑proxy — без выбранного прокси клиент не выходит в сеть; «щит» соединения виден всегда. Исключение — включённый режим WSS (он сам является методом обхода). Это страховка от случайного прямого подключения в опасной сети.
- Дефолтный SOCKS5
127.0.0.1:1353— добавляется в список один раз (если такого ещё нет; существующие прокси не перетираются). Это endpoint внешнего сервисаtelegram_proxy: схемаtdesktop → SOCKS5 1353 → telegram_proxy → WSS/FakeTLS → Telegram.
🔒 Приватность
Клиент‑сайд функции, которые сохраняют данные локально (по умолчанию включены):
- Сохранение удалённых сообщений — когда сервер присылает «удалить», сообщение не уничтожается локально, а остаётся (помечается как удалённое отправителем). Переписка не пропадает.
- Сохранение историй (stories) — локальный снэпшот историй с восстановлением при старте; истории не исчезают по истечении срока.
- Скачивание любых историй — медиа истории сохраняется на диск даже для защищённых от пересылки (noforwards) и чужих историй, без Premium (снят клиентский гейт canDownload).
- История правок — при редактировании сообщения предыдущие версии (текст + время) сохраняются, чтобы видеть, что было изменено.
Это локальные функции: они не влияют на сервер и не нарушают шифрование. Хранение части данных может быть только в памяти до перезапуска (персистентность отдельных частей — в развитии).
⚡ Производительность
- Decoder policy — централизованное ограничение числа потоков софтверного видео‑декодера и троттлинг запуска декодеров под нагрузкой, чтобы тяжёлые медиа не «съедали» CPU и не плодили лишние декодеры.
Задержка подключения: что было измерено и убрано
Жалобу «через прокси медленно, пинг большой» обычно списывают на сеть. Мы разложили её на слои и померили с двух машин — на сети с фильтрацией и без неё:
| слой | что это | типичные значения |
|---|---|---|
| TCP | до релея | 11–70 мс |
| FakeTLS | релей отвечает сам | 9–71 мс |
| resPQ | релей → Telegram → релей | 55–94 мс суммарно |
Оказалось, что фильтрация к задержке не добавляет ничего: на одном и том же релее сеть с блокировками и сеть без них дали 17/55 мс против 11/56 мс. Секунды создавал сам клиент, и нашлось два источника.
- Очередь дозвонов. Попытки к одному релею разносились на 250 мс, а холодный старт открывает десятки сокетов — поздние ждали своей очереди секундами (в логе
tcp_msдоходил до 8666 мс при сетевом round trip 17 мс). Разнос вводился ради маскировки, но измерение показало, что цена ему не соответствует: 24 дозвона вообще без разноса дошли до Telegram все 24, вся пачка за 170 мс, тогда как через очередь те же 24 стоили около шести секунд. Разнос снижен до 50 мс — этого хватает, чтобы соединения приходили различимо, а не одним мгновением. Рост разноса при неудачах не тронут: именно он защищает релей, который действительно не тянет пачку. - Алгоритм Нейгла.
TCP_NODELAYне выставлялся ни на одном сокете. Нейгл придерживает короткую запись, пока не подтверждена предыдущая, а MTProto устроен ровно так: короткий запрос, затем ожидание. Тонкость, из‑за которой это легко сделать вхолостую: Qt применяет опции сокета через движок, который появляется только после установления соединения, поэтому выставлять их надо в обработчикеconnected, а не в конструкторе.
Обе правки закрыты тестами, которые держат числа рядом с константой — чтобы следующий, кто захочет вернуть разнос, спорил с измерением, а не с догадкой.
Как выбирать релей по скорости. Сравнивать надо не пинг до релея, а сумму: путь до него плюс путь от него до дата‑центра Telegram. Релей с отличным пингом, но далёкий от Telegram, на практике медленнее скромного, стоящего рядом с ним — в наших замерах два релея различались вдвое по суммарному времени именно из‑за этого.
🧰 Спокойная архитектура прокси
- Список прокси не запускает проверку всех строк при открытии окна — это убирает «шквал» одновременных тестовых коннектов. Строки по умолчанию в состоянии Unknown; проверка запускается вручную по пункту Check Status.
🗺️ Roadmap (запланировано, ещё не реализовано)
- Глобальный лимитер MTProxy‑handshakes — в текущем Desktop каждый аккаунт держит свой
MTP::Instanceсо своей DC‑сессией (разные auth keys, msg_id/seqno, salt), поэтому «один общий поток» для всех аккаунтов сделать нельзя без серверной поддержки. Вместо этого планируется безопасный лимитер: общий cap на число одновременных MTProxy‑handshakes между аккаунтами + jitter/backoff + очередь; снижение числа активных проверок ротации (10 → 1–2); кэширование статусов прокси; единый gate для всехStartProxyCheckи рабочих handshakes. Это сгладит всплеск подключений, не душа уже установленный трафик. - UI приватности — видимая метка «удалено» на сохранённых сообщениях и просмотрщик истории правок (контекст‑меню).
🏗️ Сборка и CI
- Сборка идёт через GitHub Actions (
.github/workflows/win.yml): только Windows, конфигурацииx64иx64_x86(Qt5). После каждого пуша автоматически публикуется пре‑релизdev-Nс готовыми.exe. - Зависимости (Qt, Libraries, ThirdParty) кэшируются между запусками.
- Инструкции по ручной сборке официального клиента (применимы и здесь) — в
docs/.
Базовый клиент собирается стандартным тулчейном Telegram Desktop. Артефакты пре‑релиза переименовываются в
ZaStoGram-<arch>.exe.
📥 Установка
Скачайте ZaStoGram-x64.exe (или x64_x86 для 32‑бит) из раздела Releases (пре‑релиз dev-N). Это сборка из исходников этого репозитория. Для работы дефолтного прокси 127.0.0.1:1353 нужен запущенный внешний сервис telegram_proxy, либо включите встроенный WSS‑транспорт.
📄 Лицензия
Проект основан на Telegram Desktop и распространяется под GPLv3 с OpenSSL‑исключением — тот же текст лицензии, что и у апстрима, см. LICENSE и LEGAL.
ZaStoGram — независимый форк; товарные знаки Telegram принадлежат их владельцам.