Мессенджеры *

😎 Привет Халчане!

Давно не виделись, много чего произошло)

Сегодня вышло обновление HalChat for Android v1.0.4 (AI in every phone!)
Благодаря новым технологиям, стало возможно запускать даже 8 млрд. модели на бюджетных телефонах
Среднее время ответа ИИ на Honor X7b составляет от 3 до 4 минут
Можно почти одновременно общаться в одном чате как на ПК, так и на мобильном устройстве

Самое трудное было это перенести систему плагинов на Android.
Она может работать в оффлайн режиме, что позволяет общаться с ИИ без интернета (но пока отключено)

Кроме этого были добавлены статусы сообщениям (доставлено или отправлено)
Добавлены статусы пользователя в личном чате

Было проведено много работы над багами, оптимизацией, улучшением синхронизации и обновлению системы файлов.
На этой неделе я расскажу как я смог запустить в браузере 27b модель с минимальными потерями. И как я дообучил модель для HalChat.

Бесплатно попробовать 3 новых ИИ можете в:
Google Play: https://play.google.com/store/apps/details?id=halwarsing.net.halchatandroid
RuStore: https://www.rustore.ru/catalog/app/halwarsing.net.halchatandroid

🤝 До новых встреч!

В Telegram Desktop до версии 7.2.9 обнаружена уязвимость CVE-2026-107181, эксплуатация которой позволяет украсть любой файл с компьютера после одного клика по ссылке без подтверждения от пользователя. Из‑за отсутствия экранирования разделителя; параметры в ссылках схемы tg:// распознавались как отдельные IPC‑команды. С помощью служебного обработчика interpret: атакующий мог при клике на подготовленную ссылку незаметно отправить файлы с системы в свой канал без подтверждения со стороны пользователя.

Опасность не ограничивается только перехватом файлов сессии tdata и угоном аккаунта. Эксплуатация позволяет скрытно украсть любые файлы на рабочем ПК в сети, к которым у пользователя есть доступ: документы, сохранённые сессии браузеров, SSH‑ключи, системные конфигурации или кошельки с криптовалютой.

Подписка уже продлена, а бот всё равно просит оплатить

У отложенных уведомлений есть неприятный сценарий: задача выполняет решение, принятое несколько минут назад, хотя состояние подписки уже изменилось.

Рассмотрим Telegram-бота, который сам хранит сроки доступа и отправляет уведомление после их окончания. Условный пример:

— 12:00 — доступ закончился, планировщик создал задачу «предложить продление»;
— 12:01 — отправка получила 429 с retry_after=120 и перенесена на 12:03;
— 12:02 — пользователь оплатил следующий период, обработчик платежа зафиксировал новый access_until в БД;
— 12:03 — воркер повторил отправку старого сообщения: «Ваш доступ закончился. Продлите подписку».

В документации Telegram retry_after означает, сколько секунд нужно подождать до повторного запроса. Успех следующей попытки он не гарантирует. За время ожидания основание для уведомления может исчезнуть.

Поэтому в очереди я бы хранил контекст задачи:

• subscription_id — идентификатор конкретной подписки

• expected_access_until — срок доступа, для которого создано уведомление

• not_before — время, раньше которого отправку не предпринимаем

• valid_until — момент, после которого напоминание теряет смысл по правилам продукта

Перед каждой попыткой воркер читает состояние из источника, где видно уже зафиксированное продление. Например, с primary в новой короткой транзакции. Отстающая реплика или старый снимок транзакции могут вернуть прежний срок доступа, даже если платёж уже обработан.

Для нашего примера условия отправки такие:

— not_before <= now < valid_until;
— текущий access_until совпадает с expected_access_until;
— текущий access_until <= now;
— правила продукта разрешают предложить продление этой подписки.

Время сравниваем в одной временной шкале, например UTC.

Если срок доступа изменился, задача создана для прежнего состояния. Её отменяем, а необходимость и время нового уведомления определяем по текущим данным. Изменение access_until не обязательно означает новый период: это может быть компенсация или административная корректировка.

Если valid_until уже наступил, задачу пропускаем. Если БД недоступна, отправку откладываем с учётом этого дедлайна. Ошибка чтения сама по себе не означает, что доступ закончился.

Удаление старой задачи из очереди может сократить лишнюю работу, но проверку в воркере я бы всё равно оставил: задачу уже могли забрать на выполнение.

Актуальность и защиту от дублей нужно проверять отдельно. Даже напоминание, отправленное один раз, может содержать устаревшую информацию. Ключ вроде subscription_id + expected_access_until + notification_type помогает группировать повторы задачи для одного срока доступа, но сам по себе не гарантирует единственную отправку в Telegram.

Остаётся окно между финальным чтением БД и sendMessage: продление может быть обработано именно в этот момент. Проверка уменьшает окно гонки, но не закрывает его. Координация операций по подписке позволяет упорядочить решения внутри системы; одна транзакция БД внешний вызов Telegram не охватывает. И даже корректное на момент отправки сообщение может устареть до прочтения.

Для проверки я бы взял продление до запуска воркера, во время retry_after и между чтением БД и отправкой. Отдельно — наступление valid_until и недоступность БД.

