Comments 23
Мы опубликовали исходный код наших разработок
Интересно вы ведете разработку. Одним коммитом зафигачили всю кодовую базу? А где история, где до этого вы вели разработку?
И мотивацию, которая сподвигла написать свое решение.
- В matrix идентификация пользователей похожа на e-mail:
alice@server.com. У нас идентификатор пользователя — случайное число. За счет отсутствия привязки идентификатора к серверу, у нас пользователь может переезжать между серверами со всеми своими данными. - Протокол позволяет проксировать соединения пользователя между хабами. Например, пользователь U(a) не может напрямую подключиться к своему хабу H(a), но может подключиться к H(b). За счет проксирования получается цепочка соединений
U(a) <-> H(b) <-> H(a). - Серверное приложение из коробки имеет массу настроек под разные юрисдикции, включая российскую.
- Мы используем WebSocket, а не REST.
- У нас есть голосования с цифровыми подписями, которые можно использовать для согласования документов.
- У нас нет звонков, но наш проект еще слишком молод. На сегодняшний день он уже способен работать и решать задачи пользователей.
- У нас нет API для ботов и интеграций. Причина полностью аналогична предыдущему пункту.
на какой рынок нацелены Вы?
Мы разрабатываем мессенджер как корпоративный инструмент, но и про физиков не забываем :) в корпорациях же все равно работают люди, которые пользуются и телегой и WhatsApp. Они ведь видят как можно удобно сделать инструмент, поэтому мы тоже стараемся сделать его удобным для людей.
С кем бы перетереть?
sazonovd@corp.ymessenger.org можете найти меня по почте в нашем приложении или @DmitriySazonov в телеге
Матрикс вон уже много лет активно разрабатывается и довольно большой командой, с нехилым финансированием и поддержкой, но до сих пор ещё много всего доделывать и развивать нужно.
Мне кажется, Вам с текущими идеями было бы оптимальнее присоединиться к разработке протокола Матрикс и привнести туда свои идеи — там очень активное сообщество, которое с удовольствием поддержит ваши идеи, обсудит, проанализирует, и, возможно, даже активно подключится к разработке! И даже если Ваши идеи там вдруг не особо поддержат — Вы всегда можете сами поверх Матрикса запилить то, что там нехватает для Вас и Ваших клиентов, в своей реализации клиентов и серверов.
Я уже несколько компаний перевёл со всяких Слаков-Вайберов-Вацапов-Скайпов-Рокетчатов на Матрикс, и все счасливы!
Из того что Вы описали по недостаткам — всё это уже запланировано в Матриксе, но пока у них руки не дошли:
— Децентрализованные аккаунты
— Вебсокеты
— Синхронизация через другие сервера, если нет прямой связи с конкретным сервером.
И даже p2p-клиенты без сервера: matrix.org/blog/2020/06/02/introducing-p-2-p-matrix
Также стоит учесть, что Матрикс разрабатывает в первую очередь не «ещё один мессенджер», а открытый универсальный протокол для мессенджеров, на базе которого уже сделано несколько разных реализаций серверов и клиентов, а также вполне рабочие мосты в другие сети.
1)
Как вы считаете кол-во не прочитанных сообщений?
Получается у вас есть автоинкремент по chatID?
И структура userReadSeq: int?
Расскажите подробнее про этот момент, т.к. если у вас автоинкремент, то получается один чат может поддерживать 1 сервис, если есть горизонтальное масштабирование.
2)
И еще беглым взглядом посмотрел.
Допустим у нас есть 100 сообщений, пропадает интернет, тут приходит через WS 107-е сообщение, как вы решаете данный вопрос? request на 100 > GET < 107?
- Как считаем непрочитанные сообщения
1.1. В диалогах
Каждое сообщение хранится в двух экземплярах, по одному для каждого из собеседников. У сообщения есть флагRead:bool, а количество непрочитанных = количеству входящих сRead == false
1.2 В групповых чатах
В чатах/каналах каждый участник имеет поле с идентификатором последнего прочитанного сообщения. Количество непрочитанных = количество входящих сообщений после сообщения с ID = последнему прочитанному. - Решение этой проблемы сейчас стоит в очереди. Либо клиент будет определять момент обрыва соединения и, после соединения, запрашивать с хаба недошедшие по ID последнего известного клиенту, либо в объект сообщения добавим ссылку на предыдущее и при получении 107 клиент увидит идентификатор предыдущего — 106, определит что его нет в локальной базе и запросит его.
Возник вопрос: а как при передаче ключей от А к В обходится ситуация, когда А уже выключен (не отвечает на запросы)? Например, пользователь отложил телефон, телефон залочен, и пользователь входить в чат с ПК.
Мы решаем похожую проблему и пока не нашли элегантного решения. Мы шифруем приватный ключ мастер фразой и храним на сервере. Тогда пользователь входящий с ПК должен ввести мастер фразу для расшифровки ключа. Но это неудобно с точки зрения UX т.к. большенство пользователей не заморачиваются запоминанием мастер фразы.
Возник вопрос: а как при передаче ключей от А к В обходится ситуация, когда А уже выключен (не отвечает на запросы)? Например, пользователь отложил телефон, телефон залочен, и пользователь входить в чат с ПК.
Хороший вопрос. Да, это серьезная проблема и у нас есть только два решения:
- разбудить приложение через push-уведомление;
- сделать сервис для фоновой работы.
Ни одно из решений мы у себя еще не реализовали.
Если девайс прям выключен, то все. Без стороннего хранилища не обойтись, а мертвые клиенты на запросы не отвечают.
Хранить мастер-фразу на хабе в нашем случае достаточно рискованно, даже в зашифрованном виде. Запоминать мастер-фразу обычный пользователь вряд ли будет. Мы в интерфейсе пишем как это важно и предлагаем его куда-нибудь записать. Мастер-фразой может быть какой-нибудь афоризм, который легко запомнить или найти.
Каков у вас план по работе с СОРМ ?
В отличие от централизированных мессенджеров, мы не имеем доступа к данным пользователей на хабах. Бэкдоры для несанкционированного доступа мы не ставили и с открытым кодом это неразумно. У администратора хаба есть доступ к нешифрованной переписке и возможность запретить шифрованную переписку своим пользователям. При возникновении вопросов в рамках СОРМ, отвечать на них придется администратору хаба.
В этом вопросе наш мессенджер очень похож на электронную почту. Есть сервер с открытым исходным кодом (как Postfix), есть протокол, есть клиент с открытым кодом. Если возникает вопрос в рамках СОРМ, то ответственные лица будут задавать вопросы не (к сожалению ныне покойным) разработчикам почты, Ноэлю Моррису и Тому Ван Влеку, а владельцам сервера где все произошло.
У администратора хаба есть доступ к нешифрованной переписке и возможность запретить шифрованную переписку своим пользователям.Вот это просто никуда не годится. Это защищённость не то, что «на уровне Tox, BitMessage», но, пожалуй, даже хуже, чем у тех же Telegram и WhatsApp.
У администрации любого сервиса которым вы пользуетесь (мессенджер, почта, соц.сети) есть доступ к вашей незащищённой информации. Вы вполне спокойно доверяете свои данные каким-то людям. В нашем проекте вы можете запустить сами для себя хаб и общаться со своими друзьями только в рамках своего личного хаба. Никто кроме вас не получит доступ к этой информации.
В нашем мессенджере есть end-to-end шифрование, но это опциональная возможность. В некоторых других продуктах это обязательная опция, которая добавляет приватности, но лишает пользователей ряда возможностей. Если вы будете использовать оконечное шифрование в Y messenger, он будет защищен как Tox и BitMessage. Если не использовать — сообщения сохранятся на сервере в открытом виде и администратор будет иметь возможность читать эту переписку. Такая же возможность есть у администраторов других мессенджеров. Какой вариант использования вам лучше подходит — решать вам, мы предлагаем оба варианта.
И вообще, если шифрование сделать возможно, то для чего вообще делать режим без шифрования, почему не шифровать всё?
блокчейн не приспособлен для обработки быстрых вставок
Это почему это? Это ж не биток, при адекватной реализации (типа KSI blockhain) хоть миллиарды транзакций в секунду.
И ещё… Чего лишены большинство (если не все) мессенжеры — это удобной работы с историей сообщений, типа поиска (ключевые слова, даты, etc), тэгов (на отдельные сообщения или индивидуальные негрупповые чаты) и букмарков (фаворитов) — вот это реально киллер-фича, всё остальное уже более-менее одинаково у всех.
Также было бы очень ценно иметь возможность адекватных бэкапов аккаунта (полных и инкрементальных) со всей историей всех сообщений (со всеми метаданными и файлами) в любой момент, как с помощью API так и по плану, в любое удобное место (как минимум локальный бэкап + sftp, а не куда-то в чужое облако), в легко машинно-читаемом документированном формате (json/xml или типа того) с возможностью восстановления из оного даже если все активные устройства одновременно сгорели (но пользователь ещё помнит пароль на зашифрованный бэкап).
Разумеется, всё это в сочетании с прозначной синхронизацией между любым набором устройств (desktop + mobile), но это вы уже вроде реализуете (если я правильно понял).
Из всех существующих мессенжеров (не считая корпоративных, их я не смотрел) выше упомянутое не реализовано нигде, или реализовано очень неудобно, неполно и со странными ограничениями.
1) какие то оптимизации\пережимы медиа делаются?
2) где и как формируются фамбнейлы для видео?
Архитектура Y messenger