Зачем пишем?
Давным-давно в одной далекой стране была компания America Online. И был у нее удивительный частный Интернет за заборчиком, где вместо URL-ов были "keywords": что-то среднее между адресом веб страницы и купленным ключевым словом в рекламе. Компании боролись за интересные ключевые слова, как сейчас борются за домены, а реклама выглядела так: "посетите нас во всемирной сети по адресу www.example.com, или наберите AOL Keyword: 'banking'".
История имеет свойство повторяться. Сейчас роль Америки Онлайн играют основные мессенджеры: все они за заборчиками, несовместимы друг с другом, все изобретают свои keywords, желают схватить пользователя и уже никогда не отпускать. Компании не заинтересованы в открытости: более крупные игроки не желают делиться пользователями с более мелкими и уж тем более становиться открытыми. В результате невозможно послать сообщение даже из WhatsApp в Facebook Messenger, несмотря на то, что оба принадлежат одной компании. Да и пользователи ценят надежность и удобство выше абстрактной открытости, хотя многих раздражает, что часть друзей, например, в Telegram, часть в WhatsApp, а родители в Skype.
А вот роль открытого интернета, к сожалению, сегодня не играет никто. Ситуацию хочется изменить. Если XMPP не справился, может быть кто-то другой сможет? И тут рассказ про Tinode.
Что такое Tinode
Tinode — мессенджер с полностью открытым исходным кодом на Github. Все клиентские приложения (ReactJS и Андроид) лицензированы под Apache 2.0, для того, чтобы упростить создание коммерческих приложений на основе Tinode, сервер под GPL 3.0. Цель проекта — создать федерированный мессенджер, который прост и удобен как для пользователей, так и для операторов. Поставил — и все работает, как MySQL или Nginx. В долгосрочной перспективе цель проекта – создать открытую альтернативу существующим проприетарным мессенджерам, повторить в отношении мессенджеров то, что сделал Android в отношении операционных систем для мобильных телефонов.
Что он умеет
Поддержка множественных устройств.
У всех есть смартфон, иногда не один, плюс часто удобно использовать web-приложение с основного компьютера. Поэтому поддержка множественных устройств была одним из главных требований к проекту, что определило основные архитектурные решения. Если пользователь авторизуется с нового устройства, то не хочется, чтобы он начинал с чистого листа как в WeChat. А это означает, что нужно и адресную книгу, и сообщения хранить на сервере, что и было реализовано.
Очевидно, что хранение информации пользователя на сервере подходит не всем, так как создает риски нежелательного доступа: чем больше копий данных хранится в разных местах, тем выше вероятность, что что-то пойдет не так. Для этого предусмотрена возможность эфемерных сообщений и сообщений, которые удаляются с сервера после доставки клиенту. Технически, существует и возможность не хранить контакты на сервере постоянно — клиент отправляет их на сервер в момент подключения (login), затем они удаляются после logout. Однако, авторы посчитали это непрактично сложным и не стали делать.
Онлайн статус
Трансляция онлайн/оффлайн статуса пользователя в мессенджерах воспринимается как что-то само собой разумеющееся, однако, это весьма тяжелая в реализации фича. Нужно, чтобы она "просто работала", предсказуемо и надежно. Надежность работы исключила генерацию статуса на клиенте, как это реализовано в некоторых XMPP приложениях. В случае Tinode, сервер генерирует онлайн статус и рассылает по адресной книге, что, опять же, требует хранения контактов на сервере и их синхронизацию с клиентскими приложениями.
Простота протокола
Протокол хотелось сделать таким, чтобы кривая обучаемости была пологой – не нужно знать всего, чтобы начать. Спецификация получилась очень компактной: 10 запросов клиента, 5 ответов сервера. Например, по сравнению с 200+ страницами только core XMPP, не считая extensions, это почти записка на салфетке.
Представление данных отделено от сетевого протокола. Протокол лишь требует определенную структуру данных, но не требует, чтобы они передавались по сети каким-то определенным образом. Сейчас сервер поддерживает JSON по websocket и long polling, c TLS и без, плюс gRPC по TCP. Поддержка gRPC была реализована одним разработчиком за две недели, включая написание текстового клиента на Питоне. Добавление поддержки иных форматов данных и протоколов, например, MessagePack или Noise, вряд ли займет намного больше.
Расширяемость
С одной стороны, хочется, чтобы все работало сразу, например, чтобы основной функционал был сравним с WhatsApp и Telegram прямо из коробки. С другой, потребности у людей разные и нужно иметь возможность расширять функционал. Поиск баланса похож на выбор между монолитной архитектурой и микросервисами: нежелательно иметь неизменяемый монолит, и, аналогично, плохо получить получить зоопарк микросервисов, управление которыми превращается в отдельную задачу.
Было принято решение разделить функционал на три части — основной, сетевой и вспомогательный. Основной — это то, что позволяет Tinode выполнять основную функцию — пересылать сообщения. Сетевой — функционал взаимодействия в серверами, как формат передаваемых данных и сетевой протокол. Вспомогательный — то, что решает чью-то локальную задачу, например, поддержка конкретной базы данных в качестве бэкенда или какой-то метод авторизации, но никак не влияет на другие сервера или пользовательские приложения. Основной функционал реализован в основном коде. Сетевой функционал выделен, но также хранится в основном репозитории для того, чтобы по возможности избежать создания несовместимых серверов. Вспомогательный реализован в виде плагинов — компилируемых Go интерфейсов (поддержка разных баз данных, разных авторизаторов, пуш нотификации, валидаторы по емейл или телефону, поддержка каптчи и т.п.) и gRPC endpoints (чатбот и поисковый интерфейс).
Прочее
- Возможность, но не требование привязки счета к телефону или емейлу или ещё чему угодно.
- ID пользователей, которые трудно угадать, и, соответственно, трудно разослать спам.
- Tags, позволяющие реализовывать поиск людей как в WeChat (и, подобно WeChat, встроить в мессенджер службу знакомств) или разделить организацию на отделы как в Slack.
- Возможность подключения пользователей без регистрации, необходимая, например, для организации службы поддержки через чат.
- Интерфейс и пример подключения чатботов.
- Планы создания каналов как в Telegram.
Почему Go?
Сервер для мессенджера по сути роутер: получает сообщение из одного канала, как-то его обрабатывает, затем передает в другой канал или каналы. Go (как и Erlang, но это уже другая история) идеально подходит для создания такого функционала т.к. содержит примитивы goroutine и chan, делающие организацию потоков и обмен данными между ними эффективным и простым.
Безусловно, роутер можно написать и на C/C++, и на Java. Однако, при прочих равных, код скорее всего получится более сложным и потребует больших усилий для избежания дедлоков.
А что потом?
Федерация
Одна из основных задач для Tinode на ближайший год — создание платформы для федерации. Так, чтобы любой желающий мог запустить свой Tinode сервер, который бы мог обмениваться сообщениями с любым другим сервером, точно так, как это возможно с емейлом. Уже сейчас возможна кластеризация серверов. Сетевой обмен между сервером и клиентами идет по TLS websocket, что для внешного наблюдателя мало отличимо от простого HTTPS трафика.
Публичный DNS, вероятно, будет использоваться, по крайней мере первоначально. Однако, в будущем поиск чат-серверов будет осуществляться также, как это сделано в Bittorrent — при помощи DHT, распределенной хеш таблицы.
Хочется также избежать и проблем, за которые часто критикуют XMPP. Например, XMPP сервера очень разговорчивы. До половины сообщений является дублирующими, когда XMPP-клиент рассылает онлайн уведомления индивидуально каждому контакту из адресной книги.
Репутация и распределенное принятие решений
Системы обмена сообщениями больше всего похожи на емейл. Как известно, значительная часть электронной почты — спам. Не хочется повторять чужие ошибки, поэтому механизмы, ограничивающие спам, должны быть сразу встроены в систему. Полностью задача пока не решена, но есть общее направление:
- Криптографическая идентификация сервера-отправителя.
Изначально, SMTP вообще не предполагал какой-либо идентификации отправителя. Не стоит снова наступать на эти грабли. Каждый сервер, желающий установить контакт, будет представлен криптографическим сертификатом. "Ну да", скажете вы, "я сейчас нагенерю 100500 сертификатов и каждый раз буду представляться новым чистым сервером". И будете правы. Поэтому следующий пункт. - Распределенный учет репутации.
Когда к нам стучится новый, неизвестный сервер-отправитель, мы сделаем запрос к известным серверам с просьбой сообщить рейтинг нового сервера. И в зависимости от ответа установим, например, скорость, с которой новый сервер может посылать нам сообщения.
Если посмотреть на распределенную систему принятия решения и учета репутации с высоты птичьего полета, то станет заметно сходство с blockchain. Возможно, blockchain (но не криптовалюта) может быть использован в качестве основы для построения распределенной системы репутации, хотя пока и не очевидно каким образом.
Шифрование
Ну а как же в наши дни без шифрования сообщений? Чаты между двумя людьми, вероятно, будут шифроваться OTR. С групповыми чатами пока непонятно. Все известные схемы шифрования групповых чатов либо имеют значительный недостатки, либо тяжеловесны и сложны в реализации. Также, не очевидно, насколько важно шифрование групповых чатов: "Если тайну знают двое – это уже не тайна, а если трое – это уже базар."
Что вы по этому поводу думаете?
softaria
xkcd.ru/927?
patsuckow
К сожалению вы правы. Много людей в мире, в особенности разработчики, хотят один браузер, один мессенджер и т.п., и чтобы забыть про эту неразбериху и нарастающую коллизию кол-ва новых стандартов и технологий, которые хотят «всё и всех объединить», а на практике создаются новые «ветви в деревьях». В нас в людях, видимо, заложено желание объединения, но по факту мы только и делаем, что разъединяемся.
Lamaster
Да фиг с ними с браузерами и мессенджерами. Лишь бы интернет один был, а не китайский, руссский, севернокорейский.
patsuckow
и то верно, а то ведь всё именно к этому и идёт
jrthwk
Так или иначе «свободного интернета», увы, не будет.
«Китайский, руссский, севернокорейский» — это когда его вводят в рамки тупо и грубо. Когда это делается квалифицированно и профессионально — получается «аоловский, гуглевский, амазоновский, етс».
firedragon
в США продавливаются законы об отмене «Сетевого нейтралитета», так что будет сегрегация по национальному типу. Своеобразное технологическое рабство.
chupanebre Автор
XKCD прав только отчасти. Сетевые эффекты существуют.
Во-первых, тут не только API, но и продукт, который становится полезнее с ростом количества пользователей. Как vk или вообще WeChat — нет смысла пользоваться еще чем-то, если все друзья тут, а не там.
Во-вторых, даже для API XKCD не совсем прав. Если есть экосистема, то она сама себя поддерживает и усиливает: статьи, курсы, люди знающие платформу ее популяризируют.
Может быть и 14 конкурирующих стандартов по XKCD, но доли рынка у них разные.
qrKot
>> Может быть и 14 конкурирующих стандартов по XKCD, но доли рынка у них разные.
Собственно, с такой подачей это именно просто 15-й стандарт. Непонятно, что его от остальных отличает… Их и «открытых» уже вагон и маленькая тележка.
Просто в статье вы пишете, что «xmpp пробовал, не получилось. Может быть, у нас получится...» А на выходе получается, что даже и не пытаетесь. У xmpp, хотя бы, транспорты были…
lixmix
Самое время создать еще один, не совместимый с существующими решениями? Все описанное на этой странице можно сделать на основе XMPP, затратив намного меньше усилий в серверной части.
.
Если бы Вы почитали более подробно о ХМПП то Вы бы знали, что для доставки сообщений в XMPP вполне можно использовать Websoket, http запросы. В вашем примере Вы дублируюте Ejabberd http api docs.ejabberd.im/developer/ejabberd-api/admin-api Это работает через JSON запросы.
Kobalt_x
Push уведомлений нет в стандарте XMPP и поэтому он не нужен, А XEPы кто поддерживает кто нет, фиг разберешься
lixmix
Это очередное заблуждение. Протокол XMPP активно развивается. Чего не было лет 5 назад, теперь есть.
xmpp.org/extensions/xep-0357.html
Конкретно по серверам:
mod_push — в ejabberd.
mod_cloud_notify — Prosody.
В других серверах возможно тоже есть, не курсе
andreymal
Основная проблема в том, что этого всего нет и никогда не будет в качестве обязательной части XMPP. Есть и будут тысячи и тысячи серверов, в которых нет и не будет ни mod_push, ни MAM, ни OMEMO, ни Message Carbons. А многие клиенты до сих пор даже банальное уведомление о доставке не поддерживают! Не говоря уже об общепринятом нынче уведомлении о прочтении. И всё это легаси не даёт XMPP развиваться. Нужно сделать новый протокол хотя бы потому, чтобы всё легаси спокойно выкинулось. (Про убогость устаревшего на десять лет XML-based протокола вспоминать в этом комменте не буду)
lixmix
Вы немножко неправильно понимаете смысл создания XMPP.
XMPP это не мессенджер. Это протокол. Его цель было объединить множество разных несовместимых друг с другом мессенджеров в одну сеть коммуникации.
Никто не обязан поддерживать тысячи расширений или навязанную технологию.
XMPP это как линукс. XMPP — это как конструктор, где каждый берет свое.
Как есть WhatsApp, Telegram, Yadex, Google, внутри XMPP своя вселенная из мессенджеров и серверов/ Gajim, Conversations, Dino im., 404, жаббер.ру, жаббер.ат, национальные сервера и т.д.
В ХМПП любой может написать свой XEP или даже не писать, а прикрутить молча прикрутить свое ( социальные сеть и веб-клиент Movim.eu, блоги juick.com )
XMPP это концепция расширяемого протокола для связи между разными, не полностью несовместимыми мессенджерами. Цель ХМПП создать универсальный канал общения. XMPP это не мессенджер, а над месседжерная структура.
andreymal
Именно поэтому разные реализации XMPP очень плохо совместимы друг с другом, и упомянутой вами цели — объединения — XMPP так и не достиг.
У линукса та же самая проблема, да.
lixmix
Условно достигнута. Все мессенджеры поддерживающию XMPP, поддерживают общения между собой. В настоящее время решена, так же передача файлов между разными клиентами. Из жаббера сейчас даже можно отправить файл ссылкой, тому кто не жаббере.
Есть конечно устаревшие клиенты в которых нет новых функции, но с устареванием сталкиваются любые программы.
Большинство пользователей жаббера на мобильных используют conversations, который крайне неплох и вполне современный мессенджер.
Самая большая проблема хмпп это плохая информированность о нем. У большинства людей представление о жаббере из 2000 годов. С этих пор многое в ХМПП изменилось.
Картинки здесь не в почете, поэтому отправлю вам ссылку, как выглядит современный жаббер play.google.com/store/apps/details?id=eu.siacs.conversations.legacy
andreymal
Ну давайте начнём по порядку с вашей же ссылки.
XHTML-IM не поддерживает — половину сообщений невозможно прочитать так, как задумал автор.
Ресурсы и приоритеты не показывает — кому куда откуда как идут сообщения, непонятно.
Не-legacy версия по умолчанию включает OMEMO (мне рассказывали) — сразу же отваливается совместимость с Psi+ и остальными, кто не поддерживает.
Подключаться по 3G может полминуты. Телеграм подключается за полсекунды.
Без поддержки MAM сервером регулярно теряет сообщения — неоднократно проверено лично мной, Conversations для меня основной джаббер-клиент. Для надёжности Carbons и SM недостаточно.
Звонков нет. А между теми клиентами, где есть, созвониться — целое достижение.
MUC — срисованное с IRC убожество, что вроде как признают даже сами авторы (где-то был XEP об этом). В конференциях файлы кроме как ссылками передавать невозможно. О звонках даже не мечтаем (привет от Skype, Discord и Mumble).
Это только из того, что сходу вспомнил. Если глубже копнуть, можно ещё десятки несовместимостей и проблем упомнить.
А простая передача plain текста без гарантий надёжности — единственная задача, с которой в XMPP справляются действительно все — никому нахрен не нужна в 2018-м. Такой XMPP нам не нужен.
lixmix
Форматирование текста, есть в умеренном количестве. Можно сделать текст жирным, курсивом, исправить ошибку в уже отправленом сообщении.
В современном жаббере сообщения идут на все подключенные устройства и зашифрованные сообщения тоже. Ваш сервер действительно поддерживает
Psi+ поддерживают уже омемо через плагин. Недавно добавили. Потом, омемо можно отключить или выставить по умолчанию в настройках другое значение. Кто ставит не легаси версию знает что он делает и ему это нравится. Зачем ограничивать людей в их пожеланиях?..
Может быть телеграм он и не отключается? Скорость подключения зависит от географического расположения сервера.
Если включенны 2 устройства, если одно то всегда почти доходит (В частности на сервере 404) В настройках можно поставить посмотреть статус доставки. Использовать сервер с хранением сообщений или нет, выбор конкретно каждого пользователя.
> Для надёжности Carbons и SM недостаточно
Если Ваш сервер действительно поддерживает Carbons, вопроса ниже не должно было быть.
>Ресурсы и приоритеты не показывает — кому куда откуда как идут сообщения, непонятно
Зайдите в настройках в информацию в о сервере и посмотрите поддержку хепов. Возможно вам необходимо сменить сервер. В жаббере важно выбрать хороший сервер и клиент, если это сделано, дальше все как по маслу. Многие по незнанию выбирают не обслуживаемые серверы и клиенты, что портит впечатление о ХМПП
Можно отправить аудиосообщение
Посмотри свои настройки. У меня показываются фотографии как фотографии. В настройках может быть лимит на размер загружаемой картинки
andreymal
Ваша наивность зашкаливает.
lixmix
Вас и ваши собеседников никто не заставляет пользоваться плохими серверами и устаревшими клиентами!.. Если вы или ваш собеседник это используется пеняйте только на себя!
Как вы не понимаете. Жабберу уже почти 20 лет. За это время изменилось множество технологий и появилось множество жаббер клиентов. Часть из них писали любители.
Кто езаставил поставить его! У моих собеседников( это реальное использование), почти у всех новые версии! Потому что я просто им говорю, что этот лучше. Если кто-то отказывается переходить. Значит его ничего не раздражает. К сожалению я новый пользователь хабра, если бы я мог поставить минус, я бы поставил Вам минус, так же как и вы мне.
Почему то никто из моих собеседников не огорчился появление новой версии, наоборот обрадовались. Некоторые поставили легаси и теперь у них две версии Conversations (как и у меня также).
Почему вы приувеличиваете, когда говорите об новом обновлении, как о какой-то глобальной проблеме?
Процентов 99% обновление никак не затронуло. Опытные пользователи сейчас почти все на ОМЕМО (не в обиду вам), а те кто неразберается ничего даже не заметил.
Попробуйте сервер 404.city. Ваше сообщение 100% дойдет! Пробовал так делать и неоднократно
Да, в жаббере есть такая проблема, что люди регистрируются на заброшенных, любительски[ сервера и выбирают устаревший клиенты и после чего хейтят жаббер как технологию.
Решается проблема довольно просто, информирование о том что такое хмпп, как им пользоваться, какие есть хорошие клиенты и сервера, о различиях в них.
Говорил и не раз. Люди удивленно и с интересом расматривали.
Если людям сразу сообщаещь, каой сервер хороший и какой клиент хороший, никакого батхерда нет. В гугл плее есть много плохих мессенджеров. Как вы не понимаете, что в жаббере такая ситуация.
Жаббер это не один мессенджер! Это несколько разных разговаривающий между собой
В ХМПП не теряются сообщения. Это проблемы конкретно вашего устаревшего сервера. Смените его. Экпорт конктактов есть в мессенджере гажим.
Мои родители знакомые и близкие друзья уже все в жаббере. Поставили Conversations и не жалуются. Друзьям и близким даже нравятся закрытые чаты внутри. Где они разговаривают только между собой
andreymal
Я вам минусов не ставил, я вообще-то тоже не могу их ставить (а даже если бы мог, то всё равно бы не ставил — вас не учили, что ставить минусы за мнение и тем более за факты это неправильно?)
Так они вообще не в курсе, что используют что-то устаревшее!
А у моих (это реальное использование) повсюду QIP'ы до сих пор. Если я предложу им поменять клиент и тем более сервер — меня просто пошлют.
Уверен, ваши собеседники — такая же кучка гиков, как и мы с вами. А мои собеседники — обычные пользователи, для которых XMPP — лютое неюзерфрендли.
Вот опять вы доказываете: XMPP — для небольшой кучки опытных пользователей.
Как мне заставить переехать все свои контакты на этот вот 404.city?
Ещё раз: обычным пользователям насрать, они не слышали и не желают слышать ни о каких SM, MAM, OMEMO и прочих непотребствах — они просто хотят брать и чатиться. Поэтому они берут WhatsApp, Viber и Telegram. Я активно занимался пропагандой джаббера ещё в 2008-2012 годах (ох уж эти школьные годы) и гарантирую вам, что всем насрать.
Я тоже (см. выше). Видимо, вы разговариваете с кучкой гиков/айтишников, а не, например, с бабушкой.
Им насрать, см. выше
Да не разговаривают они между собой! Смотрите мою фотку — Conversations не осилил XHTML-IM. Про потерю сообщений тоже уже говорил.
Ещё раз: моим собеседникам насрать. Никто не станет менять сервер и JID ради меня.
Я регулярно делаю бэкап контактов в своём Psi+, но обычный пользовать и знать не хочет про существование какого-то там экспорта.
Потому что вы им всё настроили и за ними следите. Обычный пользователь без помощи в лице знакомого тыжпрограммиста не осилит «стандартный» XMPP и пойдёт в WhatsApp.
И вообще, смена сервера — это боль, которую экспорт контактов смягчает лишь отчасти.
lixmix
Смените сервер на 404.city. Вы выбрали устаревший или не обслуживаемый сервер.Ваш сервер не поддерживает http upload. Из-за это у возникают проблемы с хмпп и не появляется кнопка. На фото доказательство, того что в конференциях можно отправлять картинки
Эта ссылка отправлена из жаббера и актуальная только сейчас. Фаил автоматически удалится через 2 дня: Ссылка на фаил
Не надо потом, ставить минусы из-за того что картинки больше нет.
lixmix
Извиняюсь. Вот ссылка на скриншот жаббер-конференции, где видно что фотографии в ней прекрасно отправляются и доходят из Conversations Ссылка на скрин
Вы выбрали плохой жаббер сервер из-за чего и испытываете трудности с использованием xmpp
lixmix
Перезалил на файловый хостинг, для тех кто захочет посмотреть после того как файл сострется с жаббер сервера ibb.co/f10JJy
wlr398
В том и проблема. При выборе WhatsApp не нужно задумываться плохой он или хороший, он просто работает.
lixmix
Я хочу сказат вам тоже самое, но другими словами:
Просто все знают о WhatsApp, а что такое жаббер и как им правильно пользоваться нет. (Если бы ватсап был свободным и федерализованным, за 20 лет, к нему бы тоже понаписали плохих клиентов и наделали плохих серверов.) В жаббере надо знать хороший клиент и сервер и тогда никаких проблем с ним нет
Cryvage
Проблема заключается в «и как им правильно пользоваться». Чтобы технология имела популярность в широких массах, она должна обладать одним важным свойством. Ей должно быть невозможно пользоваться неправильно.
Конечно, жаббер это не мессенджер. Это протокол. Стандарт. Ну так давайте оценим его как протокол. Как стандарт.
Как оценивать? Начнём, пожалуй, с результатов. А результаты не очень. Популярность низкая. Проблемы присутствуют. Попробуем разобраться в причинах.
Вы вот выше доказываете, что проблемы, либо от «неправильного» клиента, либо от «неправильного» сервера. Ну, в определённом смысле это так. И выбрав «правильные» клиент и сервер, многих проблем можно избежать. Но почему всё именно так? Почему какие-то люди сидят, и пишут «неправильные» клиенты, держат «неправильные» сервера?
Вопрос можно было бы назвать риторическим. Кто же их знает, верно? Однако, мы ведь пытаемся оценить не конкретные клиенты и сервера, а протокол. Что сделал жаббер, как протокол, чтобы предотвратить появление этих «неправильных» клиентов и серверов? Ничего. С точки зрения протокола эти клиенты и сервера не являются «неправильными». Они «неправильные» с точки зрения современного пользователя, но не с точки зрения стандарта. Стандарту они соответствуют. Это говорит о том, что стандарт не отражает потребностей современного пользователя. И это однозначно говорит о том, что он плох. Да, именно так. Жаббер плох. Плох как протокол. Как стандарт.
Как так получается? Ведь вроде бы и развитие есть. И вроде бы даже реализуемые новшества вполне релевантны. На мой взгляд, всё дело в расширениях. Это гнилой подход. Это не годится для стандарта. Это не годится для протокола. В протоколах и стандартах важны гарантии. А когда всё на расширениях, то о каких гарантиях может идти речь? Когда какие-то функции вынесены в расширения — их поддержка не обязательна. Это равносильно отсутствию гарантий. А что, собственно, гарантировано стандартом без расширений? Тупо передача текста, который может будет доставлен, а может и нет. Что характерно, именно в таком виде это и работает, более или менее, везде, не зависимо от клиента или сервера. Что посеешь, то и пожнёшь.
lixmix
Причины:
Основная проблема ХМПП:
Высокая степень децентрализации создает хаос. В ХМПП децентрализованная разработка, децентрализованные сервера, децентрализованные расширение(стандарты), децентрализованное обновления, децентрализованные стандарты шифрования, но жаббер таким и задумывался.
Что бы каждый из разработчиков мог слепить из хмпп свой идеальный мессенджер, такой каким он видит его сам, а не плясал под чужую дудку
lixmix
ХМПП пытается решить проблему совместимости несовместимых мессенджеров, сохранив при этом децентрализацию.
Если сделать его централизованным, конечно можно решить все проблемы, но тогда это будет уже не жаббер
andreymal
Поэтому он не взлетел и никогда не взлетит.)
Пляска под чужую дудку — это как раз следование стандарту XMPP. Все по-настоящему независимые разработчики изобрели свои протоколы, не завися ни от кого (фейсбук, ВК, телеграм и т.п.) Один лишь WhatsApp оказался исключением, но много ли кастомных XMPP-клиентов подключаются и работают к WhatsApp-серверам?
lixmix
В стандарте ХМПП можно свободно написать свой стандарт, поэтому я с этим не согласен.
ХМПП как и сделан так, что любой мог написать свой стандарт внутри стандарта. ХМПП как матрешка. Единственно что должен поддерживать, что бы считаться полноценным, это отправку сообщений в XMPP, через вебсокет, http это уже там неважно
andreymal
И это будет уже ни с кем не совместимый ХМПП. От этого нет никакой пользы.
lixmix
Нет. Он будет совместимым. Протокол ХМПП это очень растяжимый термин.
lixmix
Кратко философия ХМПП:
Пиши любой месенеджер который хочешь, но что он мог отправить сообщение в любой другой мессенджер с хмпп
andreymal
WhatsApp это не позволяет. Conversations не понимает XHTML-IM, полученный от другого «любого мессенджера». Сообщения без MAM теряются на плохом интернете. Мессенджеры без поддержки шифрования не могут прочитать сообщения с шифрованием. Серверы, требующие шифрование, не позволяют передавать сообщения мессенджерам, не умеющим в шифрование.
Вывод: философия ХМПП не работает.
lixmix
Согласен с Вами, не все так идеально как хотелось, но здесь довольно скопилась большая цепочка сообщений уже, поэтому предлагают продолжит обсуждение в конфе не работающего жаббера)
Cryvage
Так именно в этом и проблема. Стандарт говорит что этого достаточно, и может когда-то так и было, но запросы современных пользователей намного больше. Простая отправка сообщения это не уровень современного мессенджера. Это сгодится для интеграции мессенджера с каким-нибудь игровым чатом, или системой оповещений сайта. Но полноценному мессенджеру нужно больше функционала, и не должно быть серьёзной деградации этого функционала, при использовании пользователями разных мессенджеров.
В принципе, выходом могло бы стать создание некоего обобщающего стандарта, который бы собирал воедино XMPP и наиболее важные из его расширений, объявляя их обязательными. Это могло бы стать основой для создания современных мессенджеров, совместимых между собой. И в то же время это не нарушит философию XMPP, т.к. не добавляет новых, несовместимых сущностей.
lixmix
Поддерживаю. Это простая и гениальная идея
selenite
> Да, большинства серверов и клиентов создают обычные пользователи, а не компании.
То есть, если появится компания, которая сделает приложение с функцией «прыгнуть с моста», это несомненно будет серьезным основанием взять и прыгнуть с моста? Ведь приложение наверняка писали сертифицированные профессионалы на зарплате, их инвесторы наверняка тоже прыгнули с моста… Почему контроль за данными, за стилем и поведением, за общением обязательно нужно отдать некоей корпоративной сущности?
lixmix
Вот так, выглядит просмотр возможностей xmpp-сервера в conversations ibb.co/kGYG5d
Я всегда заглядываю сюда, если смотрю новый сервер.
lixmix
Я сегодня впервые на хабре, поэтому путаюсь в разметке. Вот скриншоты из клиента Conversations. Пруф, где работают картинки в групповых чатах и как можно посмотреть возможности хмпп-сервера
andreymal
Я проверял conference.jabber.ru — самый популярный сервер с джаббер-конфочками. Никакой другой сервер я проверять не собираюсь, потому что этот — самый популярный. Когда я смогу отправить файл в чатик на conference.jabber.ru — тогда и поговорим.
Чтобы не размазываться и не упираться в ограничение один коммент в пять минут, отвечу здесь на всё что ниже (точнее, выше относительно этого сообщения):
Не работает же! Я не увидел XHTML-IM и не смог отправить файл в чатик conference.jabber.ru. И сообщения я регулярно теряю, потому что на моём сервере нет MAM, а менять сервер — это боль.
Ещё раз: пользователям насрать, они ничего сложного изучать не хотят, им нужно просто взять и початиться. Хм, который десяток раз я это уже пишу? Вы своим родителям всё настроили, но в мире миллионы людей, у которых хорошего знакомого/родственника типа вас найдётся. И они просто возьмут WhatsApp.
От того, что этот ваш 404.city работает, пользователям jabber.ru и тысяч других серверов ничуть не легче. Вашей хвалёной совместимости и объединения на практике не существует.
lixmix
На скине фотография отправленная в чат bessonica2@conference.jabber.ru. Фотография в чат была отправленна с сервера 404.city. Я незнаю как с вами спорить, если вы отрицаете очевидный факт и не желаете разобратся в чем дело.
Вам нужно сменить хмпп-сервер на современный, что отправлять фотографии по http upload.Писать в чаты можно с любого сервера, а не только того на котором вы зарегистрованы. Jabber.ru самый крупный русский сервер, но далеко не самый лучший.
andreymal
Я использую jabberon.ru, у которого есть HTTP File Upload согласно его диско (upload.jabberon.ru). На conference.jabber.ru всё работает, как вы заявляете.
lixmix
Ваш сервер устал и не поддерживает http upload
andreymal
Conversations заявляет, что XEP-0363 недоступен. А почему он это заявляет при наличии upload.jabberon.ru в диско — а фиг его знает. Может, загрузка файлов на этом сервере разрешена только избранным? Тогда почему бы не написать какую-нибудь внятную ошибку доступа?
lixmix
Подтверждаю, что есть ошибка на данном сервере
Нет просто, админ неправильно настроил сервер. В жаббере можно отправлять картинки в чаты, если зайдете с 404 сами убедитесь в этом. На скрине мной отправленным последняя версия конверсатионс, аккаунт на сервере 404 и чат бессоница на jabber.ru
lixmix
Jabberon заброщенный сервер. Я проверил ваш сервер. Действительно, на вашем сервере включен http upload, но неправильно настроен администратором сервера. Вам лучше всего сменить сервер.
andreymal
Я даже опущу кучу проблем, связанных с переездом. Но вы упорно игнорируете вторую часть всех моих комментов:
А также старательно забыли про нерабочий XHTML-IM в Conversations.
lixmix
Вам нужно пересмотреть свой взгляд и не быть таким консервативным и у вас все работать отлично.
В хмпп есть сервера новой волны и мессенджеры новой волны, они радикально отличаются по возможностям от старых серверов.
В жаббер не ограничение на вход в конференции с других серверов. Можно в конференции на жаббер.ру хоть со своего сервера с http upload входить и постить там картинки.
Конкретно на вашем сервере Jabber.ru, админ обещал обновить ПО и включить http upload этим летом
andreymal
Я не смогу всю свою сотню контактов заставить пересмотреть их взгляды и повторить то же самое. А если все мои контакты продолжат использовать старьё, то какой толк от того, что я буду использовать всё самое новое и крутое? Ой, по-моему я вам это уже писал раза три.
И про http upload см. выше — на моём сервере он и так есть, как заставить его работать-то?
lixmix
Вам нужно либо обратится к админу вашего сервера, либо сменить его на 404, либо поднять свой. Можете к примеру два сервера использовать. На 404 заходить в конфы и слать оттуда картинки, а на вашем старом общаться, как общались раньше. Это же жаббер, можно плодить аккаунты тысячами)
andreymal
Умножаем эти тысячи на сотни контактов, которые должны ответить на presence type=subscribe, и получаем сотни тысяч проблем с переносом JID :)
lixmix
Если Вам будет нужно перенести аккаунту воспользуйтесь последней версий Gajim. В нем есть возможности быстро переноса контактов между серверами.
На андроиде рекомендую заносить Jabber ID в адресную книгу, где номера телефонов.
andreymal
А вот тут я уже на самом деле не в теме, как к этому отнесутся сотни серверов моих сотен контактов? Что-то я подозреваю, что presence type=subscribe им всё прилетит и побеспокоит их
lixmix
Попробуйте и узнаете) Сотня это относительно небольшое число, если они разбросаны по разным серверам. Пока они не подтвердят подписку, можно и по старому серверу разговаривать.
bogolt
А заставить всю сотню контактов переехать на новый протокол сможете?
Имхо это общая проблема всех ИМ. Те из которые поддерживают децентрализацию, шифрование и опен-сорс — недостаточно хорошо работают и не столь популярны как распиаренные проприетарные решения, которые увы рано или поздно оскайпиваются до такой степени когда пользоваться уже больше невозможно но и уйти нелегко.
Murz
Весь геморрой по переправке сообщений из Matrix в чужеродные сети и обратно берёт на себя Matrix-сервер, поэтому клиентское приложение не будет выжирать трафик, процессор и батарею.
andreymal
Кстати, вот же ещё проблема — «удалится через 2 дня». В тех же телеграмах и ВК файлы хранятся вечно (хотя бы условно). В то время как далеко не каждый любительский джаббер-сервер типа этого вашего 404.city позволит себе вечное хранение файлов.
Я пролистал XEP-0363, но не увидел там никаких настроек про время жизни файла. То есть обычный пользователь даже не может прямо через клиент узнать, сколько его файл проживёт? Только ходить на сайт выглядывать едва заметную надпись «HttpUpload 1Gb & 2 day»?
ZurgInq
Это сделал не android, а Google. Производителям мобильных устройств оказалось выгоднее использовать android который поддерживает огромный google, чем пилить каждые несколько лет свои собственные ОС не совместимые с друг другом. Сравниваем с apple у которой есть ресурсы на поддержания и развития своей собственной замкнутой экосистемы.
Текущие лидеры в мессенджерах взлетели тоже не на пустом месте, а чуть ли не буквально сжигая мешки с деньгами. Примерно тоже самое твориться с браузерами, компании лишенные денежной поддержки сдуваются (opera\mozilla). Что бы новый мессенджер в текущих условиях мог захватить хотя бы часть рынка, у него должно быть что то новое, чего нет во всех остальных, или должны быть огромные денежные вливания.
chupanebre Автор
Все правда, но прежде, чем Google популяризировал Андроид, Энди Рубин его создал.
> Текущие лидеры в мессенджерах взлетели тоже не на пустом месте, а чуть ли не буквально сжигая мешки с деньгами
Аналогично, в 2006 году Microsoft и Nokia сжигали мешки с деньгами, создавая свои мобильные операционные системы, а всех победил Андроид, с финансированием на два порядка меньше конкурентов.
Сравнение с браузерами не вполне корректно, т.к. в браузере сетевые эффект слабые — мой выбор браузера никак не зависит от выбора браузера моих друзей.
shinkareff
Насчет лидеров — WhatsApp продемонстрировал ровно обратное, никакого сжигания мешков. Да и Skype с Viber не особо потратились, до момента их покупки. Значительно дороже рост стал обходиться с 2015 года, когда ведущие игроки сформировали индустрию и оказалось, что она весьма прибыльна. Здесь, кстати, кроется одна из причин провала WeChat на международном рынке.
lixmix
Мы не знаем как все было на самом деле, но у WhatsApp была определено большая фора. В WhatsApp первыми додумались использовать номера телефонов, как Jabber ID-ы. Они загнали в ejabberd базу номера телефонов и делали подписки в зависимости от того, есть номер в адресной книги или нет.
Далее пошла реклама: Бесплатные смс-ки! Налетайте все!
Busla
он стоил 1$ в год, а не «бесплатные СМСки»
powerman
IMHO без End-to-end шифрования, в т.ч. групповых чатов — точно не взлетит. Сложно или нет, но многие мессенджеры эту фичу уже осилили, кто-то лучше, что-то хуже, и пути назад уже нет. Что касается "что знают трое" — это, конечно, правда, но далеко не вся. Риск утечки увеличивается с ростом числа участников, но не становится равным 100% начиная с трёх человек. А вот число посторонних желающих получить информацию, которая их никак не касается — постоянно растёт. Пока это были только спец.службы — это было относительно терпимо, хотя в случае наших ещё и был шанс что информация от них уйдёт "налево" и попадёт к конкурентам. Но сейчас информацию хотя вообще все подряд, для показа рекламы, для продажи, просто на всякий случай чтоб было… End-to-end шифрование позволяет отсечь 99.999% любопытствующих, оставляя место только добровольному разглашению одним из участников (с чем можно бороться разными методами, от технических до юридических) либо утечке с заражённого малварью устройства одного из участников (с чем тоже можно бороться).
Кстати, а чем не устроил Matrix?
chupanebre Автор
Никто не спорит, что шифрование нужно. Вопрос приоритетов. А приоритеты определяются соотношением потребности к потраченным силам на разработку. Потребность в шифровании, конечно, есть, но она не выглядит так, что нужна абсолютно всем и без нее никуда. Где-то видел статистику, что в Телеграме шифруется меньше 1% чатов.
Или пример емейла. Из крупных игроков еще год назад TLS для межсерверной передачи данных был только в gmail. Не end-to-end шифрование, а эквивалент HTTPS для передачи почты между серверами. И что, все из-за этого ушли с mail.ru на ProtonMail?
Хороший проект, но с другими целями и приоритетами.
powerman
Потребность есть, нет потребности что-то ради этого делать. Именно поэтому в телеграме шифруется мало чатов — потому что нужно нажать лишние кнопочки, да и вообще просто задуматься о необходимости их нажать. Плюс в десктопном клиенте они не поддерживаются, и в веб вроде тоже.
Что касается email, то TLS там никого не волнует вообще — кому нужна безопасность тот использует PGP/GPG.
В общем, суть в том, что шифрование должно работать из коробки, чтобы люди об этом не задумывались вообще. А когда задумываются — чтобы могли сверить отпечатки ключей удобным способом, чтобы убедиться что общаются именно с тем, с кем думают.
Посмотрите как выдавливают http и любой ценой заменяют на https. И на TLS в почте, да. Суть в том, что времена не шифрованных коммуникаций заканчиваются, поэтому чтобы выжить в ближайшие годы — нужна поддержка шифрования, причём не для гиков, а удобная и прозрачная настолько, чтобы обычные юзеры её использовали по умолчанию и толком даже не замечали этого.
chupanebre Автор
Согласен, все верно. Вопрос ведь не в принципе, а в приоритетах — можно потратить время на OTR, а можно на что-то другое. Что важнее пользователям, на то и нужно тратить. Сейчас, например, больше всего запросов на повторение функционала Slack-а в каком-то виде.
powerman
На OTR время тратить не надо. Я его нежно люблю, но поддержки групповых чатов и синхронизации истории между устройствами в нём, насколько мне известно, не предвидится, а значит будущего у него нет.
chupanebre Автор
А что, если не OTR?
powerman
Вероятно, что-нибудь на базе Double Ratchet Algorithm, напр.: используемый в XMPP OMEMO, Signal Protocol, Matrix…
chupanebre Автор
Так это же и есть OTR с каким-то модификациями.
Murz
А поподробней можете описать чем ваши цели и приоритеты расходятся с Matrix.org?
ooprizrakoo
В чем идеологическое и принципиальное технологическое отличие от упомянутого вами XMPP? (я не программист, если можно — объясните как «не-программисту»)
Сейчас у меня ощущение, что вы переизобрели жаббер, а ваша простота API и компактные RFC — вещи, которые со временем превратятся в талмуды к какому-нибудь релизу «v2.0»
aakolov
Поддерживаю вопрос. Почему бы не доработать в нужную сторону любой из зиллиона известных XMPP проектов?
chupanebre Автор
Если доработать XMPP, то он перестанет быть XMPP. Например, WhatsApp использует «доработанный XMPP». Нет ни для кого никой пользы от того, что протокол WhatsApp-а основан на XMPP. А если нет пользы, то в чем смысл? Легче и удобнее начать с чистого листа.
lixmix
Если бы WhatsApp начинал с нуля, тогда бы значительные ресурсы были израсходованы на создание собственного ПО, а это годы и большие деньги. WhatsApp вполне мог обогнать какой нибудь другой мессенджер и никто о нем бы не знал. Что бы создать продукт не достаточно, его написать, но надо еще обеспечить рентабильность и высокую отказоустойчивость.
WhatsApp выбрал eJabberd из-за того что он обладает высокой отказоустойчивостью. 2 000 000 человек на одной ноде, из-за этого и любят XMPP(в особенности разработчики проприетарных мессенджеров). На дешевом VPS с eJabberd-ом можно расположить сервер с тысячами человек в онлайне
Стресс-тест Ejabberd. 2 000 000 в онлайне на одной жаббер-ноде blog.process-one.net/ejabberd-massive-scalability-1node-2-million-concurrent-users
savostin
На счет контактов на сервере не согласен.
Во-первых, для отправки онлайн статуса не вижу в этом необходимости — это может сделать клиент, раз он онлайн. Тот же ping + timeout решит проблему offline.
Во-вторых, может я не хочу иметь все контакты на всех устройствах. Может я хочу завести 2+ аккаунта (рабочий, личный, ...) Да и вообще не хочу делиться контактами хорошего сантехника с сервером. Было бы неплохо (да и оригинальная фича) сделать выборочную синхронизацию контактов. А еще интереснее, сделать разделение контактов на «Саша мобильный», «Саша компьютер», «Саша рабочий» с возможностью отсылать сообщения конкретному субконтакту (и не забыть сделать возможность отсылать себе «на мобильный»!) и контакту в целом (путь принимают все, кто онлайн).
На счет репутации мысль дельная, но, как я понял, это будет только репутация серверов для межсерверного общения? Т.е. единичные клиенты могут слать спам безнаказанно, подключившись к конкретному серверу? Или для них тоже есть репутация? Как она будет тогда вырабатываться? Не ясно.
Ну, и присоединяюсь к вопросу выше — зачем придумывать еще один протокол/стандарт? А не выбрать существующий, благо их тысячи.
chupanebre Автор
Не может. Его Android просто убил т.к. память на телефоне кончилась.
Кто и по каким адресам его будет рассылать, если клиент уже убит операционной системой, а на сервере вы предлагаете контакты не хранить?
А это будет уже проблемой конкретного сервера/узла. Если из узла идет спам, то он потеряет репутацию и от него перестанут принимать сообщения.
savostin
Если его Android убил, то он уже offline. Ping делает клиент к клиенту, в крайнем случае сервер к клиенту. Если ping'а нет — значит offline.
Т.е. в рамках одного узла можно рассылать спам, затем подключаемся к другому узлу и рассылаем там.
Mobile1
если в фоне будет постоянный пинг, то батарейка будет жить недолго.
А в ios вообще невозможно такое сделать.
savostin
Ping нужен только если клиент реально online.
Mobile1
А пинг зачем если клиент онлайн?
Вы же как раз хотите пингом выяснять что он онлайн или я неправильно понял?
Krypt
Понятия «online» и «offline» размазалось когда появились пуш-уведомления. Приложение не запущенно, но операционка может его запустить тем или иным способом при получении уведомления.
Mobile1
Самое интересное в этих пуш уведомлениях — каким образом мессенджеры, которые заявляют о том что у них сквозное end-2-end шифрование, могут шифровать пуш сообщения?
У того же вацапа или вайбера или телеграмма идет открытое сообщение через пуш сервис гугла и Эпла.
Ведь приложение в этот момент не работает, а сообщение можно прочитать.
Следовательно их енд-2-энд не работает.
Т.е. и гугл и эпл в курсе всей переписки всех мессенджеров.
По идее надо делать так чтобы приходило шифрованное пуш сообщение и только в момент запуска пользователем приложения оно бы расшифровывалось (кстати такие мессенджеры есть).
Mobile1
а у некоторых так сделано — появляется просто сообщение что что-то пришло, а забирается оно только тогда когда приложение запустилось и забирается напрямую с сервера мессенджера.
Вот так делать — совсем другое дело.
А так получается что все эти end-2-end на самом деле с гуглом и эплом посередине.
И почему-то никто на этот факт внимания не обращает.
NoRegrets
Я думаю, что не надо хранить ничего на сервере. Сервер должен быть лишь stateless маршрутизатором и не знать ничего о клиенте. Должна быть возможность подключения к любому серверу, с сохранением своего аккаунта. Сервера должны создавать mesh-сеть. Должна быть возможность создания приватного сервера предприятия, который, тем не менее, мог бы посылать и получать сообщения с других серверов.
На сервере можно хранить и ростер и переписку, но только в виде шифрованного блоба.
Одна из проблем джаббера — если у меня есть аккаунт на gmail, я уже не могу переключиться на другого вендора. Если предприятие запускает свой сервер — это еще один бесполезный аккаунт, который я потеряю вместе со списком контактов, как только уйду с этого предприятия.
chupanebre Автор
Не получится. Во-первых, невозможно надежно показывать онлайн статус без контактов на сервере. Во-вторых, web-клиент удобен, а web-client требует контактов на сервере. Не пробовали пользоваться web.wechat.com? Настолько неудобно, несколько вообще можно себе представить. А там просто сообщений старых нет.
То, что вы предлагаете — другой продукт с другими целями. Возможно, кому-то он нужен, и может быть кто-то захочет его создать.
chupanebre Автор
Кстати, Tinode как раз эту проблему и решит.
andreymal
Реквестирую больше конкретики: чем шифровать и кто, как и где расшифровывать будет?
NoRegrets
Это тривиальная схема. Шифруете любым симметричным алгоритмом со случайным, длинным паролем. Пароль тоже шифруется — симметричным или несимметричным алгоритмом и прикладывается к блобу. В качестве мастер пароля, используемого на 2м этапе, можно использовать пароль для входа в систему или закрытую часть своего ключа.
Клиент подключается, аутентифицируется. Ни пароль пользователя, ни закрытая часть ключа при этом на сервер не попадет. Запрашивает блоб принадлежащий аутентифицированному аккаунту, сливает, расшифровывает и работает.
andreymal
Вот на этом «аутентифицируется» поподробнее. Если пароль на сервер не попадает, то как аутентифицируется-то? Сразу предупреждаю, что таскать с собой закрытый ключ вместо пароля ни один обычный пользователь не станет.
NoRegrets
Пара затяжек напечатанной и скрученной в небольшой косячок документации CRAM-MD5 сразу откроет глаза на то, как это можно сделать. Со следующей затяжкой приходит понимание, что это далеко не единственный вариант.
datacompboy
Spf
datacompboy
Автозамена, блин :) и почему нельзя с телефона редактировать комментарий?
SRP, https://m.habr.com/post/121021/
Revertis
А если у вас собственный сервер, всё становится очень удобным. Вы храните у себя свой список контактов, свои сообщения и т.п.
lixmix
Я зарегистрован на двух серверах. jabber.ru и 404.city.
Эти xmpp-сервера имеют разные подходы к доставке сообщений. На jabber.ru хранится история сообщений. На сервере 404.city сообщения не хранится. На 404.city сообщения напрямую передаются на онлайн устройства, как в описанном вами предложения.
Поскольку я на практике знаком с обоими подходами, что лучше хранить историю на сервере или нет, я сказать не могу.
С одной стороны, подход с отсутствием хранения истории на сервере большой плюс к приватности.
С другой стороны, когда два устройства включаются поочередно ( оставил включенным пк, а мобильная сеть пропадает на минут пять), сообщения приходят не туда.
На Jabber.ru, где есть серверное хранение истории, так не происходит. Приходится выбирать между большей приватностью или удобством (ну или просто отключать второе устройство)
К тому же, отсутствие хранения истории сообщений не удобно тем кто любит перечитывать старые сообщения (да, есть такие люди и их много)
Как раз эти проблемы разных вкусов и предпочтений и пытается решить XMPP, со множеством XEP-ов
Проблема переноса аккаунтов в жаббере, частично решена в клиентах.
В декстопном Gajim, есть возможноcть экспорта контактов из одного аккаунта в другой.
В мобильном Conversations, есть возможность хранить жаббер-контакты в адресной книге андроида, как номера телефонов.
Существует так же мобильный жаббер kontalkt, где JabberID это номера телефонов. Он работает по принципу добавления контактов так же как WhatsApp, Telegram и т.д
keydon2
1)Можно позволить клиенту решать где хранить сообщения(причем как глобальным пунктом в меню, так и статусом «полуофлайн, посылать сообщения на другое устройство»)
2)Перечитывать можно и оффлайн. Особенно если предусмотреть удобную синхронизацию состояния(контактов\истории\etc) без участия сервера(по вафли в одной сети\через файл).
geektimess
А можно инструкцию на русском языке? Как запустить-попробовать Ваш мессенджер?
chupanebre Автор
translate.google.com решает проблему процентов на 90.
MisterParser
Я думаю, вам нужно подумать о том, чтобы можно было подключать контакты из скайпа, телеграма, воцапа и вайбера в ваш протокол. Я хочу заходить в ваше приложение, отправлять человеку из контакт-листа сообщение и не думать о том, какой у него мессенджер. Я один раз добавил Васю Пупкина как vasya в телеграме, а дальше пусть ваш мессенджер отправляет сам ему в телеграмм сообщение и принимает от него ответы. Вот это было бы круто и 100% взлетело бы.
mspain
Не настолько это нужно хомячкам. Стоит у них по 4 чатов и не жужат. А вот в реализации неофициальный гейт в 4 разных чата это мегагемор. А если они ещё и сопротивляться начнут…
andreymal
Но хотя бы просто запилить возможность создания гейтов в протоколе вполне можно. В том же XMPP гейты всегда делались независимыми разработчиками
chupanebre Автор
То есть пойти по пути Миранды и друзей? Спасибо, но не надо. Это другой продукт, с другими целями.
andreymal
Почему сразу Миранды, по пути XMPP-транспортов же :)
Ах да, это ещё одна фича, которую я считаю обязательной для кандидата в идеальные/универсальные мессенджеры
lixmix
Тут к сожалению часто бывает проблема, скайпы, телеграмы и воцапы не очень то горят желанием, что бы к ним подключались по-сторонним мессенджерам. Пользователкая база это капитал для них.
Задумка у XMPP была хорошая, как раз создать один такой единый стандарт коммуникаций для всех мессенджеров, а дальше пускай бы писали свои расширения, но она запнулась об это.
Сегодня WhatsApp разрешит писать в него с жаббера, а завтра все кто недоволен WhatsApp, но вынужден его держать удалит его и компания потеряет часть пользователей.
NoRegrets
На шлюзы маленького мессенджера никто внимания и не обратит. А когда обратят возможно это уже станет необязательной фичей мессенджера, он и без них проживет.
Goodkat
Был такой мессенджер, Meebo, ещё до воцапов с телеграмами — он делал именно так, как вы описали, позволял подключить кучу разных мессенджеров и объединял их все в обном удобном веб-приложении и приложении для телефона.
Мои знакомые неудомевали, как это я в аське круглосуточно онлайн, даже когда лечу над Тихим oкеаном.
А потом из купил Гугл и закрыл.
mais
Зачем писать свой месенджер с открытым исходным кодом, если есть signal?
chupanebre Автор
Зачем писать Postgres если есть MySQL? Зачем писать Mongo если есть Postgres и Mysql? Зачем писать Redis, если есть Mondo, Postgres и Mysql? Зачем писать RocksDB если…
У каждого проекта свои цели и приоритеты. Signal про криптографическую безопасность. Tinode про федерацию, удобство пользователя и гибкость настроек.
redmanmale
Который привязан к телефону.
mais
Код открыт, телефон можно заменить на что угодно, немного переписав пару классов. Телефон используется для высылки кода подтверждения и пушей. Если они вам не нужны — можно на никнеймы перейти за пару минут.
Sjam
Еще один вариант matrix?
andreymal
Ээ, федерации нету? Так неинтересно. Без федерации (и без p2p) любой школьник может наклепать мессенджер за неделю, а вот с федерацией сразу вылезает куча проблем (многие из которых не решены ни в XMPP, и в E-mail).
И не забудьте решить проблему смерти серверов в федерации. А то мне уже приходилось разок эвакуироваться с умершего jabbus.org — это весьма неприятно.
trublast
В свете недавних событий с Телеграмом подумывал плотнее переходить на TOX. Да там свои проблемы, но просто еще один велосипед городить смысла тоже не вижу.
esudnik
На мой взглят основная проблема в TOX, это то что сообщение не доходят если получатель офлайн.
QuakeMan
им просто блокчейна не хватает — для хранения ников и сообщений
godlikebasic
Мне кажется суть этого проекта не совсем в этом, но лично мне был бы интересен софт, с помощью которого можно было просто сделать свой чат на своём сервере. А если бы на него уже будет готовый лаунчер для андройда и прочих систем, было бы совсем шикарно.
Скачал в плеймаркете — ввел адрес сервера — авторизовался — и общаешься спокойно, не боясь рос******зора.
chupanebre Автор
Вот прямо сейчас можете сделать свой чат на своем сервере. Скачать в плее пока нельзя, но будет можно. Смысл именно такой — чтобы чат-клиент был как веб браузер, мог работать с любым сервером.
Revertis
Nextcloud Talk. Устанавливаете сервер, скачиваете клиенты из маркета. Федерируетесь с другими серверами.
mistbow
Интересный проект, я бы попробовал… С чего лучше начать?
wlr398
В начале марта на Geektimes были статьи от Mobile1 тоже про новый месенджер. Как было в момент публикации на Google.Play у них 5000+ установок, так и осталось сейчас. Отсутствует киллер фича чтобы даже просто установить попробовать, и тем более кого-то ещё уговаривать.
С 2002 года пользуюсь разными месенджерами. ICQ и клоны получили распространение, так как в те времена просто не было ничего подобного. Skype дал возможность бесплатно общаться голосом по всему миру, при этом требовал минимальных усилий от пользователя, легко пробивал всякие NATы, файрволы.
WhatsApp пришёл как бесплатная замена SMS и при этом тоже требовал минимальных усилий привязываясь к номерам телефонов, установил и всё. Телеграм акцентировался на безопасности и, конечно, личность Дурова играет большую роль.
Киллер фичей была бы возможность обмениваться трафиком между разными сервисами, но это не выглядит реалистичным, абсолютно.
Плюс ещё момент, что на месенджерах до сих пор никто не смог зарабатывать. Заработок происходил только в момент продажи предыдущими владельцами Майкрософт, Фейсбук и т.д.
Mobile1
Спасибо за упоминание нашего проекта.
Кстати, скоро будет 10000, но действительно, сделать массовым мессенджер нелегко.
Чтобы был виральный эффект, нужно набрать критическую массу, может быть 100 тыс, а может и 1 млн.
Т.е. на первом этапе нужно продвигаться в любом случае.
Мы этим пока не занимались, потому что допиливали видеозвонки и Live TV режимы, вот только на днях выложили версии со стабильными и качественными видео и Live.
Еще одна проблема — нужно сделать все теже самые фичи что например в WhatsApp и добавить свое, т.е. по сути в идеале нужно сделать продукт, который умеет все тоже самое и плюс на голову выше их по другому функционалу.
Вдобавок к этому мы попали под раздачу РКН в связи с блокировкой Телеграм, т.к. мы хостимся на Амазоне и возможно в РФ он не работает (по крайней мере несколько раз пользователи жаловались и в тоже время у них же через впн все работало).
ianzag
Что мешает взять в качестве frontend-а телеграм и дорисовать свой backend? Исходники телеги лежат в гитхабе под GPLv3. Бери не хочу.
chupanebre Автор
А если мы хотим сделать что-то, чего в Телеграме нет? А если Телеграм хочет сделать что-то, что мы считаем неправильным? Если если Дуров пришлет нам письмо "Прекратите использовать нашу интеллектуальную собственность"?
mr_tron
1) Ну для начала стоит сделать то что уже есть в телеграме.
2) это проблема — да.
3) ну это. пошлёте ему в ответ фоточку стольмана, поедающего козявку с подошвы ноги. ну или ещё что-нить смешное про gpl
chupanebre Автор
> 3) — клиентское приложение — да, а серверное, даже если там чистый reverse engineering и нет ни строчки телеграмного кода — нет. Если пожелает, то прикроет или, как минимум, создаст большие проблемы.
mr_tron
Ну как минимум часть серверного телеграмного кода выложена под gpl (они так его прихватывали из ВК). Хотя они уже переехали на mtproto 2 и скорее всего ничего не осталось. mtproto защищен лицензией, но оно собственно и не надо. с клиентской стороны достаточно реализовать апи tdlib, а оно имеет открытую лицензию.
ianzag
Форкнитесь и…
> А если мы хотим сделать что-то, чего в Телеграме нет?
… сделайте…
> А если Телеграм хочет сделать что-то, что мы считаем неправильным?
… выкиньте…
> Если если Дуров пришлет нам письмо «Прекратите использовать нашу интеллектуальную собственность»?
… сошлитесь на GPLv3.
Вроде сходится?
Код десктопной телеги — сравнительно простой и достаточно продуманный. Приличный современный C++. Чтобы сделать что-то подобное самим — придется сильно потрудиться. И это только fontend и только десктоп. А есть ещё мобайл во всех его красках без которого современный мессенджер обречен на смерть ещё не родившись.
Даже на приличный современный frontend нужно ресурсов. Потяните с нуля?
chupanebre Автор
Разговор про "дорисовать свой backend". И какой смысл реверс-инженирить сервер, чтобы сделать из него несовместимый продукт? Профит в чем?
Речь не про клиентские приложения, а про гипотетический сервер.
А вот интересно, насколько популярен десктопный клиент? Есть где-нибудь цифры?
С клиентскими приложениями тоже не все отлично, т.к. GPL затрудняет создание независимых коммерческих проектов.
aakolov
Несовместимый с чем? Как раз наоборот, совместимый.
Это если брать код и делать свою коммерческую версию на его основе, если же пользовать ПО, то никаких трудностей нет. Насколько я понимаю, в этом проекте коммерции (на коде) не предполагается. Ну и к слову, Red Hat c Oracle что-то не жалуются на GPL.
ianzag
> А вот интересно, насколько популярен десктопный клиент? Есть где-нибудь цифры?
Если мы говорим за messender широкого плана, то наличие и десктопной и мобильной версий — это IMHO must have. В противном случае mobile only версия конечно наберет свою пользовательскую базу, но скажем для рабочих процессов это использовать уже не получится.
Ну и голосовые конференции конечно же. Без возможности пообщаться голосом причем нескольким участникам — это ни о чем. Видео не так важно.
robux
.
Блокчейн — не поможет, это централизованная и уязвимая структура.
Вам следует использовать распределённую сеть доверия.
chupanebre Автор
В статье критикуется не блокчейн вообще, а блокчейн в той форме, в которой он используется в криптовалютах. Критика разумна, но не по адресу.
Скорее всего будет какая-то производная от https://en.wikipedia.org/wiki/EigenTrust
Возможно, стоит написать отдельную статью про распределенную систему учета репутации.
linuxover
было бы интересно обсудить такой вопрос:
Задача: сделать IM уровня Телеграм, но с полной децентрализацией и включенным навсегда шифрованием.
то есть важно:
очевидно что решение подобной задачи (особенно в области пункта 2 и 8) требует очень тщательной разработки базовой архитектуры и эволюционно до этого уровня вырасти сможет далеко не всякий проект.
linuxover
то есть если задачу решать то видится некий распределенный DHT на базе которого распределенная FS.
при этом ноды этой FS должны опираться на рейтинг нод, который ведется как-то независимо от ноды. чтобы избежать атак зафлуживания FS мусором.
ну и соответственно каждая нода будет еще и нодой-хранилищем FS. Типа хочешь хистори хранить по своим чатам на 10 мегабайт, предоставь 50 мегабайт для всех прочих нод.
распределенная FS даст оффлайн отправку
Massacre
Это уже есть и называется Perfect Dark. Используется для анонимного файлшаринга. Узкое место — скорость, и в случае p2p обмена с распределённым хранилищем это будет всегда так. Ну и несколько десятков гигов надо выделить под общее хранилище, да. Зато и сервера не нужны
x2bool
Вот что-то не получается ни у кого сделать такое. Обычно, либо оно централизованное, либо очень неудобное и убогое. На Tox можно для примера посмотреть.
wlr398
Не получится в эпоху мобильников сделать децентрализованное. Потому что мобильники сидят за NAT, имеют ограниченные ресурсы — аккумулятор, платный трафик, вычислительные.
Каким образом предлагается обслуживать полтора миллиарда мобильных клиентов как, к примеру, у WhatsApp?
Если не считать торренты, то децентрализация получилась только у раннего Скайпа. И то, в эпоху десктопов было немало жалоб на прокачку чужого трафика на клиентах выбранных супернодами.
Плюс были проблемы массовых сбоев когда оказывалось, что суперноды не спешили обновлять клиента.
Так же есть риски визита спецслужб, если вдруг окажется, что через ваш компьютер прокачивался какой-то не очень хороший трафик. А эти риски сейчас совсем не нулевой вероятности.
linuxover
здесь основная проблема — ограниченность аккумулятора. по идее если DHT расчитывать на то что многие сегменты не могут друг с другом сконнектиться, то все норм будет.
я например на мобильной сети качая торренты вижу пиры в той же мобильной сети. т.е. даже у торрентов получается работать в мобильных сетях-то.
linuxover
тут ведь можно сочетать.
типа если любой волонтёр поставит стационарную ноду, то она будет помогать в скорости, но при этом уязвима к людям в погонах.
Важно чтобы когда ноду уберут, система сохраняла работоспособность..
Cryvage
Сделать что-то централизованное, неудобное и убогое?
А если серьёзно, прежде чем пытаться сочетать, надо тщательно проанализировать почему раньше ни у кого не получалось. Интуиция подсказывает, что тут мешает что-то фундаментальное. Совместить распределённость, синхронизацию, и эффективность кажется, если не невозможной, то очень сложной задачей. А каким должен быть оптимальный компромисс — не совсем понятно.
linuxover
нет, децентрализованное.
так я об этом же и пишу.
что прежде чем начинать делать подобную систему нужно на начальном этапе спроектировать архитектуру.
а проекты (матрикс, токс, итп) начинают с того что начинают писать сразу клиентов. Увы.
а теоретически надо планировать сперва сеть. Причем сразу закладывая в нее
ну и заодно устойчивость к атакам.
а то один проект предусматривает скажем шифрование, но не предусматривает оффлайновость общения. Другой наоборот. итп.
вот тот же блокчейн примерно так же продумывали сперва, потом реализовывали.
vmchaz
Эти проблемы можно решить все вместе только тогда, когда каждый пользователь обзаведётся своим промежуточным сервером, который будет постоянно онлайн, и все подключения будут происходить через него.
Эта стратегия, кстати, позволит решить множество других проблем, связанных с приватностью и анонимностью.
linuxover
нет, почему?
эти проблемы можно решить сделав распределенное файловое хранилище с избыточностью на всех нодах-участниках.
просто получается пользователь будет знать что ему чтобы пользоваться сетью, обязательно и вкладываться в нее ресурсами (диск, CPU)
Murz
Опишите пожалуйста поподробнее — чем не устроил уже существующий открытый и активно развивающийся протокол Matrix?
Практически всё, что вы описываете и планируете сделать, там уже реализовано на вполне юзабельном уровне. Есть даже уже несколько разных имплементаций клиентов на разных языках программирования matrix.org/docs/projects/try-matrix-now.html#clients и серверной части matrix.org/docs/projects/try-matrix-now.html#servers
И даже есть рабочие шлюзы в Телеграм, Гиттер, IRC, Skype и другие мессенджеры.
Мне кажется будет логичней и эффективней присоединиться к команде Matrix, чем изобретать свой велосипед.
andreymal
Фиг с ним, с убогим REST, но — чё там с вебсокетами?)
Murz
Ну REST уж всяко получше будет чем огромные XML гонять как в XMPP. По поводу вёбсокетов — это конечно стильно-модно-молодёжно, но разработчики пока не увидели особых преимуществ в срочном переходе на них по сравнению с HTTP Long Polling, поэтому добавление вёбсокетов — у них в планах есть, но пока в низком приоритете. Пока что и без вёбсокетов всё работает неплохо.
Как раз можно заняться допиливанием этого PR, чтобы всем прибыло вёбсокетового счастья :)
andreymal
И тут вся моя остававшаяся вера в Matrix развалилась окончательно. Если в сабже будет нормальная федерация, возможно поддержу его
Murz
А что с верой-то сразу так всё погрустнело? Они же не отказываются прикручивать вёбсокеты, просто пока есть более приоритетные задачи по развитию, всё сразу сделать — никаких рук не хватит. Если бы переход на вёбсокеты сразу дал бы кучу заметных преимуществ — то возможно да, стоило бы всё бросить и их прикрутить.
А если текущий HTTP Long Polling «просто работает» и всех устраивает, зачем ломать и переделывать в срочном порядке? Кому надо побыстрее — пусть присоединяются к PR и дорабатывают.
andreymal
Ага, а потом половина серверов будет с вебсокетами, а другая половина останется с лонг-поллингом? И в клиентах тоже наступит бардак? Не нужно плодить легаси с самого начала, нужно было изначально сделать нормально. А теперь, скорее всего, Matrix скатится в те же проблемы совместимости, которые сейчас имеет XMPP. (Это я ещё протокол в подробностях не читал, там наверняка тоже найдётся к чему прикопаться)
Murz
Они как раз не хотят идти по пути XMPP а сделать всё по-нормальному — единые спеки вместо кучи независимых XEP-ов.
И они уже огромный объём работы проделали, особенно по реализации федерации. А вам с новым мессенджером ведь придётся всё это заново писать, это огромный объём работы.
andreymal
И в итоге нужно будет официально поддерживать целых два способа подключения и в клиентах, и в серверах, при том что один из них просто лишний (лонг-поллинг, ага). Говорю же, устраивают легаси с самого начала. Не надо так.
Теперь лучше уж сделать новый нормальный протокол, своровав хорошие идеи из XMPP и Matrix (чтобы объём работы уменьшить) и не накосячив с лонг-поллингом :D
И ещё использовать CBOR вместо XML/JSON будет нелишним. Сабжа тоже касается.
Murz
Ага, а завтра появится что-то более модное чем вёбсокеты и все побежим снова писать новый протокол? ;)
Кстати, никто не мешает написать свой вариант сервера Matrix с блекджеком и вёбсокетами, но совместимого с Federation API — вот примеры такой реализации: mxhsd и Ruma
andreymal
Ну зачем, протокол должен быть независим от способа передачи данных (и от формата, кстати). Только вот лонг-поллинг — по определению костылизм и лютая стыдоба. Использовать лонг-поллинг, когда уже давно существуют вебсокеты — двойная стыдоба. Продолжать поддерживать лонг-поллинг ради обратной совместимости (а это Matrix теперь будет вынужден делать) — тройная стыдоба. Усугублять легаси слоупочностью с добавлением вебсокетов — стыдоба ? 4. Про нормальные TCP/SCTP-сокеты даже вспоминать не буду, а то меня хипстота съест.
В общем, Matrix окончательно умер в моих глазах.
Murz
Кстати, Matrix сейчас пишет новую версию сервера как раз на Go: github.com/matrix-org/dendrite и этим летом даже в Google Summer Of Code попали.
Murz
Если уж всё-равно хочется что-то своё написать, то было бы здорово сделать федерацию совместимой с протоколом Matrix, например Rocket.Chat такую пилит: github.com/RocketChat/Rocket.Chat.Federation
chupanebre Автор
Я мог бы написать, что messaging — потоковая архитектура, и реализовывать ее на транзакционном REST-API немного нелогично, но не буду.
Мог бы сказать, что причина в том, что Matrix в первую очередь API, а потом уже приложение, построенное на нем, и, как результат, API слишком широкий, но это было бы неправдой.
Сказал бы, что Go для написания потоковых приложений подходит лучше, чем Python, но тоже не буду. Кто что умеет, тот то и отстаивает.
Сказал бы, что хочу разрабатывать систему с единомышленниками, которые не пишут "добавление вёбсокетов — у них в планах есть, но пока в низком приоритете". Но это тоже не было причиной.
А реально причина "чем не устроил уже существующий открытый и активно развивающийся протокол Matrix" очень проста — его не было в 2014 году.
chupanebre Автор
Почитал спецификацию как в matrix устроено присутствие:
https://matrix.org/docs/spec/client_server/r0.3.0.html#id62
И, мягко говоря, был удивлен. Они реально предлагают использовать pull, т.е. периодически спрашивать сервер об онлайн статусе контактов? Без шуток, в 2018 году спрашивать сервер раз в 10 или 20 секунд? Вот прямо так, с мобильного телефона и спрашивать? Или я все-таки что-то недопонимаю в их спецификации?
Вообще в мессенджерах присутствие — это процентов 50 сложности. Если кто-то делает присутствие как pull, то, скажем так, он неправ.
linuxover
> Если кто-то делает присутствие как pull, то, скажем так, он неправ.
я в целом с Вами согласен, но в распределенной сети, при отсутствии центрального сервера (не знаю как у матрикс) pull — возможно единственный способ доставки евента?
chupanebre Автор
Нет, конечно. Например, емейл настолько распределенная система, насколько это бывает, и сообщения там ходят от сервера к серверу как push. Даже в XMPP, несмотря на то, что я его не люблю, надо отдать должное, присутствие сделано как push. У меня прямо-таки взрыв мозга, что кто-то может всерьез в 2018 году предлагать pull как механизм обновления присутствия.
lixmix
У матрицы сервера подают часто. Плохая отказоустойчивость на серверах, за исключением matrix.org. Существует мнение, что плохая оптимизация специально сделана
lixmix
Очень жаль. Из вашего приложения, мог бы получится неплохой веб-клиент для декстопа
chupanebre Автор
Рад, что вам понравилось. Если хотите адаптировать его под XMPP, то можете, лицензия Apache 2.0 позволяет.
linuxover
емейл — распределенная система, но не совсем. там один сервер как правило отвечает за множество адресов на нём.
соответственно сеть емейл уязвима к тому что один из узлов будет выведен из строя. Выводим из строя ноду "@mail.ru" — страдает несколько десятков миллионов пользователей. Выводим из строя "@gmail.com" — еще минимум столько же.
а мы же обсуждаем некую систему доставки сообщения, которая не подвержена подобным «атакам» или проблеме?
chupanebre Автор
Ну вы, наверно, скажете, что только mesh network является вполне распределенной системой )
На мой взгляд задача вполне может решаться пошагово, а не «все или ничего». Начать достаточно с устойчивости системы, сравнимой с емейлом. И дальше по мере необходимости добавлять фичи типа DHT для нахождения пиров.
Murz
Да и вообще — если у меня 1000 контактов, и изменение статуса каждого контакта мне PUSH-ем будет прилетать на мобилу — с таким подходом батарею от Камаза надо будет ставить на мобилу ;)
andreymal
Ээ, серьёзно? Тогда не удивительно, чего презенсы на matrix.org вообще отрубали нафиг. Ещё один гвоздь в крышку гроба мертворожденного Matrix
Murz
А у других мессенджеров это как-то лучше реализовано? У того же воцапа с его xmpp+костыли, или у вайвайбера который на базе SIP протокола разрабатывался?
Для мобил — в Matrix уведомления о новых сообщения через PUSH прилетают, а изменение статуса контактов через PUSH гонять — это уже совсем бред.
Поэтому активного соединения не поддерживается и батарея не жрётся в фоне. А для активного приложения — варианта два: либо вёбсокеты (которые matrix скоро всё же прикрутит) либо long polling, или ещё что-то есть интересного?
Поддерживать постоянное активное вёбсокет-соединение в фоне на мобильном девайсе с динамическим ип и нестабильным интернетом — это практически то же самое для батареи и трафика.
andreymal
Немного мелочей по сабжу: не обнаружил в протоколе использования SASL, это не очень хорошо. CRAM-MD5, в который меня тыкали носом выше в комментах, есть в SASL, и поддержать всё это дело будет правильно.
Немного странно изобретать «random 64-bit number» вместо стандартного UUID.
Тырить юзер-агент из HTTP — плохая идея, это довольно убогая штука. Получение информации в том же XMPP сделана очень хорошо, например.
Лонг-поллинг не нужен. Вебсокет тоже избыточен, но фиг с ним, для веб-клиентов пригодится.
chupanebre Автор
Зачем? Не троллю, на самом деле спрашиваю. Если добавить SASL, то что это даст пользователю, разработчику или администратору системы?
Рассматривали, долго дебатировали. int64 лучше поддерживаются в базах данных и короче. Наличие стандарта, описывающего конструкции разных UUID не является какой-то полезной фичей само по себе.
Поменять несложно. Можно поподробнее?
Да, думаю, что в 2018 году больше не нужен. Когда начинали был нужен.
andreymal
Стандарт же. SASL используется много где (хоть те же джаббер и почта), уже есть куча готовых реализаций и куча алгоритмов аутентификации на любой вкус (тот же CRAM-MD5). SASL абстрагирует механизм аутентификации от остального протокола (Tinode) и позволяет творить с аутентификацией что угодно, в том числе переиспользовать готовые реализации — а это уже должно быть полезно для разработчиков, которым не придётся городить велосипеды (ну или будет проще адаптировать и переиспользовать существующие велосипеды) (при нормальной архитектуре реализаций, конечно же, хех).
Сильно не вчитывался и могу ошибаться, но, как я понял, сейчас используется обычная PLAIN аутентификация, которая не очень хороша, потому что пароль попадает на сервер в открытом виде. Если очень хочется продолжить использовать PLAIN, то в SASL аналогичный алгоритм тоже есть.
В юзер-агентах всё свалено в одну кучу и каждый пишет что попало, а в jabber:iq:version по-нормальному разделены имя, клиент, версия и ОС — намного удобнее обрабатывать программно.
chupanebre Автор
Так оно сейчас и работает. Поддерживаются три разных механизма аутентификации и нет никаких проблем добавить еще 30. Механизм авторизации абстрагирован от остальной логики. Может быть то, как сейчас работает, и не называется SASL, но концептуально очень-очень похоже.
OK, спасибо.
andreymal
Вот поэтому и нужно как можно скорее брать стандартный SASL, а не клепать ни с чем не совместимый велосипед без причины ;)
И в SASL это уже сделано до вас.
chupanebre Автор
А что значит "стандартный SALS"? Это ведь не библиотека, не API, а протокол, который определяет обмен сообщениями между клиентом и сервером. Давайте я скажу тогда, что у нас реализовано подмножество SASL?
Мы говорим о разных вещах.
andreymal
RFC 4422 предъявляет вполне конкретные (и довольно простые, несмотря на длину RFC) требования без всяких там подмножеств. Давайте вы не будете выпендриваться велосипедами и вносить дополнительную неразбериху в и без вас творящийся хаос в мессенджерах?
chupanebre Автор
Да, вы совершенно правы. Пойду удалю проект с Гитхаба, чтобы не вносить неразбериху.
А если серьезно, то так, как вы пишете: "мне нравится RFC 000, давайте вы разберетесь зачем он нужен и его реализуете" — не очень полезно. Полезно бы было "я внимательно посмотрел на ваш код/документацию, у вас так-то, а если было бы так-то, то это позволило бы то-то и то-то". А еще лучше "вот вам pull request, он добавляет поддержку того-то что полезно потому-то".
andreymal
У вас там SASL-подобный велосипед, а если бы вместо SASL-подобного был бы сам SASL, то было бы меньше хаоса, больше совместимости с существующими реализациями SASL и меньше проблем с расширяемостью и безопасностью, потому что разработчики SASL уже продумали всё до вас и десятки страниц RFC посвящены не столько тому, что это такое, сколько тому, почему оно такое. Не ленитесь его почитать, тем более есть перевод на русский.
А Go слишком ересь, чтоб я на нём пулл-реквесты писал. Будущее за Rust!chupanebre Автор
Я вот все равно не понимаю в чем ценность «больше совместимости с существующими реализациями SASL». Как это улучшит проект? Ну переименую я аутентификацию по логину-паролю из basic в plain. Что это изменит? Только конкретно, пожалуйста.
Был такой формат картинок — TIFF. Я когда-то в стародавние времена писал для него писалку-читалку. Писалку для него делать — одно удовольствие. Пиши как хочешь и все получается по стандарту. А вот читать — убийство. По сути TIFF только назывался стандартом, а реально являлся десятком разных форматов под одним зонтиком. SASL, похоже, что-то аналогичное.
Можно примеры каких-нибудь B2С приложений, использующих SASL?
andreymal
Не знаю, о каких B2C речь, мне достаточно того, что SASL работает в джаббере и почте, и работает хорошо. Другие примеры использования вы вполне можете найти самостоятельно, вас же в гугле не заба… а, ну да :(
Сравнивать с TIFF некорректно. Вас никто не заставляет реализовывать и читать абсолютно все алгоритмы — никто не запрещает вам оставить один-единственный PLAIN. Но если вы задумаетесь над комментами других хабраюзеров и захотите прекратить передавать пароль открытым текстом, то с SASL можно было бы просто взять готовый CRAM-MD5, а у вас сейчас, похоже, ничего подобного в протоколе ещё нет. (Здесь ещё можно было бы припомнить совместимость с другими существующими базами данных, но я сам не в теме)
Раз вы не хотите SASL, давайте проверим одну простую вещь — что нужно сделать, чтобы запилить в Tinode аутентификацию с помощью OAuth?
chupanebre Автор
Ну ок, будем считать, что поговорили
Написать соответствующего провайдера с таким интерфейсом:
https://github.com/tinode/chat/blob/master/server/auth/auth.go
andreymal
А чуть подробнее? Для OAuth нужны следующие шаги (примерно):
Как это запхнуть в интерфейс по вашей ссылке, я как-то не понял. Не исключаю, что я тупой и/или не выспался, расскажите как, а?
chupanebre Автор
Ну вот так и сделать, как вы написали. Покажите, что вам на самом деле интересно, а не просто поспорить хочется.
andreymal
Я знаю, что можно сделать так, как я написал. Я не знаю, как это сделать в показанном вами интерфейсе. Как сервер должен скормить в него ссылку? Как в нём открыть браузер? Не увиливайте от ответа, пожалуйста — мы тут обсуждаем фундаментальные проблемы протокола вообще-то.
chupanebre Автор
Ну вот не хочу я «вы мне расскажите, чтобы я еще с вами поспорил». Если вы реально будете делать авторизатор, то буду объяснять. А если просто для продолжения спора — не хочу. Интересно — потратьте свое время и разберитесь.
andreymal
Я потратил своё время и не разобрался. Довольны?
chupanebre Автор
Вы будете писать авторизатор? Да? Нет?
andreymal
Вы будете рассказывать хотя бы примерно, как мне его написать? Или сойдёмся на том, что добавить поддержку OAuth в Tinode невозможно?
chupanebre Автор
Мы сойдемся на том, что вы не хотите тратить свое время, чтобы разобраться, а я не хочу тратить свое время, чтобы вам объяснять.
vmchaz
Защищённые груп-чаты могут выглядеть таким образом:
1. Каждое сообщение симметрично шифруется случайным ключом. Случайный ключ шифруется публичными ключами каждого из участников. Для очень больших чатов возможен такой вариант: каждый участник публикует свой случайный ключ, который будет действовать следующие n часов, зашифрованный открытым ключом каждого из участников чата, после чего постит только сами зашифрованные сообщения, без ключа.
2. Каждый клиент сам выбирает, какую информацию он предоставляет другим участникам чата. По умолчанию, другие участники не могут видеть даже его глобальный ID. Вместо этого они видят его локальный ID, уникальный для каждого чата, который является функцией от ID группы и глобального ID клиента. Таким образом, у наблюдателя, который в чате #mylittlepony видит участника $7fdc8a00, а в чате #kde2 — участника $1120fc07, нет возможности узнать, каков глобальный идентификатор каждого из них, и являются #mylittlepony$7fdc8a00 и #kde2$1120fc07 одним и тем же клиентом или нет.
Некоторые другие соображения:
Не вижу причин, почему некоторые противопоставляют синхронизацию истории и приватные чаты. Можно сделать хранение и подгрузку защищённой отдельной парой ключей, не связанной с основной перепиской.
eirnym
"пишем…" на хабре раньше под таким заголовком допускались только статьи либо с простыми решениями, либо с детальным анализом существующего. В любом случае был подробный рассказ про архитектуру с небольшими кусками кода
У Вас же получилось что-то в духе "Tinode еще один open source чат".
xRay
А свои сообщения можно редактировать после отправки?
chupanebre Автор
Нет. Сделано сознательно.
andreymal
И почему же?
chupanebre Автор
Потому что чтобы сделать хорошо, надо поддерживать версионирование сообщений, а это много работы для редко используемой фичи.
andreymal
Тупо добавить поле вроде replace к самому обычному сообщению, чтобы сделать его сообщением-редактированием. Так сделано в XMPP и (предположительно) Telegram. Ну и просмотр истории сообщений немного пропатчить, чтобы эти replace учитывать, и пару дополнительных индексов в базе прокинуть — версионирование получится само по себе
chupanebre Автор
И replace, и хранение истории изменений, и механизм получения истории изменений клиентом. Слишком много работы для редко используемой фичи.
eirnym
Откуда у Вас такая статистика? Можно в цифрах?
chupanebre Автор
Давайте наоборот. Давайте вы покажете цифры.
lixmix
?
Интересное совпадение. На XMPP, для Линукс недавно появился мессенджер Dino dino.im, это немного созвучно с Tino. Дизайн и внешний вид похожи. Это совпадение?
Кому интересно, можете установить и посмотреть сами:
andreymal
Тоже не поддерживает vCard… Что за ненависть к ним у современных клиентов?
lixmix
Это бета версия
andreymal
И группы в ростере не показывает. И OMEMO-сообщение от Conversations расшировать не смог. Отправить зашифрованное сообщение тоже не позволяет, в замочке пункты не выбираются, хотя и OMEMO и PGP ключи есть. Не, на бету не тянет, максимум альфа
andreymal
Что ж, поджытожим.
Проекту скоро три года, а федерации до сих пор нет. А с этого вообще-то нужно было начинать.
Шифрования тоже нет. А то, которое будет — не OMEMO. И шифрования групповых чатов, похоже, не будет — в общем, без киллер-фич, всё это уже есть в других мессенджерах — да в том же XMPP.
Нет SASL. А велосипедная аутентификация состоит ровно из одного round trip'а: {login} от клиента и {ctrl} от сервера. Впихнуть сюда многоступенчатую аутентификацию вроде OAuth невозможно в принципе.
Описание протокола невнятное. Я так и не понял, каким именно {ctrl} должен ответить сервер на успешную аутентификацию. Лучше уж длинный XMPP Core, но зато чёткий, понятный и с наглядыми пошаговыми примерами. Кр. — с. т. здесь не работает.
Нет редактирования сообщений — базовая фишка всех современных мессенджеров.
Вердикт: в текущем виде не взлетит.
SchmeL
Есть ли в нем сейчас поддержка авторизации по ntlm в LDAP или Active Directory?
chupanebre Автор
Нет, но вы можете ее добавить: github.com/tinode/chat/blob/devel/server/auth/auth.go