Пропуски с причинами access_until_changed и deadline_expired стоит учитывать отдельно от ошибок отправки: они показывают, сколько работы устарело в очереди.

Поделитесь как вы разделяете продление между проверкой и отправкой? Координируете операции по subscription_id или допускаете это окно и делаете текст уведомления менее категоричным?

Ссылка на одного участника в Telegram — ещё не персональный доступ

Представим закрытый канал: бот подтвердил оплату и выдал покупателю ссылку с member_limit=1. Кажется, что схема защищена: один платёж — один участник. Но лимит не проверяет, кто именно вступает.
По документации Telegram, member_limit ограничивает число пользователей, которые могут одновременно состоять в чате, вступив по этой ссылке. Это не привязка к Telegram ID покупателя и не гарантия одного использования за всё время.

Пример: Анна оплатила доступ и переслала приглашение Борису. Борис вступил первым. Лимит соблюдён, но доступ получил другой аккаунт. Даже если ссылка действует пять минут, переслать её можно за несколько секунд.

Здесь речь об обычных приглашениях, когда доступом управляет бот. Нативные платные ссылки Telegram Stars — отдельный механизм.
На мой взгляд, проверять нужно право конкретного пользователя на вход. Приглашение позволяет подать заявку, а решение принимается по актуальным правам аккаунта.

Для обычных chat_join_request без query_id схема такая:

1. Бот создаёт ссылку с creates_join_request=True, без member_limit: эти параметры нельзя использовать одновременно.

2. При получении заявки берёт chat.id и from.id, проверяет действующее, не отозванное право пользователя на конкретный чат.

3. При положительном решении вызывает approveChatJoinRequest. Боту нужны права администратора с can_invite_users.

Допустим, доступ оформлен для user_id=101 в канал A. Приходит заявка от user_id=202, у которого такого права нет. Само наличие приглашения не становится основанием для одобрения. И наоборот: оплата канала A не должна автоматически открывать канал B.
Если разрешены подарки, получателя доступа нужно определить заранее. С заявкой сравнивается его Telegram ID, который может отличаться от ID плательщика.

Отдельный случай — задержка обработки оплаты. Он возможен при общей ссылке на заявки, доступной ещё до покупки. В случае если приглашение выдаётся только после записи права доступа, заявка по нему уже не может опередить эту запись.

Условная последовательность для общей ссылки:

— 12:00:00 — пользователь оплачивает подписку;
— 12:00:02 — приходит заявка, но обработчик платежа ещё не создал право доступа;
— 12:00:05 — подтверждение оплаты обработано, право записано.

Заявку для повторной проверки с ограниченным временем ожидания я бы сохранял. После обработки платежа можно заново проверить актуальный доступ и попробовать одобрить заявку. Скриншота платежа для этого недостаточно. Если БД недоступна, автоматическое одобрение тоже следует отложить.
Это относится к обычным заявкам. Для событий с query_id действует другой протокол: в течение 10 секунд нужно вызвать answerChatJoinRequestQuery или sendChatJoinRequestWebApp. Переносить туда ту же логику ожидания без изменений нельзя.

Срок приглашения и срок подписки тоже нужно разделять. Например, ссылка действует пять минут, а доступ оплачен на месяц. Истечение expire_date не удаляет уже вступившего участника. За окончание доступа отвечает отдельная логика.
Проверка заявки защищает только этот способ вступления. Другие ссылки без одобрения и действия администраторов тоже нужно учитывать. Копирование самого контента она не предотвращает.

Собственная система нужна не всегда: для ежемесячного доступа в один канал у Telegram есть платные пригласительные ссылки с оплатой Stars. Дополнительная модель прав становится полезной, когда продукт объединяет несколько чатов и тарифов.

Отсюда вопрос: как вы организуете приглашения, отдельной ссылкой на каждого получателя или общей ссылкой с проверкой каждой заявки? Какие различия заметили в аудите восстановлении доступа?

Как превратить задержку в главную функцию продукта

Пока мессенджеры соревнуются в скорости, Roost выбрал обратную механику: сообщения доставляют виртуальные птицы с реальной скоростью. Путь в соседний город занимает часы, на другой континент — дни.

Приложение создал один продакт-менеджер без команды и инвестиций, используя Claude Code. За пять недель проект вырос почти до 300 тысяч пользователей благодаря органическому распространению.

Технически и продуктово здесь важна не симуляция птиц, а смена роли ограничения. Задержка не маскируется и не оптимизируется — она становится интерфейсом, ожиданием и причиной писать более осознанно.

Получился парадокс: ИИ ускорил разработку продукта, который намеренно замедляет коммуникацию.

Подробнее — в моём Telegram-канале «Идеи для ИИ — Андрей Анисимов». Ссылка в профиле.

Московский суд признал основным доказательством переписку в Telegram по делу о принудительном возврате долга.

Мужчина попросил у знакомого 365 тыс. рублей и пообещал в мессенджере вернуть деньги в срок с процентами в размере 91 тыс. рублей. Когда заёмщик отказался возвращать средства, мужчина пошёл в суд. Московский суд подтвердил, что аккаунты в мессенджере привязаны к номерам телефонов истца и ответчика и проверил банковские выписки, свидетельствующие о переводе денег. Переписку, подлинность которой была удостоверил нотариус, судья счёл договором. В итоге должника обязали вернуть почти полмиллиона рублей с учётом судебных расходов.

