Как я решил проблему «третьей стороны» в мессенджерах, или почему сервер - это слабое звено
Помните обещания об «абсолютной приватности»? Марк клялся, Павел обещал, но в 2025-м новости о мессенджерах всё больше напоминали сводки с фронта: утечки сотен гигабайт переписки, найденные бэкдоры и данные, внезапно ставшие доступными «третьим лицам».
Пока большинство проектов пытается защитить серверную часть или внедрить еще более сложные протоколы шифрования, я решил пойти другим путем: просто убрать сервер из этой цепочки.
От теории к практике
Примерно в то же время, когда скандалы с приватностью стали нормой, у меня появилась мысль - а что, если посредник не просто не зашифрован, а физически отсутствует?
Я реализовал эту концепцию как технический эксперимент, чтобы проверить её на прочность. Оказалось, что схема вполне жизнеспособна. То, что начиналось как проект «на коленке», превратилось во вполне рабочий инструмент, где безопасность гарантирована не обещаниями разработчика, а самой архитектурой системы.
В чем реальная уязвимость сигнальных серверов
Многие мессенджеры гордятся стойкостью шифрования - AES-ключи, обфускация трафика и борьба с DPI выглядят солидно. Но остается один критический нюанс: у них всё равно есть сервер.
Даже если его называют «сигнальным» и говорят, что он нужен только для установления связи, это всё равно точка сбора данных. Если данные где-то собираются, за ними рано или поздно придут. Будь то хакерская атака или официальный запрос - метаданные (кто, когда и с кем общался) могут рассказать о вас больше, чем само содержание сообщений.
Ну и наконец в серверную могут просто прийти уполномоченные люди которые потребуют предоставить доступ ко всему :-).
Концепция чистого P2P
В Silent Channel я исходил из того, что лучшая защита - это отсутствие объекта для атаки. Здесь нет серверов. Вообще. Даже для того, чтобы ваши устройства «увидели» друг друга.
В классических мессенджерах вы подключаетесь к центральному узлу, который фиксирует ваш IP, время входа и личность собеседника. В моем приложении вы генерируете файл запроса (Offer), передаете его собеседнику любым удобным способом (через почту, другой мессенджер или физически на флешке), получаете файл ответа (Answer) - и только после этого устанавливается прямой туннель. В итоге для остального интернета вашего общения просто не существует.
Цена приватности
Соединение нужно устанавливать заново для каждой сессии, вручную обмениваясь данными.
Тут есть важный технический момент: почему эти файлы нужно использовать быстро? Успех P2P-соединения зависит от того, найдут ли устройства друг друга в сети. Файлы содержат ICE-кандидаты - список ваших текущих IP-адресов и портов на данный момент.
Соединение достаточно сильно зависит от стабильности сети:
При смене IP (переход с Wi-Fi на мобильную сеть) старые данные в файле моментально становятся недействительными.
В отсутствие сервера, который обновлял бы маршруты в реальном времени, вы полагаетесь на «снимок» сети. Если условия изменились за время передачи файла, туннель не построится.
При слабой связи бывает не сразу удается установить соединение, приходится повторять процесс подключения.
Это своего рода цифровая скоропортящаяся посылка. Да, это требует лишних действий, но именно такая механика исключает возможность отложенных атак или долгосрочной слежки.
Автономность и отказ от сервисов Google
Я старался сделать приложение максимально независимым:
Здесь нет аккаунтов. Никаких привязок к номеру телефона или почте. Нет записи в базе - нет данных, которые можно сопоставить с личностью.
Никакого Firebase или Google Play Services. В приложении нет облачных уведомлений и встроенной аналитики, что кстати делает его удобным для любых кастомных сборок Андроид.
Никакой рекламы и скрытых метрик. Передавать данные просто некуда - в коде не заложены адреса серверов для сбора статистики.
Почему это критично сейчас
Последние годы показали, что метаданные - это яд. Даже если никто не прочитал ваше сообщение, сам факт контакта в три часа ночи, частота этих контактов и их привязка к вашему местоположению позволяют составить очень точный психологический портрет.
В централизованных системах администратор сервера знает о вас всё, кроме смысла слов, но смысла часто и не требуется для деанонимизации. В моем приложении нет даже «Личного кабинета» - это было бы абсурдом в контексте приватности. Только код и прямое соединение.
Стек технологий и платформы
Для тех, кому интересна техническая часть:
WebRTC в чистом, без-серверном виде.
Serverless Signaling - отсутствие посредников при обмене SDP-пакетами.
KMP (Kotlin Multiplatform) - основа проекта. Благодаря этому стеку приложение уже сейчас доступно не только на Android, но и в виде полноценной Desktop-версии (Windows). Оба клиента работают по идентичной логике безопасности. На данный момент это две основные платформы, для которых возможна сборка и стабильная работа P2P-протокола.
Интересный технический парадокс: установить и поддерживать стабильное соединение для текстового чата в чистом P2P зачастую сложнее, чем для видео или аудио. Это связано с фундаментальными различиями в передаче потоковых и дискретных данных через WebRTC.
Для передачи голоса и видео используется протокол SRTP на базе UDP. Это концепция «живого потока», где потеря части пакетов не критична: мы просто их игнорируем, так как следующий пакет придет через миллисекунды. Текстовая же переписка работает через Data Channel (протокол SCTP поверх UDP), который обязан гарантировать доставку каждого байта в правильной последовательности.
Здесь и кроется главная проблема «молчаливого» канала. Видеопоток - это непрерывная бомбардировка сети пакетами, которая удерживает NAT-сессию роутера открытой. Чат же может «молчать» минутами, и в отсутствие сервера, который мог бы пропинговать клиента, домашние роутеры быстро закрывают порты, считая соединение неактивным. В итоге туннель схлопывается именно в моменты тишины.
Кроме того, Data Channel требует жесткого контроля состояния. Если из-за кратковременной смены сети потеряется служебный пакет подтверждения, канал может уйти в ошибку и потребовать пере-подсоединения. Видео в такой ситуации просто «дернется» и продолжит трансляцию.
Именно поэтому аудио- и видеозвонки субъективно кажутся стабильнее. При их выборе приложение задействует механизмы, которые на уровне системы имеют приоритет. Постоянная передача трафика не дает сетевому оборудованию «забыть» маршрут. Это предотвращает агрессивное закрытие процесса системой ради экономии энергии.
В итоге мы получаем техническу�� иронию: передать «тяжелое» видео в мире без серверов иногда проще, чем установить текстовое общение. Зачастую установить одно только соединение для чата (Data Channel) не получается за один подход, когда аудио или видео устанавливается без проблем.
О доверии
Я предвижу главный вопрос сообщества: «Если приложение про приватность, почему код не открыт?». Хочу ответить на это максимально честно.
Silent Channel — это мой коммерческий проект, в который вложено много сил на решение задач P2P‑стабильности. На данном этапе я выбрал модель закрытого кода для защиты интеллектуальной собственности и монетизации. Однако приватность здесь базируется не на «честном слове», а на физических ограничениях архитектуры:
Проверка сетевой активности. Любой задавшийся целью может запустить сниффер (Wireshark, PCAPDroid) и убедиться: приложение не инициирует соединений с внешними серверами. В коде просто нет адресов, куда могли бы уходить логи или метаданные.
Нету бигтеха. Писал чуть выше - в приложении полностью отсутствуют Firebase, Google Play Services и любая другая аналитика. Нет рекламы. Это можно проверить через анализ манифеста. Так что в случае креша мне сложнее его поймать, так что очень жду живые отзывы.
Несохранение данных. Ваша переписка не сохраняется ни на каких серверах (их просто нет) и не кэшируется в постоянную память устройства. Все данные существуют только в рамках текущей сессии исключительно в оперативной памяти.
- Важное уточнение: Принятые файлы сохраняются в указанном вами месте (по умолчанию в папке «Загрузки»).Минимум разрешений. Silent Channel запрашивает абсолютный минимум системных разрешений. Ему не нужны ваши контакты, доступ к SMS или геолокации. Только аудио, видео звонки - собственно для этого он и нужен ).
Вы можете убедиться посмотрев файл манифеста приложения по ссылке или самостоятельно дастать его из файла апк.
Для поддержки проекта существуют две версии приложения. Цена платной версии в Google Play зависит от страны, она снимает все лимиты на общение. Рассматриваю вариант оплаты другими методами.
Бесплатная версия полнофункциональна в плане безопасности, но имеет следующие технические ограничения: Длительность аудиозвонка - до 3 минут, видеозвонка - до 1 минуты, максимальный размер пересылаемого файла в чате - до 3 МБ.
Я понимаю, что для многих отсутствие Open Source - это «красный флаг». Но в данном случае архитектура Clean P2P делает наличие бэкдора практически бессмысленным: ему просто некуда отправлять украденные данные, так как в системе отсутствует центральный узел сбора.
В общем я открыт к диалогу.
Итог
Пока индустрия спорит о том, чей сервер защищеннее, я предлагаю просто выйти из этой системы координат. Если вы не хотите, чтобы ваши данные попали в сеть - не отправляйте их туда.
Silent Channel - это эксперимент по возвращению контроля над общением самому пользователю. Это не так удобно, как обычный чат, но это цена за то, что ваше общение остается только вашим.
Буду рад любому фидбеку. Сразу отмечу: при анализе предложений я в первую очередь смотрю на то, как идея влияет на максимальную безопасность и анонимность пользователя, и только во вторую - насколько это повышает удобство интерфейса.
Для генерации картинок и в качестве шеф редактора использовался AI.
Комментарии (75)
Andnet
19.01.2026 14:39Куча бесплатных уже давным давно есть.
lordtao Автор
19.01.2026 14:39В том-то и дело, что почти все они используют серверы, даже если этого не видно. Моя идея это соединение вручную, вообще без них. Это другая концепция.
grixis
19.01.2026 14:39Tox например. Там нет сервера вроде.
lordtao Автор
19.01.2026 14:39Tox не использует центральный сигнальный сервер. Поиск контактов происходит через сеть пользователей, что может раскрывать ваш IP-адрес — это его главный минус для анонимности. История храниться минимум локально.
Kagvi13
19.01.2026 14:39А как вы оцениваете такой проект как BitMessage (основан на принципах Blockchain, но, похоже, давно не развивается)?
MAXH0
19.01.2026 14:39: “Если приложение про приватность, почему код не открыт?”. Хочу ответить на это максимально честно.
Silent Channel - это мой коммерческий проект, в который вложено много сил на решение задач P2P-стабильности. На данном этапе я выбрал модель закрытого кода для защиты
Вынесете это, пожалуйста, в заголовок. Потому что дальше можно не читать.
lordtao Автор
19.01.2026 14:39Справедливое замечание. Я, как и многие, верю, что честный труд заслуживает честной оценки. Надеюсь, вы тоже не работаете исключительно за идею. Статья, впрочем, остаётся бесплатной для всех любопытных
MAXH0
19.01.2026 14:39Ну вы же рекламируете товар. Так рекламируйте его заинтересованным в покупке клиентам, а не случайным прохожим, зашедшим поинтересоваться решением... Ведь сами признали "для многих отсутствие Open Source - это «красный флаг»." Так зачем вы заставляете их время терять?..
lordtao Автор
19.01.2026 14:39Спасибо за вашу точку зрения. Цель статьи - в первую очередь обсудить архитектуру чистого P2P-соединения и её жизнеспособность, а не продвижение продукта. Модель монетизации упомянута лишь для полноты картины, так как это часто важный практический вопрос. Основная задача - получить мнения и отзывы от читателей, чтобы понять, насколько такая концепция вообще имеет перспективы и что в ней можно улучшить. Ваше мнение, как человека с интересом к теме, тоже ценно для этого обсуждения.
MAXH0
19.01.2026 14:39Вот мне тоже интересно, как поведёт себя система в России в условиях анализа пакетов и прочих чудес.
dsoastro
19.01.2026 14:39а как у вас связываются клиенты за NAT? Какой TURN сервер они используют?
namikiri
19.01.2026 14:39Присоединюсь к вопросу, это было первое, о чём я подумал.
Плюс более глобальный: как двум клиентам найтись? Допустим, я хочу связаться с кем-то, как я идентифицирую собеседника? По его IP? По какому-то уникальному ключу? А как наши приложения узнают друг друга? Как проверить, что посреди нас не появился мужик посередине?
lordtao Автор
19.01.2026 14:39Вы правы, но именно этап обмена файлами и есть критическая точка. WebRTC защищает уже установленный канал, но не процесс «рукопожатия».
Если злоумышленник перехватит и подменит файлы offer и answer в момент их передачи (например, по email или в другом мессенджере), он может встать между вами, представившись каждому из вас вашим собеседником. После этого он сможет расшифровывать и перенаправлять весь трафик.
Думаю для этого можно использовать рэндомный/одноразовый канал доставки предложения/ответа. Не уверен что все каналы мужик посредине сможет отследить.
Это не делает систему абсолютно неуязвимой (теоретически, целевая атака на конкретных лиц всё ещё возможна), но повышает порог входа для атаки на несколько порядков, что для большинства сценариев более чем достаточно.
supercat1337
19.01.2026 14:39Вообще, было бы интересно почитать о безопасности stun и turn серверов. Без них никакого p2p нет.
lordtao Автор
19.01.2026 14:39STUN сервера только выдают однократно тебе твой публичный адрес в момент запроса, но он не знает, с кем вы планируете общаться дальше.
Использование же TURN-серверов сопряжено с серьезными рисками для приватности, так как владелец сервера технически может видеть IP-адреса участников и объемы передаваемого трафика. TURN же видит IP обеих сторон одновременно, так как он соединяет их внутри себя.
namikiri
19.01.2026 14:39Вопрос туда же: если несколько устройств сидят за NAT, и двое из них решили связаться с кем-нибудь извне по вашему протоколу, как система поймёт, кто куда подключается? По портам?
lordtao Автор
19.01.2026 14:39Система различает устройства за одним NAT в основном с помощью портов и механизмов NAT-трансляции, которые координируются через STUN-серверы.
Ключевую роль играют порты. Даже если публичный IP-адрес у всех устройств за NAT один, маршрутизатор назначает уникальный внешний порт для каждого исходящего соединения. Это позволяет системе однозначно идентифицировать, какому именно устройству в локальной сети предназначен входящий трафик.
quarus
19.01.2026 14:39Давно ждал чего-то подобного (я не программист).
По оплате: нет подписки. Пишу здесь, т.к. в GPlay невозможен отзыв без установки программы.
Зачастую разовая оплата программы это - высокая вероятность, что проект рано или поздно будет заброшен... неоднократно сталкивался.
Number571
19.01.2026 14:39Задумка прямого P2P-соединения хороша, но в реальном мире почти неосуществима. Вы убрали из модели угроз сервера, которые могли бы хранить метаданные о вас, вашем онлайн/оффлайн статусе, переписках и прочей активности - это хорошо. Тем не менее P2P-соединение - оно не является прямым, оно проходит сквозь множество маршрутизаторов провайдеров связи, фактически тех же серверов, всё также собирающих множество метаданных. Чтобы скрыть от них активность уже недостаточно обычной установки P2P-соединения в сети Интернет. В результате, мы получаем слегка пониженный риск сбора метаданных, но основной риск в лице майора - он остаётся.
lordtao Автор
19.01.2026 14:39Вы совершенно правы: P2P-соединение не является абсолютной защитой от слежки, а скорее меняет источник угроз. Оно устраняет центральный сервер, который хранит метаданные и историю переписки, что защищает от корпоративной слежки и взломов серверов. Однако, как вы верно заметили, соединение проходит через маршрутизаторы провайдеров, которые по-прежнему могут анализировать сам факт коммуникации между IP-адресами.
Ключевая уязвимость чистого P2P — раскрытие реальных IP-адресов собеседникам, что позволяет легко их идентифицировать.
Именно эту проблему эффективно решает VPN. Он скрывает ваш настоящий IP-адрес от собеседника и шифрует трафик от локального провайдера, перенося "точку доверия" на VPN-сервис. Таким образом, комбинация P2P и VPN значительно повышает уровень приватности, защищая как от корпоративного, так и от другого анализа трафика, при условии выбора надёжного VPN-провайдера.
sohmstyle
19.01.2026 14:39>>при условии выбора надёжного VPN-провайдера
Если резюмировать, то здесь самый обычный P2P без какой-то большой маскировки -сетевая активность по-прежнему видна.
А если ваш проприетарный код написан ИИ (в чём я не сомневаюсь, учитывая структуры текста в ваших сообщениях и текстах) без аудита профессионального разработчика, то грош цена вашему решению, извините.
Пусть это будет вашим pet-проектом, который вы сможете демонстрировать на собеседованиях.
lordtao Автор
19.01.2026 14:39Вы абсолютно правы, я использую AI для написания приложений Андроид приблизительно с 2009 года, для публикаций на Хабре с 2011 года. Да, еще библиотеки на GitHub c 2010 года. Рекомендую использовать, очень помогает.
AI3aEball
19.01.2026 14:39Идея Pure P2P, по моему мнению пушка. Выкинуть сервер из уравнения - единственно верный путь. Нооооо... давайте без иллюзий. "Приватность базируется на архитектуре" разбивается о "я выбрал модель закрытого кода". В мире Security это так не работает насколько мне известно. "Trust me, bro" это тоже не аргумент. ИМХО. Если я не могу скомпилить клиент сам и убедиться, что он не пишет копию SDP-оффера в скрытый лог (который улетит при краше или обновлении), то вся эта "архитектурная защита" держится на честном слове. Или я что-то не понимаю?
Хотите доверия параноиков (а это по сути ваша ЦА) - открывайте код. Хотите денег - продавайте сборки в сторе, донаты или Enterprise-лицензии. А "Приватный проприетарный мессенджер" - это оксюморон.
lordtao Автор
19.01.2026 14:39Согласен с вами на 100%: в безопасности одних слов недостаточно. Поэтому главный принцип Silent Channel - полная проверяемость сетевой активности на уровне ОС. Любой желающий (с помощью Wireshark, PCAPdroid или встроенного мониторинга) может убедиться, что после обмена SDP-файлами приложение не устанавливает ни одного соединения с какими-либо внешними серверами - только прямой P2P-канал с собеседником. Архитектура без серверов - это не просто заявление, а технический факт, который можно подтвердить независимо от открытости кода. Для параноиков (нашей ЦА) это, пожалуй, даже важнее, чем исходники - ведь даже в открытом коде можно спрятать сюрприз, а здесь доказательство лежит в плоскости сетевого трафика, который вы можете проконтролировать сами.
takezi
19.01.2026 14:39Бэкдор может ждать сигнала к действию молча :)
lordtao Автор
19.01.2026 14:39Это верное наблюдение. Однако в системе без серверов «сигнал к действию» должен откуда-то прийти. Приложение не имеет фоновых подключений — весь его трафик это прямое P2P-соединение, которое можно проверить. Чтобы активировать бэкдор на конкретном пользователе, нужен механизм целевой доставки команды, а в чистом P2P для этого просто нет инфраструктуры. Интересно услышать вашу гипотезу: как, технически, по-вашему, мог бы выглядеть такой сигнал и каналы его доставки в данной архитектуре?
aleksandr_el
19.01.2026 14:39С инициализацией соединения со стороны клиента спустя 180 дней от вчера, либо 18 сентября...
Как верно заметили, параноики не станут верить на слово. Проверять весь трафик? Ну такой себе совет на самом деле, в данном контексте
lordtao Автор
19.01.2026 14:39В андроиде есть такое понятие как бекграунд/фореграунд сервис. Он должен быть прописан в манифесте по типу <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
Открываете приложение при помощи к примеру jadx, смотрите манифест (он там в открытом виде). Там указаны все разрешения. Вы увидите что там перечислены только вот эти:
<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" /> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /> <uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.RECORD_AUDIO" /> <uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
Эти разрешения не дают возможности находиться приложению в бекграунде и быть готовым принимать в любой момент команду или активизироваться.Вы так же не найдете описания никаких других сервисов которые могут подобным заниматься. Чистое сингл активити.
cpud47
19.01.2026 14:39Есть механизмы стеганографии по встраиванию бэкдора в криптографию. Например, можно к каждому шифрованному офферу прилагать метаинформацию, зашифрованную публичным ключом злоумышленика. Или в самом p2p соединении оставлять шифрованный блок.
Дальше продать эту информацию провайдерам/точкам обмена трафиком и профит. Ну или мониторить офферы и собирать информацию.
Или в другую сторону: а сколько по времени нужно производить эксперимент по мониторингу? Что если приложение выходит на связь только раз в сутки, в глубокую ночь?;)
И напомню, что всю процедуру проверки необходимо повторять после каждого обновления. С нуля, т.к. неизвестно что поменялось.
Короче говоря, нет. Закрытые исходники — это крест на доверии/приватности.
lordtao Автор
19.01.2026 14:39Offer/Answer - сигнальные текстовые файлы стандартного JSON с ICE кандидатами. Вы их можете легко проверять.
Мониторинг можно делать автоматическим, покажет пустоту за ночь. Приложение не имеет разрешений для работы сервисов в бекграунде - см. манифест. А если приложение не имеет возможности получить команду в любой момент, то это явно не айс.
Открыть исходники - подумаю. Может быть позже. А пока у меня маленький вопрос - а зачем это мне?cpud47
19.01.2026 14:39Вопрос не в том, чтобы убедиться что нет конкретной лазейки. Вопрос в том, что доказать отсутствие бэкдоров внешними методами — крайне проблематично.
А пока у меня маленький вопрос - а зачем это мне?
Не знаю. Если Вы хотите, чтобы Вашим приложением пользовались в качестве "приватного мессенджера" — то открыть прийдётся. Если же Ваша ЦА — обычные пользователи, которым просто нужен мессенжер (удобный, красивый, etc), то можете не открывать.
Если что, открытие исходников не означает отсутствие заработка. Можете рассмотреть разные модели монетизации.
Вопрос именно в том, что открытые исходники есть необходимый пререквизит к приватному мессенжеру. Если мы о реальной приватности, а не о маркетинге, конечно
Mikhail55ru
19.01.2026 14:39Не разделяю общий восторг. Надёжность системы будет равна надёжности ее самого слабого компонента. Обмен ключами, поиск в глобальной сети абонента добавляют ту самую ложку дегтя, превращая всю бочку меда в бочку ну точно не меда.
supercat1337
19.01.2026 14:39Абсолютно согласен. Конфиденциальность как-то не бьётся с реалтаймовым p2p и отсутствием верификации (читай как риск mim).
typ6o0jiehb
19.01.2026 14:39Переходите на ipv6, и вам не нужны будут посредники. Yggdrasil / mycelium например. Используйте готовые решения типа i2p или tor - развивайте эти сети, и в них транслируйте ваши сообщения. В чем проблема? Есть куча вариантов.
А вот эти вот ваши чистый прямой p2p так же будет залогирован операторами.
mitrillov
19.01.2026 14:39Ура, мы достигли использования ИИ вместо человека на всех этапах разработки продукта, от кода и сайта, до написания статьи на Хабр.
Nemoumbra
19.01.2026 14:39... и ответов в комментариях. Вернее, надеюсь, что это просто мерещится мне.
Вы совершенно правы: P2P-соединение не является абсолютной защитой от слежки, а скорее меняет источник угроз.
gassner
19.01.2026 14:39Не мерещится. Это реально с ИИ ответы написаны, со всеми его красными флагами.
lordtao Автор
19.01.2026 14:39Вы абсолютно правы, я использую AI для написания приложений Андроид приблизительно с 2009 года, для публикаций на Хабре с 2011 года. Да, еще библиотеки на GitHub c 2010 года.
Рекомендую, очень помогает. Я исправлю статью.
TechnicalMan94
19.01.2026 14:39Или я что-то не понимаю, или...
Зачем на сигнальном сервере что либо сохранять? Я делал чат, сокет принял-отправил сообщение и забыл.
MarksMan09
19.01.2026 14:39Keet вроде уже придумали... Вы придумали его еще раз? :)
Скрытый текст
lordtao Автор
19.01.2026 14:39Интересный проект. Прочитал в инете - " его финансируют крупные крипто-корпорации".
gassner
19.01.2026 14:39Слушайте, ну хоть не позорьтесь написанием ответов с помощью ИИ. Видно же насквозь и по обычным признакам, и по повторяемости,
и по занудству.Если вы душу в софт вложили, так и ответить могли бы. А если там нейро-слоп "напиши мне приложение для отправки текста через WebRTC" (как у вас в промпте для ответов на комментарии), то платить вам не за что. Самое ответственное (передачу ключ-файлов) вы не придумали.
leadraven
19.01.2026 14:39Статья про "народный" (пролетарский) мессенджер, а в конце интеллектуальная собственность, монетизация... Не изжил ещё мелкобуржуазное в себе.
Лучше бы донаты принимал.
lordtao Автор
19.01.2026 14:39Вы правы, возможно если бы не было войны, то у меня не было бы столько свободного времени в связи с отсутствием работы и невозможностью выйти из дома (загребут ТЦК). А так появилось много свободного времени чтобы придумать как прокормить семью.
Сейчас я полностью мелкобуржуазный и только истинные пролетарии не нуждаются в земной пище. А поскольку учился в советское время, то не умею нормально продавать свои продукты (не учили), поэтому до крупно буржуазного не дорос.
lordtao Автор
19.01.2026 14:39Донаты вещь хорошая. Только "кто девушку поит, тот ее и танцует". Не хочется заниматься танцами с кем то.
Мне кажется честней использовать либо бесплатную версию с небольшими ограничениями, либо одноразовый небольшой платеж. Ну и конечно же можно вообще не использовать ).
aleksandr_el
19.01.2026 14:39Чем все эти "приседания" и сложности лучше, чем скажем выдать ключ от непривилигированного доступа по ssh на любой арендованный сервак в Африке, где можно двоим пообщаться в текстовом файлике и оставить файлы прям в домашнем каталоге?
В этом сценарии я вижу проблем не меньше, чем в предлагаемом в статье варианте
lordtao Автор
19.01.2026 14:39Вы правы, ну что может быть проще для обычного пользователя чем аренда сервака в Африке ).
Кстати вы пробовали как работает бесплатное приложение? Вам было сложно его использовать?aleksandr_el
19.01.2026 14:39Учитывая на чём именно Вы акцентируетесь и сколько всеможных шагов, судя даже по уже написанным комментариям, мне нужно сделать, чтобы убедится в честности утверждений, без гарантий убедится на сто процентов... Даже не скачивал
khamraev
19.01.2026 14:39У тебя может быть идеальный P2P, но если оба за CGNAT — вы никогда не встретитесь.
lordtao Автор
19.01.2026 14:39Вы совершенно правы. Вероятность почти 100% что не соединиться. Для таких целей как раз и должны использоваться TURN-серверы. Но я их не включал осознанно. Как писал выше возможно добавлю в качестве опции.
Yuriy_krd
Идея шикарная, но ахиллесова пята - передача файлов оффера и ответа. Как бы не передавались эти файлы - факт обмена этими файлами не через вашу программу покажет связь между двумя людьми.
lordtao Автор
Признаю, это уязвимость — факт обмена файлами. Но это контролируемый риск:
Для обычного пользователя — не трагедия.
Для параноика — каналов для одноразовой отправки не отследить, а файлы быстро «протухают», не раскрывая сути.
fnlnz
А клавиатура гугловская или встроенная?
lordtao Автор
Клавиатура предлагаемая устройством. Судя по всему есть предложение дополнить самописной встроенной клавиатурой чтобы избежать возможных перехватов?