Кирилл, спасибо за баг-репорты, часть уже исправлена, остальное в работе. Большинство из них касались десктопной версии, которая активно дорабатывается, первый релиз был сфокусирован на мобильном PWA. По модерации: публичные каналы с названиями сексуального характера удаляются осознанно, это базовый принцип платформы. Правила опубликуем в ближайшее время.
На начальном этапе мы ввели лимиты на загрузку файлов (для Free 20 в день), зашифрованные файлы весят значительно больше исходных и нагрузка на хранилище соответствующая. В будущем планируем пересматривать лимиты. По корпоративному плану вы можете написать в поддержку Mist или на почту, обсудим индивидуально.
Seed-фраза в Mist генерируется при создании аккаунта, войти с произвольной BIP39 фразой нельзя, потому что аккаунта с таким ключом просто не существует на сервере. Процесс: регистрация - BIP39 в Mist генерирует 12 слов - из них детерминированно выводятся ключи - публичный ключ отправляется на сервер. При логине сервер проверяет подпись через challenge-response если публичного ключа нет в базе, логин невозможен. Использовать свою фразу от кошелька не получится это разные системы идентификации. Зарегистрируйтесь через "Создать аккаунт", сохраните сгенерированную фразу и с ней можно входить с любого устройства в Mist.
Возможно это рабочий метод для экстремальных сценариев, но транспорт через Яндекс почту или Max создаёт новую проблему оба сервиса видят метаданные и находятся в рф юрисдикции. Это не приватный транспорт, это замена одного риска другим
SNI в открытом виде - да, без ECH домен виден в TLS handshake. Но блокировки по SNI в РФ работают не для всех доменов, а по реестру. Пока домена нет в реестре РКН SNI не помеха. Тестировали с МТС, Билайн, Т2 и домашних провайдеров, работает без VPN
Подробная документация по архитектуре в процессе, скоро появится на сайте. Пока можете ознакомиться с README на гитхабе (cсылка в статье). По бизнес-модели: Free план + платные подписки Pro и Ultra
По MLS да, рассматриваем. Текущая схема с per-member key wrapping работает для групп до 50-100 человек: отправитель делает N операций AES-GCM wrap, сервер хранит N зашифрованных ключей на сообщение. Это O(N) на отправку и O(N) на хранение.
MLS с TreeKEM даёт O(log N) на обновление ключей за счёт древовидной структуры при 1000 участников это разница между 1000 и 10 операциями. Для нашего текущего лимита групп это оверинжиниринг, но при масштабировании станет необходимостью.
В v2 планируем подход Signal Private Groups, сервер хранит зашифрованный blob состояния группы и не знает состав участников. Протокол открыт, будем пробовать
Это интересное предложение, но на практике упирается в несколько моментов:
UPnP отключён по умолчанию у большинства провайдеров и роутеров. А где включён - это дыра в безопасности которую мы не хотим рекомендовать пользователям.
IPv6 да, снимает проблему NAT. Но проникновение IPv6 в России пока низкое, особенно в мобильных сетях.
Идея с пользовательскими relay за премиум это по сути Tor-модель. Работает, но создаёт юридические риски для тех кто ретранслирует чужой трафик. В контексте РФ это то, чем мы не хотим нагружать пользователей.
Пока проще и надёжнее держать несколько своих TURN серверов в разных юрисдикциях. Но идею с десктоп-клиентом держим в уме, он в планах
P2P как идея отличная, но на практике упирается в NAT traversal, мобильные сети и энергопотребление. Держать прямое соединение между двумя телефонами за NAT оператора, задача которую даже WebRTC решает через TURN серверы, а это уже не чистый P2P. Мы не претендуем на решение проблемы «сервер можно заблокировать» - от этого нет защиты. Но разница в том что наш сервер это почтальон: он передаёт зашифрованные пакеты и не может их прочитать. Даже если его заблокируют - переписка не скомпрометирована. А переехать на другой IP - вопрос минут. Полноценный P2P мессенджер без серверов, без mesh, без костылей - я буду рад увидеть рабочую реализацию. Пока её нет, мы решаем задачу теми способами которые работают сегодня.
Проект финансируется фаундерами. Инфраструктура в текущей реализации недорогая, сервер не занимается шифрованием, всё шифрование происходит на клиенте. Подписки (доп возможности к базовому функционалу) частично покрывают расходы
Да мы осознаем этот риск. Подготовились к возможности блокировок. Резервные домены, несколько IP, быстрое переключение. Плюс PWA обновляется автоматически - пользователю не нужно качать новую версию из стора чтобы переехать на новый адрес.
Кирилл, спасибо за баг-репорты, часть уже исправлена, остальное в работе. Большинство из них касались десктопной версии, которая активно дорабатывается, первый релиз был сфокусирован на мобильном PWA. По модерации: публичные каналы с названиями сексуального характера удаляются осознанно, это базовый принцип платформы. Правила опубликуем в ближайшее время.
На данный момент self-hosted версии нет, Mist работает как единый сервис
На начальном этапе мы ввели лимиты на загрузку файлов (для Free 20 в день), зашифрованные файлы весят значительно больше исходных и нагрузка на хранилище соответствующая. В будущем планируем пересматривать лимиты. По корпоративному плану вы можете написать в поддержку Mist или на почту, обсудим индивидуально.
Seed-фраза в Mist генерируется при создании аккаунта, войти с произвольной BIP39 фразой нельзя, потому что аккаунта с таким ключом просто не существует на сервере. Процесс: регистрация - BIP39 в Mist генерирует 12 слов - из них детерминированно выводятся ключи - публичный ключ отправляется на сервер. При логине сервер проверяет подпись через challenge-response если публичного ключа нет в базе, логин невозможен. Использовать свою фразу от кошелька не получится это разные системы идентификации. Зарегистрируйтесь через "Создать аккаунт", сохраните сгенерированную фразу и с ней можно входить с любого устройства в Mist.
Возможно это рабочий метод для экстремальных сценариев, но транспорт через Яндекс почту или Max создаёт новую проблему оба сервиса видят метаданные и находятся в рф юрисдикции. Это не приватный транспорт, это замена одного риска другим
Спасибо! Приятно слышать. Удачи с проектом!
Спасибо за обратную связь. Какое устройство и браузер? Вы используете PWA или открытое окно в браузере?
SNI в открытом виде - да, без ECH домен виден в TLS handshake. Но блокировки по SNI в РФ работают не для всех доменов, а по реестру. Пока домена нет в реестре РКН SNI не помеха. Тестировали с МТС, Билайн, Т2 и домашних провайдеров, работает без VPN
Подробная документация по архитектуре в процессе, скоро появится на сайте. Пока можете ознакомиться с README на гитхабе (cсылка в статье). По бизнес-модели: Free план + платные подписки Pro и Ultra
Спасибо за обратную связь. Исправили
Спасибо за детальный разбор.
По MLS да, рассматриваем. Текущая схема с per-member key wrapping работает для групп до 50-100 человек: отправитель делает N операций AES-GCM wrap, сервер хранит N зашифрованных ключей на сообщение. Это O(N) на отправку и O(N) на хранение.
MLS с TreeKEM даёт O(log N) на обновление ключей за счёт древовидной структуры при 1000 участников это разница между 1000 и 10 операциями. Для нашего текущего лимита групп это оверинжиниринг, но при масштабировании станет необходимостью.
В v2 планируем подход Signal Private Groups, сервер хранит зашифрованный blob состояния группы и не знает состав участников. Протокол открыт, будем пробовать
Это интересное предложение, но на практике упирается в несколько моментов:
UPnP отключён по умолчанию у большинства провайдеров и роутеров. А где включён - это дыра в безопасности которую мы не хотим рекомендовать пользователям.
IPv6 да, снимает проблему NAT. Но проникновение IPv6 в России пока низкое, особенно в мобильных сетях.
Идея с пользовательскими relay за премиум это по сути Tor-модель. Работает, но создаёт юридические риски для тех кто ретранслирует чужой трафик. В контексте РФ это то, чем мы не хотим нагружать пользователей.
Пока проще и надёжнее держать несколько своих TURN серверов в разных юрисдикциях. Но идею с десктоп-клиентом держим в уме, он в планах
P2P как идея отличная, но на практике упирается в NAT traversal, мобильные сети и энергопотребление. Держать прямое соединение между двумя телефонами за NAT оператора, задача которую даже WebRTC решает через TURN серверы, а это уже не чистый P2P. Мы не претендуем на решение проблемы «сервер можно заблокировать» - от этого нет защиты. Но разница в том что наш сервер это почтальон: он передаёт зашифрованные пакеты и не может их прочитать. Даже если его заблокируют - переписка не скомпрометирована. А переехать на другой IP - вопрос минут. Полноценный P2P мессенджер без серверов, без mesh, без костылей - я буду рад увидеть рабочую реализацию. Пока её нет, мы решаем задачу теми способами которые работают сегодня.
Проект финансируется фаундерами. Инфраструктура в текущей реализации недорогая, сервер не занимается шифрованием, всё шифрование происходит на клиенте. Подписки (доп возможности к базовому функционалу) частично покрывают расходы
Да мы осознаем этот риск. Подготовились к возможности блокировок. Резервные домены, несколько IP, быстрое переключение. Плюс PWA обновляется автоматически - пользователю не нужно качать новую версию из стора чтобы переехать на новый адрес.