«Между истцом и ответчиком в соответствии со статьёй 434 ГК РФ фактически были установлены заёмные правоотношения… Указанная переписка, подтверждающая условия займа и срок возврата, является надлежащим доказательством в суде», — говорится в решении суда.

Если вы пользуетесь Linux и регулярно созваниваетесь через Discord, Teams, Telegram, Телемост и другие программы, то наверняка сталкивались с проблемой шумоподавления.

Где-то встроенный шумодав работает нормально, где-то его нет вообще.

Я раньше использовал NoiseTorch (долго и велосипедно настраивать), пробовал EasyEffects (очень громоздко и избыточно). А недавно нашёл HushMic.

Устанавливаешь, запускаешь, выбираешь свой физический микрофон — и получаешь отдельный виртуальный источник уже с шумоподавлением. И всё это настраивается буквально за пару минут и кликов.

https://github.com/Fovty/HushMic

В Telegram появился WEB‑прокси: как мессенджер учится притворяться обычным сайтом и чем это отличается от SOCKS5 и MTProto

В конце августа пользователи обратили внимание, что в Telegram появился новый тип подключения — Web-прокси. Одновременно разработчики выложили открытый репозиторий telegramdesktop/tproxy-server.

Что это за зверь и почему классические прокси проигрывают цензуре?

Любой прокси-сервер — это посредник между вашим устройством и конечным сервисом. Разница в том, как именно этот посредник передает ваши данные и насколько он заметен для систем DPI (глубокого анализа пакетов):

• Прямое подключение (без посредников): Пакеты летят напрямую в подсети Telegram. Провайдер сразу видит целевые IP-адреса мессенджера или характерные сигнатуры и обрубает соединение.

• Обычный прокси (SOCKS5): Протокол передает данные и рукопожатие открытым текстом. DPI давно умеет распознавать сигнатуры протокола, в текущих реалиях прокси работают плохо.

• MTProto с Fake-TLS: Притворяется HTTPS-сессией к чужому, как правило популярному ресурсу (google.com). Но у прокси нет настоящего SSL-сертификата и ключей от чужого домена. Цензоры научились слать на подозрительный сервер проверочные запросы, в случае получения нехарактерного для указанного домена ответа, соединение банится.

• WEB-прокси: Telegram заворачивает трафик в стандартные веб-протоколы (HTTPS / WebSocket) через встроенный движок браузера. Запрос идет на обычный домен с настоящим SSL-сертификатом от Let's Encrypt. Снаружи на этом адресе висит реальный сайт (даже обычный одностраничник), поэтому любая автоматическая проверка видит обычный веб-серфинг.

В чем главная техническая хитрость?

Telegram не стал изобретать собственный велосипед для маскировки TLS-отпечатков, а просто использует встроенный системный движок браузера.

Для DPI провайдера такое соединение неотличимо от ситуации, когда пользователь просто открыл вкладку в браузере и смотрит страничку.

Как устроен tproxy-server

Что мы видим в репозитории telegramdesktop/tproxy-server:

1. Сервер слушает только веб-порты (80 и 443). Все служебные порты остаются внутри локального сетевого интерфейса.

2. Обязательный сайт-прикрытие. Разработчики специально не добавили в репозиторий готовый шаблон сайта, чтобы исключить слепое копирование (защита от дурака). В документации так и сказано — если тысячи операторов поставят один и тот же дефолтный лендинг, по нему создадут сигнатуру. Сервер требует настроить проксирование на любой реальный сайт (блог на WordPress, документацию, портфолио или страницу на React/Node.js).

3. Разделение потоков. Когда на порт 443 приходит проверяющий, робот или случайный посетитель — сервер возвращает обычные HTML/CSS-страницы. Но если по специальному пути приходит клиент Telegram с валидным секретным ключом, соединение проксируется на внутренний демон mtproto-proxy.

Что нужно, чтобы поднять свой WEB-прокси?

