Pull to refresh

Comments 8

Код клиентов открыт, ссылки под статьёй.

Забыли добавить?

Спасибо, исправили.
Ссылки действительно потерялись при публикации, добавил в конец статьи.

Вот они:

iOS: github.com/rcq-messenger/rcq-ios
Android: github.com/rcq-messenger/rcq-android
Референс сервера: github.com/rcq-messenger/rcq-server-ref

Всё под AGPL-3.0.

Почему решили делать своё решение? И в чём ваш протокол лучше чем matrix и xmpp?

И вопросы:

  • где s2s спецификация?

  • не увидел поддержки нескольких устройств, она есть?

  • почему сделали свою аутентификацию, а не взяли OIDC?

  • не увидел ролевой модели в чатах (админ/модератор/пользователь), она присутствует?

  • почему в спеке поддержка только одного эфемерного ключа, а не нескольких?

Своё не из любви к велосипедам. Matrix и XMPP про федерацию и совместимость, а нам важнее минимум метаданных и анонимность. У них сервер видит состав комнат, граф, presence. У нас sealed sender, сервер не знает даже от кого сообщение. За это и платим отсутствием федерации. Кстати это сразу ответ про s2s: её нет специально, острова это изолированные инстансы, а федерация и есть лишний канал утечки метаданных.

Мультидевайса пока нет, врать не буду. Мультиаккаунт есть (несколько личностей на телефоне), но это другое. На libsignal он ложится естественно, доберёмся.

OIDC не подходит по смыслу: это провайдер, который знает кто ты и когда зашёл. А аккаунт у нас анонимный, без почты и телефона. Регистрация выдаёт UIN и токен под ключ, сгенерированный на устройстве, пароля нет вообще.

Роли пока примитивные: владелец и участники, вся модерация на владельце (кик, закреп, кто может постить, закрыть группу). Полноценных админов и модераторов нет, хотим добавить.

Про эфемерный ключ: вы смотрели v=1, это запасной режим (ECIES) для случая, когда у собеседника ещё нет libsignal-бандла. Боевой путь v=2, там полноценный libsignal: X3DH/PQXDH плюс Double Ratchet, ключей хватает и forward secrecy на месте.

  • То есть переустановка - это потеря аккаунта, доступ к нему больше не вернуть, только создавать новый?

  • Как искать других пользователей?

  • И утеря аккаунта - утеря истории?

  • Как подтверждать пользователей, то есть подтвердить, что за данным UIN-ов нужный человек (например, чтобы его добавить в закрытую группу)?

  • Как бороться с ботами и спамом, когда в открытую группу заходит кто угодно и может постить что угодно (включая запрещённую информацию)?

  • Если нужна максимальная анонимность и полноценный peer-to-peer, то смотрели в сторону Tox и Briar?

По порядку.

Переустановка и потеря устройства. Да, аккаунт это ключ, сгенерированный на устройстве, без пароля, почты и телефона. Снёс приложение без бэкапа, ключ пропал, UIN не вернуть: на сервере нет ни пароля, ни почты, чтобы что-то сбросить. Это осознанная цена анонимности, по смыслу как seed-фраза у криптокошелька. Сейчас восстановления нет, шифрованный экспорт ключа и истории в планах.

Поиск людей. По UIN или QR, обмен происходит вне сервиса, как в ICQ. Плюс есть «Люди рядом» (геохеш, без точных координат), случайный чат и поиск групп.

История. Лежит локально и шифрованно, сервер сообщения после доставки удаляет, да он их и прочитать не может. Поэтому потеря аккаунта это потеря истории, серверу просто нечего отдать. Лечится тем же локальным шифрованным бэкапом, что и ключ.

Подтвердить, что за UIN нужный человек. Через safety numbers, это отпечаток ключей как в Signal: сверили число лично или по другому каналу, значит за UIN тот, кого вы ждёте. Плюс приложение предупреждает, если ключ контакта сменился. В закрытую группу владелец добавляет по UIN, а доверие к этому UIN вы проверяете отпечатком.

Боты, спам, запрещёнка в открытых группах. Тут честно: сервер контента не видит (sealed sender плюс e2e), поэтому серверной модерации по содержимому быть не может в принципе. Что есть на деле: модерация на владельце (кик, кто может постить, режим «пишет только владелец», закрыть группу), репорты с баном UIN, антифлуд-лимиты. И свежее: регистрацию на сервере-острове теперь можно закрыть инвайтами, тогда заходит не кто угодно, а по приглашению. Полноценные роли модераторов ещё дорабатываем. Если остров публичный и открытый, модерация это зона его владельца, у self-host тем более их собственная.

Tox и Briar. Смотрели, по духу они нам ближе всего. Briar это Tor плюс p2p, метадата-стойкость отличная, но цена высокая: нужен Tor (задержки, батарея), доставка обычно требует, чтобы обе стороны были онлайн, мультидевайса нет, UX тяжёлый. Tox это p2p поверх DHT, а DHT светит ваш IP и presence узлам сети, и с офлайн-доставкой там туго. Мы сознательно выбрали тонкий сервер-релай: он держит очередь из запечатанных блобов, которые сам прочитать не может, зато сообщение дойдёт, когда вы офлайн, и поверх этого живёт обход блокировок. Это просто другая точка на шкале: не федерация (Matrix, XMPP) и не чистый p2p (Tox, Briar), а минимум метаданных с обычным сервером доставки. Для близкого радиуса и офлайна у нас есть локальный mesh по Bluetooth (в том числе и внутри одной локальной сети по WiFi Direct).

С историей будут проблемы, хранить на мобильном клиенте не получится, она слишком быстро (2-3 года активной переписки) займёт всё свободное место. Нет варианта часть истории скидывать в архив?

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

Да и relay-сервера видят ip-адреса пользователей. Можно выбрать relay-сервер, к которому подключаться, чтобы цепляться только к доверенным серверам?

Как сервера друг друга находят? Как работает маршрутизация, если Alice подключилась к relay1, а Bob к relay2, и Alice хочет отправить сообщение Bob-у?

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

Медиа и IP. Клиент ходит только на свой сервер, не по сторонним URL. Картинка лежит блобом на том же бэкенде и тянется по id. Наружу IP не утекает, свой сервер контент всё равно не видит.

Relay видит IP. Да, любой сервер видит ваш TCP-адрес, без Tor/VPN никак. У нас знание расщеплено: relay видит IP, но не личность и не контент (TLS-туннель), бэкенд видит личность, но IP уже relay. Пул наш, конфиг подписан. Нужен полный контроль над IP, поднимаете свой остров. Выбор relay вручную на радаре.

Яна на relay1, Саша на relay2. Поправлю: такой модели у нас нет специально. Federation и s2s нет, острова изолированы, Яна и Саша общаются только на одном острове. Relay это не роутер между серверами, а дверь обхода блокировок перед одним бэкендом. Какую дверь ни выбери, попадёшь на тот же сервер.

Sign up to leave a comment.

Articles