Для самостоятельного развертывания понадобится собственный VPS за пределами зон фильтрации (подойдет любой недорогой виртуальный сервер, главное, чтобы он не был заблокирован), доменное имя (любой недорогой домен в свободной зоне (.xyz, .site, .top или .com/.net), SSL-сертификат (выпускается автоматически через Let's Encrypt или ZeroSSL).

Также нужно будет оформить сайт-фасад (сделать на домене статичную веб-страницу, чтобы сайт выглядел как сайт и не вызывал подозрений) и понадобится также секретный ключ, который Генерируется стандартной утилитой openssl rand -hex 16.

Главный плюс такого подхода заключается в том, что если домен попадет под блокировку, ничего не придется перенастраивать с нуля. Достаточно будет зарегистрировать новый домен за, направить DNS-запись на тот же IP-адрес и перевыпустить сертификат. И WEB-прокси снова работают.

Наконец мой мессенджер прошёл тест в Google Play . За время тестирования он научился совершать звонки по udp. Это позволило по udp получать не только голос, но и пинок от сервера на проверку сообщений в реальном времени. Осталось придумать как без внешних сервисов, вроде FCM, не засыпать вместе с системой и не давать андроиду прибить процесс приложения, чтоб принять udp пендаль в любое время. Так как мессенджер ориентирован на пользователей роутеров Mikrotik, на роутер и была возложена такая задача. Не давать телефону спать :). В качестве энергетика будет выступать DHCP Lease. В приложении я подписываюсь на изменения параметров сети, и выполняю задачу в обычном executor.

private void registerNetworkCallback() {
        ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
        if (connectivityManager != null) {
            connectivityManager.registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() {
                @Override
                public void onAvailable(@NonNull Network network) {
                    isNetworkActive.set(true);
                    if (userId > 0) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                    offlineHandler.removeCallbacks(resetStatusesRunnable);
                    Log.d(LOG_TAG, "Network: WiFi Connected. " + network);
                }

                @Override
                public void onLinkPropertiesChanged(@NonNull Network network, @NonNull LinkProperties linkProperties) {
                    Log.d(LOG_TAG, "LINK CHANGED DNS=" + linkProperties.getDnsServers());
                    if (userId > 0 && isNetworkActive.get()) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                }

                @Override
                public void onLost(@NonNull Network network) {
                    isNetworkActive.set(false);
                    offlineHandler.postDelayed(resetStatusesRunnable, 15000);
                    Log.d(LOG_TAG, "Network lost. Scheduled offline reset in 15s...");
                }
            });
        }
    }

который тригерится в том числе и на изменение списка DNS серверов. В роутере я указываю время аренды DHCP для подключённых устройств 6 минут. Соответственно устройства будут обновлять аренду каждые 3 минуты. С таким же интервалом 3 минуты, скриптом меняем список DNS серверов для локальной сети.

:local netId [/ip dhcp-server network find address="192.168.88.0/24"];
:local currentDns [/ip dhcp-server network get $netId dns-server];
:if ($currentDns = "192.168.88.1,8.8.8.8") do={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.4.4";
} else={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.8.8";
}

Этих трёх минут вполне хватает чтоб не заснуть, и пингануть разочек сервер для прогрева udp порта.

Расход заряда в планшете с таким энергетиком от роутера я специальными приборами не замерял. Но на глазок, за 12 часов бездействия ни одного процента зарядка не потяряла, и через 12 часов и планшет и телефон приняли и звонок и сообщение мгновенно.

В Bot API 10.3 появилась остановка генерации. Но LLM-запрос придётся отменять самому

24 августа вышел Telegram Bot API 10.3. В нём появилась полезная функция для AI-ботов: пользователь может остановить генерацию ответа штатной кнопкой Telegram.

В методы sendMessageDraft и sendRichMessageDraft, которые позволяют показывать черновик ответа в личном чате, добавили два параметра:

• can_stop=True — показывает кнопку остановки;

• keep_on_stop=True — временно оставляет уже сгенерированную часть ответа в чате.

Когда пользователь нажимает кнопку, бот получает обновление stopped_message_generation. В нём есть chat, message_thread_id и draft_id, поэтому событие можно связать с конкретной генерацией.

Если вы явно задаёте allowed_updates, новый тип обновления нужно добавить туда. Иначе нажатие кнопки просто не попадёт в обработчик.

Но Telegram останавливает только показ черновика. Запрос к LLM на стороне бота продолжит выполняться, пока разработчик сам его не отменит.

Например, можно хранить задачи по ключу из идентификаторов чата, темы и черновика:

key = (chat_id, message_thread_id, draft_id)

active_generations[key] = asyncio.create_task(
    generate_answer()
)

При получении stopped_message_generation находим задачу и отменяем её:

event = update.stopped_message_generation
key = (event.chat.id, event.message_thread_id, event.draft_id)

task = active_generations.pop(key, None)

if task is not None:
    task.cancel()

    try:
        await task
    except asyncio.CancelledError:
        pass

Это упрощённый пример: конкретный обработчик зависит от используемого фреймворка.

Одного task.cancel() тоже не всегда достаточно. Отмена в asyncio кооперативная: задача остановится только тогда, когда управление вернётся в event loop. Если внутри работает синхронный код или отдельный поток, он может продолжить работу.

Нужно также закрыть потоковое HTTP-соединение с провайдером модели. А если провайдер поддерживает отдельный API отмены, вызвать и его. Иначе модель может продолжить генерацию — вместе с расходом токенов — даже после закрытия соединения.

По сути, здесь есть три независимых действия:

• Telegram прекращает показывать черновик;

• бэкенд отменяет локальную задачу и закрывает соединение;

• провайдер модели останавливает генерацию, если умеет это делать.

Ещё один нюанс касается keep_on_stop=True. Остановленный черновик не превращается в обычное сообщение. Он исчезнет после следующего сообщения в чате или примерно через 30 секунд.

Если частичный ответ нужно сохранить, его придётся отдельно отправить через sendMessage или sendRichMessage.

В многопроцессной системе обычного словаря тоже будет недостаточно: событие остановки может попасть не в тот процесс, где выполняется генерация. Тогда понадобится общая маршрутизация или канал отмены через Redis, брокер сообщений либо другой внешний сервис.

Telegram добавил удобный интерфейс, но жизненный цикл генерации всё равно остаётся на стороне разработчика.

Вопрос: что вы бы делали после остановки: сохраняли частичный ответ, удаляли его или показывали кнопку «Продолжить», которая запускает новый запрос с уже полученным текстом?

WEB-прокси Telegram помогает клиенту, но не инфраструктуре бота

В Telegram Desktop 7.1.0 появился новый тип подключения — WEB proxy. Его уже успели описать как способ, с помощью которого Telegram может выглядеть для сети как обычный HTTPS-сайт.

Если сильно упростить официальное описание архитектуры, работает это так:

1. Клиент сохраняет обычный MTProxy framing и шифрование.

2. Соединения проходят через скрытый WebView внутри приложения.

3. WebView передаёт несколько логических потоков через один или несколько HTTPS- либо WebSocket-соединений с тем же доменом.

4. Серверный relay разделяет потоки и передаёт каждый локально запущенной официальной реализации MTProxy.

При этом relay видит только непрозрачный поток данных: он не расшифровывает содержимое и не выбирает Telegram-сервер назначения.

Указанный домен продолжает работать как обычный HTTPS-сайт. Если запрос не содержит корректного capability, вычисленного из домена и секрета WEB-прокси, посетитель получает публичную страницу. Bridge открывается только клиенту с правильными параметрами подключения.

Сейчас готовая реализация работает в Telegram Desktop. Для Android существует экспериментальный клиент, а поддержка iOS пока описана только в планах проекта.

Что это меняет для разработчика бота

Сам WEB-прокси обслуживает соединение Telegram-клиента с инфраструктурой мессенджера. Он не становится общим туннелем для всех компонентов продукта.

По-прежнему существуют отдельные сетевые контуры:

• Telegram Desktop пользователя → WEB-прокси → Telegram;

• сервер бота → api.telegram.org;

• Telegram → webhook endpoint бота;

• Mini App → домен, на котором размещено веб-приложение.

Если сервер бота потеряет доступ к api.telegram.org, результат будет зависеть от способа получения обновлений.

При long polling бот перестанет и получать обновления, и вызывать методы Bot API.

При webhook входящие обновления ещё могут приходить, если endpoint доступен извне. Однако обычные исходящие обращения к Bot API работать не будут. Есть редкое исключение: Telegram разрешает передать один метод Bot API прямо в HTTP-ответе на webhook. Но узнать результат выполнения такого метода бот уже не сможет.

WEB-прокси также не восстановит недоступный webhook и не поможет загрузить Mini App, если проблема возникла с доменом самого веб-приложения.

Это не недостаток новой технологии. Просто WEB-прокси решает задачу доступности клиента, а не отказоустойчивости сторонней инфраструктуры.

Что по-прежнему остаётся на стороне разработчика

Для long polling нужно отдельно контролировать доступность Bot API и задержку получения обновлений.

Для webhook полезно отслеживать через getWebhookInfo как минимум:

• pending_update_count;

• last_error_date;

• last_error_message.

Обработку обновлений лучше делать идемпотентной: если webhook отвечает кодом вне диапазона 2xx, Telegram повторяет доставку. А слепой повтор исходящих методов вроде sendMessage, наоборот, способен создать дубли.

Получается, фраза «Telegram у пользователя открылся» ещё не означает, что бот, webhook и Mini App тоже работают.

Подскажите, держите ли для Bot API резервный egress или HTTPS-прокси? И состояние webhook вы контролируете через getWebhookInfo или ограничиваетесь метриками самого приложения?

Wildberries выпустила собственный мессенджер WB Chat

У Wildberries появился собственный мессенджер WB Chat. Приложение уже доступно пользователям на Android и iOS, а авторизация проходит через WB ID.

Интерфейс построен по знакомой схеме: диалоги разделены на чаты, группы и каналы, причём создать собственную группу или канал можно непосредственно из приложения. Есть отдельный раздел профиля с аватаром, именем, статусом и возможностью выбрать юзернейм, а для организации переписок предусмотрены папки.

Набор функций тоже постепенно расширяется. Сейчас WB Chat позволяет:

• отправлять сообщения, фото, видео и файлы;

• пересылать сообщения и отвечать на них;

• использовать реакции, эмодзи и стикеры;

• создавать публичные и приватные группы и каналы;

• закреплять важные сообщения;

• искать людей, чаты и сообщения;

• совершать аудиозвонки;

• расшифровывать голосовые сообщения в текст.

Последняя функция особенно интересна для повседневного использования: рядом с кнопкой воспроизведения голосового сообщения появляется возможность получить его текстовую расшифровку. То есть длинное голосовое необязательно прослушивать целиком.

При этом проект пока активно развивается. Например, в последних версиях разработчики отдельно сообщают об исправлениях синхронизации, работе контактов, медиафайлов, звонков и повышении стабильности приложения.

В Google Play приложение опубликовано компанией WB FZE, зарегистрированной в Hamriyah Free Zone в эмирате Шарджа, ОАЭ. На момент проверки там указано 1 тыс.+ скачиваний.

Есть и отдельный момент, на который стоит обратить внимание перед регистрацией: в информации Google Play разработчик указывает, что приложение может собирать фотографии и видео, файлы и документы, а также передавать некоторые категории данных третьим сторонам. При этом передача данных заявлена как шифруемая.

Скачать WB Chat для Android можно через Google Play, для iPhone и iPad — через App Store. Также заявлена веб-версия WB Chat.

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

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

MAX тоже можно защитить шифрованием поверх мессенджера

Telegram, VK и другие сервисы можно использовать как транспорт для зашифрованных сообщений, не полагаясь на их собственный механизм защиты содержимого. Российский разработчик развивает open-source проект CryptoLayer — библиотеку, которая создает дополнительный криптографический слой непосредственно на устройствах участников переписки.

Идея простая: мессенджер становится каналом доставки. Сообщение сначала шифруется локально, затем полученные данные отправляются через выбранный сервис. На устройстве получателя они восстанавливаются и расшифровываются.

Как это работает

CryptoLayer не заменяет Telegram, VK или другой сервис, а отделяет защиту содержимого от транспорта.

Для шифрования используется AES-256-GCM, для цифровых подписей — ECDSA на кривой SECP256R1, а согласование ключей выполняется через ECDH с той же кривой. Дополнительно библиотека может преобразовывать зашифрованные данные с помощью WordCoder — он кодирует байты в последовательность обычных слов.

В результате транспорт получает не исходный текст, а набор слов, который не содержит исходного смыслового содержания. На стороне получателя последовательность преобразуется обратно в байты, после чего CryptoLayer выполняет расшифровку.

Один криптографический слой — разные каналы

Главная особенность проекта — модульная архитектура. CryptoLayer не привязан к конкретному мессенджеру или платформе.

В репозитории указано, что транспортом может быть практически любой канал, способный передавать данные. Среди примеров — Telegram, VK, Discord, HTTP, SSH, FTP, UDP, облачные хранилища, файловая система и Bluetooth. Для нового варианта передачи требуется написать отдельный модуль.

Такой подход позволяет использовать одну криптографическую часть поверх разных сервисов. Теоретически это относится и к MAX: для него можно создать отдельный транспортный модуль, не меняя ядро библиотеки.

Однако готового модуля для MAX в основном репозитории сейчас нет. Поэтому полноценной поддержки этого мессенджера пока нет — потребуется отдельная интеграция.

Какие инструменты уже доступны

Вокруг CryptoLayer постепенно формируется собственная экосистема:

• CryptoLayer CLI — интерфейс для работы из терминала;

• CryptoLayer Web UI — веб-интерфейс для защищенного обмена сообщениями;

• zkgram — отдельный клиент для приватного общения через Telegram.

Исходный код опубликован под лицензией MIT. На момент проверки официальный репозиторий набрал более 200 звезд на GitHub, но проект остается небольшим независимым open-source решением, а не криптографической системой, прошедшей масштабный аудит.

Это важная оговорка. Наличие AES-256-GCM, ECDSA и ECDH само по себе не гарантирует безопасность всей системы. Многое зависит от реализации протокола, генерации и хранения ключей, защиты конечных устройств и отсутствия ошибок в коде.

Что все равно видит мессенджер

CryptoLayer решает конкретную задачу: защищает содержимое сообщения от транспортного сервиса. Но он не скрывает сам факт общения и не делает пользователя анонимным.

Мессенджер по-прежнему может получать техническую информацию, необходимую для работы платформы: данные аккаунтов, факт передачи сообщений, время активности и другие метаданные.

Иными словами, CryptoLayer не скрывает существование переписки. Его задача — не дать транспортному каналу получить исходный текст сообщения.

Где посмотреть исходный код

Репозиторий CryptoLayer на GitHub содержит исходный код, описание архитектуры, используемые криптографические механизмы и информацию о доступных интеграциях.

Архитектура и принцип работы проекта также показаны в видеопрезентации CryptoLayer.

Главное

CryptoLayer интересен не как новый защищенный мессенджер, а как внешний слой шифрования, который отделяет конфиденциальность переписки от конкретного сервиса доставки.

Если проект продолжит развиваться, один и тот же криптографический механизм можно будет использовать поверх разных каналов.

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

Ситуация, знакомая многим: MAX ставить не хочется, а приходится. Работа, знакомые, школьные чаты — и вот у тебя на телефоне живёт приложение, которому ты не доверяешь, и которое работает в фоне тогда, когда ему захочется.

Мне хотелось чтобы MAX вообще не было ни на моём телефоне, ни в моём браузере — а переписка при этом приходила туда, где я и так сижу. В Telegram.

Так появился Telemax — мост между MAX и Telegram.

Что понадобится

Сервер — любая VPS на Ubuntu/Debian. Требования скромные, хватит самой дешёвой.

Свой Telegram-бот — создаётся за минуту в @BotFather, токен вставляется при настройке. Бот твой, живёт на твоём сервере, никакого общего чужого бота — данные идут только через твою инфраструктуру.

Telegram-группа с включёнными темами, куда ты добавишь этого бота админом. Она и станет твоим «окном» в MAX.

Номер MAX, на который мост авторизуется (в том числе если на аккаунте стоит пароль-2FA).

Про безопасность и доступ — два уровня:

Снаружи бот глухой. На любое сообщение или команду из другого чата (личка боту, чужая группа, куда его попытались добавить) он просто молчит. Работает только внутри твоей группы.

Внутри группы — разграничение. Обычные участники могут читать и писать (можно спокойно добавить людей в группу, чтобы вести общее обсуждение). А вот команды боту — только для админа.

Честная оговорка: тот, кого ты добавил в Telegram-группу, видит там все MAX-чаты, а не один. Так что доступ к самой группе — вещь чувствительная.

В ТГ это выглядит так:

14 августа 2026 года проекту Telegram исполнилось 13 лет. В этот день в 2013 году мессенджер был официально запущен в виде клиента на iPhone.

Почему корпоративные чаты постепенно превращаются в новую файловую систему

Когда-то для хранения рабочих файлов были папки, сетевые диски и корпоративные порталы. Сейчас всё чаще главным местом хранения информации становится обычный рабочий чат.

Презентация? "Где-то в чат".
Ссылка на документ? "Используй поиск".
Важное решение? "Где-то выше в переписке".
Нужный файл? "Поищи в нашем чате, я точно отправлял".

В результате чат постепенно превращается в файловую систему, только без нормальных папок и структуры.

Почему так происходит

Чат удобнее большинства корпоративных систем.

Чтобы отправить файл, достаточно перетащить его в окно. Не нужно создавать папку, выбирать права доступа и придумывать название.

Но удобство быстро превращается в проблему.

Через несколько месяцев поиск нужного документа выглядит примерно так:

"Это было либо в понедельник, либо в четверг. Кажется, Андрей отправлял. Название было что-то вроде final_final22314.xlsx".

Поиск по сообщениям помогает, но не решает главную проблему: контекст и информация смешиваются в одном потоке.

Самая опасная часть — знания

Файл найти ещё можно.

Гораздо хуже, когда в чате остаётся решение:

"Давайте делаем по второму варианту".

Через полгода новый сотрудник видит это сообщение, но вообще в глаза его не видел:

• что обсуждалось до него;

• почему выбрали второй вариант;

• кто принимал решение;

• актуально ли оно сейчас.

Получается своеобразная «база знаний без документации».

Что с этим делать

Не обязательно запрещать использование чатов.

Достаточно разделить информацию:

Чат — обсуждение и быстрые решения.
Задачник — конкретные действия.
Документы — актуальные файлы.
База знаний — решения и правила, которые должны жить долго.

Главное правило можно сформулировать очень просто:

Чат должен быть местом, где информация появляется, а не местом, где она навсегда хранится.

Иначе однажды поиск по корпоративному чату станет самым важным IT-инструментом компании — просто потому, что больше никто не знает, где что лежит.

Почему одни Telegram-каналы с 500 подписчиками зарабатывают больше чем другие с 50 000

Долго не мог понять эту разницу. Потом увидел несколько проектов изнутри и стало понятно.

Дело не в размере аудитории. Дело в том за что именно платят подписчики.

В большом канале с холодной аудиторией люди подписались потому что алгоритм показал или кто-то порекомендовал. Они читают. Но не платят - потому что не чувствуют связи с автором. Контент есть, отношений нет.

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

Это меняет всю стратегию монетизации.

Большой канал монетизируется рекламой - там нужен охват. Маленький канал монетизируется подписками и консультациями - там нужна глубина отношений.

Проблема в том что большинство авторов растут в размере но не в глубине. Гонятся за подписчиками, теряют близость с аудиторией, и потом удивляются почему монетизация не работает.

Самый быстрый способ проверить где вы сейчас: спросите свою аудиторию о чём-нибудь личном и посмотрите сколько человек ответят. Если отвечают единицы из тысяч - аудитория холодная. Если десятки из сотен - горячая.

У вас какой тип аудитории и как это влияет на монетизацию?

Миграция корпоративных коммуникаций - это не только перенос почты. Компаниям необходимо сохранить документы, календари, учетные записи и историю переписки, а сотрудникам доступ к привычным рабочим инструментам.

12 августа в 11:00 МСК пройдет бесплатный вебинар «Импортозамещение ≠ долго, дорого, формально. Миграция корпоративных коммуникаций: опыт VK WorkSpace и кейсы крупных компаний».

Эксперты VK Tech расскажут, как подготовить инфраструктуру к переходу, какие данные можно перенести в SaaS-версию и нужно ли при этом останавливать работу на прежней платформе. Отдельно разберут возможные ошибки при миграции, восстановление неперенесенных данных и адаптацию сотрудников после запуска новой системы.

В прямом эфире покажут работу сервисов VK WorkSpace: почты, календаря, мессенджера, видеоконференций, документов, облачного диска и таск-трекера. На примерах крупных компаний спикеры объяснят, сколько времени может занять переход и какие сложности обычно возникают в процессе. Вебинар проведут Сергей Кирсанов, менеджер по развитию продаж VK WorkSpace, и Иван Бородин, пресейл-архитектор VK WorkSpace.

Считал экономику платного Telegram-канала. Комиссия с оборота или фиксированный тариф - разница оказалась неожиданной

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

Поделюсь тем что удивило.

Большинство людей выбирают сервис по стоимости подключения. Это почти всегда ошибка.

Настоящая стоимость - в модели работы сервиса. А моделей сейчас три.

Модель 1 - комиссия с каждой оплаты

Tribute, Paywall и похожие сервисы берут 10-20% с каждой транзакции. Деньги идут через их систему, они выплачивают тебе остаток по расписанию.

Считаем на конкретных числах. При обороте 30 000 рублей в месяц комиссия 10% это 3 000 в месяц и 36 000 в год. При обороте 100 000 - уже 10 000 в месяц и 120 000 в год. При 300 000 - 30 000 в месяц и 360 000 в год только за пользование платформой.

Плюс: не надо думать о платёжках, просто подключился и работаешь.

Минус который мало кто считает заранее: при обороте от 100к в месяц комиссия начинает ощутимо давить. А ещё - Tribute работает через иностранное юрлицо (TRBT Limited). Для самозанятых это дополнительные вопросы по 173-ФЗ о валютном контроле.

Модель 2 - Telegram Stars

Нативная валюта платформы. Пользователь платит не выходя из Telegram, конверсия выше.

Но есть нюансы которые многие узнают постфактум. Если пользователь купил Stars через iOS или Android - Telegram отдаёт разработчику примерно 70%, остальное уходит Apple или Google. Если через десктоп - почти всё твоё. Вывод только через Fragment в TON, для рублёвой отчётности лишний шаг.

Для кого подходит: проекты где аудитория сидит в основном на десктопе, или те кто не против крипто-вывода.

Модель 3 - фиксированный тариф

Деньги идут напрямую на твой счёт в ЮKassa или CloudPayments, сервис берёт фиксированную абонентку.

Та же математика. При обороте 30 000 в месяц платишь фикс около 2 000 - экономия против 10% всего 1 000, разница несущественная. При 100 000 в месяц фикс те же 2 000, экономия уже 8 000. При 300 000 - фикс 2 000, экономия 28 000 в месяц. За год это больше 300 000 рублей которые остаются у тебя а не у платформы.

Из российских сервисов с такой моделью смотрел Nemiling - там фиксированный тариф от 1 790 ₽ в месяц без ограничений по количеству проектов, деньги приходят напрямую на счёт, бесплатно до 5 000 ₽ оборота.

Что ещё важно при выборе - и про что почти не пишут.

Автоматическое удаление при отмене подписки. Кажется очевидным, но не все сервисы делают это надёжно. Если бот не удалил пользователя который не продлил - он продолжает получать закрытый контент бесплатно. На маленькой аудитории не критично, на большой - реальные потери.

Платные группы а не только каналы. Большинство сервисов умеют закрытые каналы. Но платная группа где участники общаются между собой - это другой технический сценарий. Не все его поддерживают.

Платные консультации с таймером. Если продаёшь не подписку а доступ к себе - нужен другой механизм. Пользователь платит за определённое время общения, после которого доступ закрывается автоматически.

Налоговый статус. Самозанятый или ИП - это влияет на выбор сервиса. Деньги которые приходят от иностранного юрлица могут создавать вопросы которые лучше закрыть заранее, а не когда уже пришло требование от банка.

Правильный вопрос при выборе сервиса не «сколько стоит подключение», а «какова полная стоимость при моём планируемом обороте через год» плюс «какие юридические риски я принимаю».

При обороте до 20-25 тысяч в месяц разница между моделями почти незаметна - можно брать что удобнее. При росте выше - фиксированный тариф начинает выигрывать математически.

А вы как выбирали инструмент для монетизации Telegram-проекта - считали экономику заранее или уже потом пересчитывали?

[пожалуйста, не злоупотребляйте эмодзи]

😻 Привет Халчане! Новое обновление HalChat for Android 1.0.3 (Pin, read and react)

Что нового?
🥷 Теперь можно закреплять сообщения
🤗 Поиск по чату
😳 Реакции на сообщения
🤓 Возможность выделять и копировать текст
🤖 Синхронизация действий в реальном времени
🫢 Возможность вернуться в самый низ, когда зашли далеко

Что исправлено?
🤠 Проведена оптимизация от улучшения распределения задач до ускорение процессов синхронизации
👻 Исправлены баги (опросы показывали зашифрованный текст, не всегда загружались люди, терялась синхронизация и данные и т.п.)
🫩 Добавлен выбранный вариант в опросе

Что дальше?
🙀 В следующем обновлении будут дополнительно добавлен локальный ИИ. Благодаря однобитным ИИ моделям, это новая технология уже доступна на HalChatWeb.
🤔 Также я дообучил собственную ИИ модель HalChat-RP с которой сняты больше ограничений и дообучена на RP общении, в том числе все 1к+ ИИ персонажей из генератора HalChatRP

И хотел бы попросить вас всем пройти опрос, проголосовало мало людей, а от этого выбора зависят новые звуковые эффекты мессенджера: https://halwarsing.questionpro.com/t/AddsYZ9TdN

😈 До новых встреч!

Google Play: https://play.google.com/store/apps/details?id=halwarsing.net.halchatandroid
RuStore: https://www.rustore.ru/catalog/app/halwarsing.net.halchatandroid
HalChat Web: https://halch.at/c/tZgWWT
GitHub: https://github.com/halwarsing/HalChat/tree/dev