Комментарии 208
Во-первых, тут не только API, но и продукт, который становится полезнее с ростом количества пользователей. Как vk или вообще WeChat — нет смысла пользоваться еще чем-то, если все друзья тут, а не там.
Во-вторых, даже для API XKCD не совсем прав. Если есть экосистема, то она сама себя поддерживает и усиливает: статьи, курсы, люди знающие платформу ее популяризируют.
Может быть и 14 конкурирующих стандартов по XKCD, но доли рынка у них разные.
Собственно, с такой подачей это именно просто 15-й стандарт. Непонятно, что его от остальных отличает… Их и «открытых» уже вагон и маленькая тележка.
Просто в статье вы пишете, что «xmpp пробовал, не получилось. Может быть, у нас получится...» А на выходе получается, что даже и не пытаетесь. У xmpp, хотя бы, транспорты были…
История имеет свойство повторяться. Сейчас роль Америки Онлайн играют основные мессенджеры: все они за заборчиками, несовместимы друг с другом, все изобретают свои keywords, желают схватить пользователя и уже никогда не отпускать.
Самое время создать еще один, не совместимый с существующими решениями? Все описанное на этой странице можно сделать на основе XMPP, затратив намного меньше усилий в серверной части.
Протокол хотелось сделать таким, чтобы кривая обучаемости была пологой – не нужно знать всего, чтобы начать. Спецификация получилась очень компактной: 10 запросов клиента, 5 ответов сервера. Например, по сравнению с 200+ страницами только core XMPP, не считая extensions, это почти записка на салфетке..
Представление данных отделено от сетевого протокола. Протокол лишь требует определенную структуру данных, но не требует, чтобы они передавались по сети каким-то определенным образом. Сейчас сервер поддерживает JSON по websocket и long polling, c TLS и без, плюс gRPC по TCP
Если бы Вы почитали более подробно о ХМПП то Вы бы знали, что для доставки сообщений в XMPP вполне можно использовать Websoket, http запросы. В вашем примере Вы дублируюте Ejabberd http api docs.ejabberd.im/developer/ejabberd-api/admin-api Это работает через JSON запросы.
Push уведомлений нет в стандарте XMPP и поэтому он не нужен
Это очередное заблуждение. Протокол XMPP активно развивается. Чего не было лет 5 назад, теперь есть.
xmpp.org/extensions/xep-0357.html
Конкретно по серверам:
mod_push — в ejabberd.
mod_cloud_notify — Prosody.
В других серверах возможно тоже есть, не курсе
Основная проблема в том, что этого всего нет и никогда не будет в качестве обязательной части XMPP
Вы немножко неправильно понимаете смысл создания XMPP.
XMPP это не мессенджер. Это протокол. Его цель было объединить множество разных несовместимых друг с другом мессенджеров в одну сеть коммуникации.
Никто не обязан поддерживать тысячи расширений или навязанную технологию.
XMPP это как линукс. XMPP — это как конструктор, где каждый берет свое.
Как есть WhatsApp, Telegram, Yadex, Google, внутри XMPP своя вселенная из мессенджеров и серверов/ Gajim, Conversations, Dino im., 404, жаббер.ру, жаббер.ат, национальные сервера и т.д.
В ХМПП любой может написать свой XEP или даже не писать, а прикрутить молча прикрутить свое ( социальные сеть и веб-клиент Movim.eu, блоги juick.com )
XMPP это концепция расширяемого протокола для связи между разными, не полностью несовместимыми мессенджерами. Цель ХМПП создать универсальный канал общения. XMPP это не мессенджер, а над месседжерная структура.
Никто не обязан поддерживать тысячи расширений или навязанную технологию.
Именно поэтому разные реализации XMPP очень плохо совместимы друг с другом, и упомянутой вами цели — объединения — XMPP так и не достиг.
У линукса та же самая проблема, да.
упомянутой вами цели — объединения — XMPP так и не достиг.
Условно достигнута. Все мессенджеры поддерживающию XMPP, поддерживают общения между собой. В настоящее время решена, так же передача файлов между разными клиентами. Из жаббера сейчас даже можно отправить файл ссылкой, тому кто не жаббере.
Есть конечно устаревшие клиенты в которых нет новых функции, но с устареванием сталкиваются любые программы.
Большинство пользователей жаббера на мобильных используют conversations, который крайне неплох и вполне современный мессенджер.
Самая большая проблема хмпп это плохая информированность о нем. У большинства людей представление о жаббере из 2000 годов. С этих пор многое в ХМПП изменилось.
Картинки здесь не в почете, поэтому отправлю вам ссылку, как выглядит современный жаббер play.google.com/store/apps/details?id=eu.siacs.conversations.legacy
Ну давайте начнём по порядку с вашей же ссылки.
XHTML-IM не поддерживает — половину сообщений невозможно прочитать так, как задумал автор.
Ресурсы и приоритеты не показывает — кому куда откуда как идут сообщения, непонятно.
Не-legacy версия по умолчанию включает OMEMO (мне рассказывали) — сразу же отваливается совместимость с Psi+ и остальными, кто не поддерживает.
Подключаться по 3G может полминуты. Телеграм подключается за полсекунды.
Без поддержки MAM сервером регулярно теряет сообщения — неоднократно проверено лично мной, Conversations для меня основной джаббер-клиент. Для надёжности Carbons и SM недостаточно.
Звонков нет. А между теми клиентами, где есть, созвониться — целое достижение.
MUC — срисованное с IRC убожество, что вроде как признают даже сами авторы (где-то был XEP об этом). В конференциях файлы кроме как ссылками передавать невозможно. О звонках даже не мечтаем (привет от Skype, Discord и Mumble).
Это только из того, что сходу вспомнил. Если глубже копнуть, можно ещё десятки несовместимостей и проблем упомнить.
А простая передача plain текста без гарантий надёжности — единственная задача, с которой в XMPP справляются действительно все — никому нахрен не нужна в 2018-м. Такой XMPP нам не нужен.
XHTML-IM не поддерживает — половину сообщений невозможно прочитать так, как задумал автор.
Форматирование текста, есть в умеренном количестве. Можно сделать текст жирным, курсивом, исправить ошибку в уже отправленом сообщении.
Ресурсы и приоритеты не показывает — кому куда откуда как идут сообщения, непонятно.
В современном жаббере сообщения идут на все подключенные устройства и зашифрованные сообщения тоже. Ваш сервер действительно поддерживает
Не-legacy версия по умолчанию включает OMEMO (мне рассказывали) — сразу же отваливается совместимость с Psi+ и остальными, кто не поддерживает
Psi+ поддерживают уже омемо через плагин. Недавно добавили. Потом, омемо можно отключить или выставить по умолчанию в настройках другое значение. Кто ставит не легаси версию знает что он делает и ему это нравится. Зачем ограничивать людей в их пожеланиях?..
Подключаться по 3G может полминуты. Телеграм подключается за полсекунды.
Может быть телеграм он и не отключается? Скорость подключения зависит от географического расположения сервера.
Без поддержки MAM сервером регулярно теряет сообщения — неоднократно проверено лично мной, Conversations для меня основной джаббер-клиент. Для надёжности Carbons и SM недостаточно.
Если включенны 2 устройства, если одно то всегда почти доходит (В частности на сервере 404) В настройках можно поставить посмотреть статус доставки. Использовать сервер с хранением сообщений или нет, выбор конкретно каждого пользователя.
> Для надёжности Carbons и SM недостаточно
Если Ваш сервер действительно поддерживает Carbons, вопроса ниже не должно было быть.
>Ресурсы и приоритеты не показывает — кому куда откуда как идут сообщения, непонятно
Зайдите в настройках в информацию в о сервере и посмотрите поддержку хепов. Возможно вам необходимо сменить сервер. В жаббере важно выбрать хороший сервер и клиент, если это сделано, дальше все как по маслу. Многие по незнанию выбирают не обслуживаемые серверы и клиенты, что портит впечатление о ХМПП
Звонков нет. А между теми клиентами, где есть, созвониться — целое достижение
Можно отправить аудиосообщение
MUC — срисованное с IRC убожество, что вроде как признают даже сами авторы (где-то был XEP об этом). В конференциях файлы кроме как ссылками передавать невозможно.
Посмотри свои настройки. У меня показываются фотографии как фотографии. В настройках может быть лимит на размер загружаемой картинки
Ваша наивность зашкаливает.
Можно сделать текст жирным, курсивом
В современном жаббере
У моего собеседника может оказаться устаревший джаббер.
Кто ставит не легаси версию знает что он делает и ему это нравится.
Ничего подобного, не-легаси версия прилетела в обновлениях автоматически (мне тоже прилетала, но я заблаговременно отключил обновления). И простой пользователь не станет менять настройки по умолчанию.
Даже так: обычный пользователь слышал про шифрование максимум в новостях про телеграм, а OMEMO для него — какое-то незнакомое ругательство.
Может быть телеграм он и не отключается?
Отключается, подключение занимает максимум секунду-две даже после переподключения интернета, тыкания режима «В самолёте» или перезагрузки телефона.
если одно то всегда почти доходит
Опять неправда ваша: достаточно отрубить в Conversations интернет на 15 минут или более и попробовать отправить сообщение в течение этих 15 минут. На сервере без MAM сообщение безвозвратно потеряется, иногда отправителю даже не приходит сообщение об ошибке — я неоднократно это проверял и продолжаю иногда проверять до сих пор.
Использовать сервер с хранением сообщений или нет, выбор конкретно каждого пользователя.
Обычный пользователь не разбирается в подобных выборах. Клиент показывает историю — и нормально, а на сервере она или в клиенте — он даже не задумается.
Если Ваш сервер действительно поддерживает Carbons
А сервер собеседника не поддерживает. Как мне понять, поучил/получит ли собеседник сообщение, если у него ни Carbons, ни MAM, ни уведомлений о доставке?
Зайдите в настройках в информацию в о сервере и посмотрите поддержку хепов.
Обычный пользователь в ответ на это предложение выматерится и уйдёт в WhatsApp.
Многие по незнанию...
Сама необходимость какого-то там знания портит впечатление об ХМПП обычным пользователям. Я знаю всё то, о чём мы с вами беседуем, а мои родители — не знают и знать не хотят. Поэтому они сидят и будут сидеть в WhatsApp, Telegram и Skype, как бы мной внутренний швабодкофил ни возмущался.
Можно отправить аудиосообщение
Но не нужно, пользователь хочет звонок. Я лично знаю одного человека, который ничего кроме звонков вообще толком не признаёт и регулярно звонит мне по телеграму.
Посмотри свои настройки.
Так-так, давайте не спешить. Начнём сначала: где в Conversations кнопка отправки файла в конференцию? В личке есть, в конференции не вижу.
Итого: пусть у меня даже будет правильно настроенный сервер и идеальный клиент с поддержкой всех XEP'ов — какой толк от всего этого, если мой собеседник будет использовать условный QIP и всё равно потеряет мои сообщения от банального случайного отключения роутера?
Именно из-за всего этого XMPP (кроме несовместимого WhatsApp) остаётся и всегда будет оставаться уделом небольшой кучки гиков вроде нас с вами. А наши родители будут сидеть в проприетарных мессенджерах.
Как вы не понимаете. Жабберу уже почти 20 лет. За это время изменилось множество технологий и появилось множество жаббер клиентов. Часть из них писали любители.
У моего собеседника может оказаться устаревший джаббер
Кто езаставил поставить его! У моих собеседников( это реальное использование), почти у всех новые версии! Потому что я просто им говорю, что этот лучше. Если кто-то отказывается переходить. Значит его ничего не раздражает. К сожалению я новый пользователь хабра, если бы я мог поставить минус, я бы поставил Вам минус, так же как и вы мне.
Ничего подобного, не-легаси версия прилетела в обновлениях автоматически (мне тоже прилетала, но я заблаговременно отключил обновления). И простой пользователь не станет менять настройки по умолчанию.
Почему то никто из моих собеседников не огорчился появление новой версии, наоборот обрадовались. Некоторые поставили легаси и теперь у них две версии Conversations (как и у меня также).
Почему вы приувеличиваете, когда говорите об новом обновлении, как о какой-то глобальной проблеме?
Процентов 99% обновление никак не затронуло. Опытные пользователи сейчас почти все на ОМЕМО (не в обиду вам), а те кто неразберается ничего даже не заметил.
Опять неправда ваша: достаточно отрубить в Conversations интернет на 15 минут или более и попробовать отправить сообщение в течение этих 15 минут. На сервере без MAM сообщение безвозвратно потеряется, иногда отправителю даже не приходит сообщение об ошибке — я неоднократно это проверял и продолжаю иногда проверять до сих пор.
Попробуйте сервер 404.city. Ваше сообщение 100% дойдет! Пробовал так делать и неоднократно
А сервер собеседника не поддерживает. Как мне понять, поучил/получит ли собеседник сообщение, если у него ни Carbons, ни MAM, ни уведомлений о доставке?
Да, в жаббере есть такая проблема, что люди регистрируются на заброшенных, любительски[ сервера и выбирают устаревший клиенты и после чего хейтят жаббер как технологию.
Решается проблема довольно просто, информирование о том что такое хмпп, как им пользоваться, какие есть хорошие клиенты и сервера, о различиях в них.
Обычный пользователь в ответ на это предложение выматерится и уйдёт в WhatsApp.
Говорил и не раз. Люди удивленно и с интересом расматривали.
Сама необходимость какого-то там знания портит впечатление об ХМПП обычным пользователям. Я знаю всё то, о чём мы с вами беседуем, а мои родители — не знают и знать не хотят. Поэтому они сидят и будут сидеть в WhatsApp, Telegram и Skype, как бы мной внутренний швабодкофил ни возмущался.
Если людям сразу сообщаещь, каой сервер хороший и какой клиент хороший, никакого батхерда нет. В гугл плее есть много плохих мессенджеров. Как вы не понимаете, что в жаббере такая ситуация.
Жаббер это не один мессенджер! Это несколько разных разговаривающий между собой
Итого: пусть у меня даже будет правильно настроенный сервер и идеальный клиент с поддержкой всех XEP'ов — какой толк от всего этого, если мой собеседник будет использовать условный QIP и всё равно потеряет мои сообщения от банального случайного отключения роутера?
В ХМПП не теряются сообщения. Это проблемы конкретно вашего устаревшего сервера. Смените его. Экпорт конктактов есть в мессенджере гажим.
Именно из-за всего этого XMPP (кроме несовместимого WhatsApp) остаётся и всегда будет оставаться уделом небольшой кучки гиков вроде нас с вами. А наши родители будут сидеть в проприетарных мессенджерах.
Мои родители знакомые и близкие друзья уже все в жаббере. Поставили Conversations и не жалуются. Друзьям и близким даже нравятся закрытые чаты внутри. Где они разговаривают только между собой
Я вам минусов не ставил, я вообще-то тоже не могу их ставить (а даже если бы мог, то всё равно бы не ставил — вас не учили, что ставить минусы за мнение и тем более за факты это неправильно?)
Вас и ваши собеседников никто не заставляет пользоваться плохими серверами и устаревшими клиентами!..
Так они вообще не в курсе, что используют что-то устаревшее!
моих собеседников( это реальное использование), почти у всех новые версии!
А у моих (это реальное использование) повсюду QIP'ы до сих пор. Если я предложу им поменять клиент и тем более сервер — меня просто пошлют.
Почему то никто из моих собеседников не огорчился появление новой версии, наоборот обрадовались.
Уверен, ваши собеседники — такая же кучка гиков, как и мы с вами. А мои собеседники — обычные пользователи, для которых XMPP — лютое неюзерфрендли.
Опытные пользователи...
Вот опять вы доказываете: XMPP — для небольшой кучки опытных пользователей.
Попробуйте сервер 404.city
Как мне заставить переехать все свои контакты на этот вот 404.city?
Решается проблема довольно просто, информирование
Ещё раз: обычным пользователям насрать, они не слышали и не желают слышать ни о каких SM, MAM, OMEMO и прочих непотребствах — они просто хотят брать и чатиться. Поэтому они берут WhatsApp, Viber и Telegram. Я активно занимался пропагандой джаббера ещё в 2008-2012 годах (ох уж эти школьные годы) и гарантирую вам, что всем насрать.
Говорил и не раз.
Я тоже (см. выше). Видимо, вы разговариваете с кучкой гиков/айтишников, а не, например, с бабушкой.
Если людям сразу сообщаещь, каой сервер хороший и какой клиент хороший
Им насрать, см. выше
Это несколько разных разговаривающий между собой
Да не разговаривают они между собой! Смотрите мою фотку — Conversations не осилил XHTML-IM. Про потерю сообщений тоже уже говорил.
Смените его.
Ещё раз: моим собеседникам насрать. Никто не станет менять сервер и JID ради меня.
Экпорт конктакто
Я регулярно делаю бэкап контактов в своём Psi+, но обычный пользовать и знать не хочет про существование какого-то там экспорта.
и не жалуются
Потому что вы им всё настроили и за ними следите. Обычный пользователь без помощи в лице знакомого тыжпрограммиста не осилит «стандартный» XMPP и пойдёт в WhatsApp.
И вообще, смена сервера — это боль, которую экспорт контактов смягчает лишь отчасти.
Так-так, давайте не спешить. Начнём сначала: где в Conversations кнопка отправки файла в конференцию? В личке есть, в конференции не вижу.
Смените сервер на 404.city. Вы выбрали устаревший или не обслуживаемый сервер.Ваш сервер не поддерживает http upload. Из-за это у возникают проблемы с хмпп и не появляется кнопка. На фото доказательство, того что в конференциях можно отправлять картинки
Эта ссылка отправлена из жаббера и актуальная только сейчас. Фаил автоматически удалится через 2 дня: Ссылка на фаил
Не надо потом, ставить минусы из-за того что картинки больше нет.
Вы выбрали плохой жаббер сервер из-за чего и испытываете трудности с использованием xmpp
В том и проблема. При выборе WhatsApp не нужно задумываться плохой он или хороший, он просто работает.
В том и проблема. При выборе WhatsApp не нужно задумываться плохой он или хороший, он просто работает.
Я хочу сказат вам тоже самое, но другими словами:
В том и проблема. При выборе Conversations и 404 не нужно задумываться плохой он или хороший, он просто работает.
Просто все знают о WhatsApp, а что такое жаббер и как им правильно пользоваться нет. (Если бы ватсап был свободным и федерализованным, за 20 лет, к нему бы тоже понаписали плохих клиентов и наделали плохих серверов.) В жаббере надо знать хороший клиент и сервер и тогда никаких проблем с ним нет
Просто все знают о WhatsApp, а что такое жаббер и как им правильно пользоваться нет.
Проблема заключается в «и как им правильно пользоваться». Чтобы технология имела популярность в широких массах, она должна обладать одним важным свойством. Ей должно быть невозможно пользоваться неправильно.
Конечно, жаббер это не мессенджер. Это протокол. Стандарт. Ну так давайте оценим его как протокол. Как стандарт.
Как оценивать? Начнём, пожалуй, с результатов. А результаты не очень. Популярность низкая. Проблемы присутствуют. Попробуем разобраться в причинах.
Вы вот выше доказываете, что проблемы, либо от «неправильного» клиента, либо от «неправильного» сервера. Ну, в определённом смысле это так. И выбрав «правильные» клиент и сервер, многих проблем можно избежать. Но почему всё именно так? Почему какие-то люди сидят, и пишут «неправильные» клиенты, держат «неправильные» сервера?
Вопрос можно было бы назвать риторическим. Кто же их знает, верно? Однако, мы ведь пытаемся оценить не конкретные клиенты и сервера, а протокол. Что сделал жаббер, как протокол, чтобы предотвратить появление этих «неправильных» клиентов и серверов? Ничего. С точки зрения протокола эти клиенты и сервера не являются «неправильными». Они «неправильные» с точки зрения современного пользователя, но не с точки зрения стандарта. Стандарту они соответствуют. Это говорит о том, что стандарт не отражает потребностей современного пользователя. И это однозначно говорит о том, что он плох. Да, именно так. Жаббер плох. Плох как протокол. Как стандарт.
Как так получается? Ведь вроде бы и развитие есть. И вроде бы даже реализуемые новшества вполне релевантны. На мой взгляд, всё дело в расширениях. Это гнилой подход. Это не годится для стандарта. Это не годится для протокола. В протоколах и стандартах важны гарантии. А когда всё на расширениях, то о каких гарантиях может идти речь? Когда какие-то функции вынесены в расширения — их поддержка не обязательна. Это равносильно отсутствию гарантий. А что, собственно, гарантировано стандартом без расширений? Тупо передача текста, который может будет доставлен, а может и нет. Что характерно, именно в таком виде это и работает, более или менее, везде, не зависимо от клиента или сервера. Что посеешь, то и пожнёшь.
И выбрав «правильные» клиент и сервер, многих проблем можно избежать. Но почему всё именно так? Почему какие-то люди сидят, и пишут «неправильные» клиенты, держат «неправильные» сервера?
Причины:
- Устаревании ПО. Жаббер появился в 2000 году. С тех пор прошло почти 20 лет… Часть клиентов и серверов устарела и не обновляется. Нельзя заставить людей слезть с этих клиентов и обновить сервера. Человеческий фактор. Каждый делает, что хочет
- Любительские сервера и клиенты созданные и поддерживаемые не профессионалами. Да, большинства серверов и клиентов создают обычные пользователи, а не компании. Качество таких клиентов и серверов, как правило плохое
- Отсутствие финансирования и в следствии плохая информационная поддержка
Основная проблема ХМПП:
Высокая степень децентрализации создает хаос. В ХМПП децентрализованная разработка, децентрализованные сервера, децентрализованные расширение(стандарты), децентрализованное обновления, децентрализованные стандарты шифрования, но жаббер таким и задумывался.
Что бы каждый из разработчиков мог слепить из хмпп свой идеальный мессенджер, такой каким он видит его сам, а не плясал под чужую дудку
Если сделать его централизованным, конечно можно решить все проблемы, но тогда это будет уже не жаббер
жаббер таким и задумывался.
Поэтому он не взлетел и никогда не взлетит.)
а не плясал под чужую дудку
Пляска под чужую дудку — это как раз следование стандарту XMPP. Все по-настоящему независимые разработчики изобрели свои протоколы, не завися ни от кого (фейсбук, ВК, телеграм и т.п.) Один лишь WhatsApp оказался исключением, но много ли кастомных XMPP-клиентов подключаются и работают к WhatsApp-серверам?
Пляска под чужую дудку — это как раз следование стандарту XMPP.
В стандарте ХМПП можно свободно написать свой стандарт, поэтому я с этим не согласен.
ХМПП как и сделан так, что любой мог написать свой стандарт внутри стандарта. ХМПП как матрешка. Единственно что должен поддерживать, что бы считаться полноценным, это отправку сообщений в XMPP, через вебсокет, http это уже там неважно
Пиши любой месенеджер который хочешь, но что он мог отправить сообщение в любой другой мессенджер с хмпп
WhatsApp это не позволяет. Conversations не понимает XHTML-IM, полученный от другого «любого мессенджера». Сообщения без MAM теряются на плохом интернете. Мессенджеры без поддержки шифрования не могут прочитать сообщения с шифрованием. Серверы, требующие шифрование, не позволяют передавать сообщения мессенджерам, не умеющим в шифрование.
Вывод: философия ХМПП не работает.
В принципе, выходом могло бы стать создание некоего обобщающего стандарта, который бы собирал воедино XMPP и наиболее важные из его расширений, объявляя их обязательными. Это могло бы стать основой для создания современных мессенджеров, совместимых между собой. И в то же время это не нарушит философию XMPP, т.к. не добавляет новых, несовместимых сущностей.
В принципе, выходом могло бы стать создание некоего обобщающего стандарта, который бы собирал воедино XMPP и наиболее важные из его расширений, объявляя их обязательными. Это могло бы стать основой для создания современных мессенджеров, совместимых между собой. И в то же время это не нарушит философию XMPP, т.к. не добавляет новых, несовместимых сущностей.
Поддерживаю. Это простая и гениальная идея
То есть, если появится компания, которая сделает приложение с функцией «прыгнуть с моста», это несомненно будет серьезным основанием взять и прыгнуть с моста? Ведь приложение наверняка писали сертифицированные профессионалы на зарплате, их инвесторы наверняка тоже прыгнули с моста… Почему контроль за данными, за стилем и поведением, за общением обязательно нужно отдать некоей корпоративной сущности?
Я всегда заглядываю сюда, если смотрю новый сервер.
Я проверял conference.jabber.ru — самый популярный сервер с джаббер-конфочками. Никакой другой сервер я проверять не собираюсь, потому что этот — самый популярный. Когда я смогу отправить файл в чатик на conference.jabber.ru — тогда и поговорим.
Чтобы не размазываться и не упираться в ограничение один коммент в пять минут, отвечу здесь на всё что ниже (точнее, выше относительно этого сообщения):
В том и проблема. При выборе Conversations и 404 не нужно задумываться плохой он или хороший, он просто работает.
Не работает же! Я не увидел XHTML-IM и не смог отправить файл в чатик conference.jabber.ru. И сообщения я регулярно теряю, потому что на моём сервере нет MAM, а менять сервер — это боль.
как им правильно пользоваться нет
В жаббере надо знать хороший клиент и сервер
как можно посмотреть возможности хмпп-сервера
Ещё раз: пользователям насрать, они ничего сложного изучать не хотят, им нужно просто взять и початиться. Хм, который десяток раз я это уже пишу? Вы своим родителям всё настроили, но в мире миллионы людей, у которых хорошего знакомого/родственника типа вас найдётся. И они просто возьмут WhatsApp.
От того, что этот ваш 404.city работает, пользователям jabber.ru и тысяч других серверов ничуть не легче. Вашей хвалёной совместимости и объединения на практике не существует.
Я проверял conference.jabber.ru — самый популярный сервер с джаббер-конфочками. Никакой другой сервер я проверять не собираюсь, потому что этот — самый популярный. Когда я смогу отправить файл в чатик на conference.jabber.ru — тогда и поговорим.
На скине фотография отправленная в чат bessonica2@conference.jabber.ru. Фотография в чат была отправленна с сервера 404.city. Я незнаю как с вами спорить, если вы отрицаете очевидный факт и не желаете разобратся в чем дело.
Вам нужно сменить хмпп-сервер на современный, что отправлять фотографии по http upload.Писать в чаты можно с любого сервера, а не только того на котором вы зарегистрованы. Jabber.ru самый крупный русский сервер, но далеко не самый лучший.
Вам нужно сменить хмпп-сервер
Я использую jabberon.ru, у которого есть HTTP File Upload согласно его диско (upload.jabberon.ru). На conference.jabber.ru всё работает, как вы заявляете.
То есть условия поддержки сервером HTTP File Upload и использования клиента Conversations оказалось недостаточно. Что ещё я должен сделать, чтобы кнопка появилась и файл отправился?
Jabber.ru самый крупный русский сервер, но далеко не самый лучший.
Ещё раз: обычные пользователи об этом не знают и знать не желают.
Conversations заявляет, что XEP-0363 недоступен. А почему он это заявляет при наличии upload.jabberon.ru в диско — а фиг его знает. Может, загрузка файлов на этом сервере разрешена только избранным? Тогда почему бы не написать какую-нибудь внятную ошибку доступа?
Может, загрузка файлов на этом сервере разрешена только избранным?
Нет просто, админ неправильно настроил сервер. В жаббере можно отправлять картинки в чаты, если зайдете с 404 сами убедитесь в этом. На скрине мной отправленным последняя версия конверсатионс, аккаунт на сервере 404 и чат бессоница на jabber.ru
Я использую jabberon.ru, у которого есть HTTP File Upload согласно его диско (upload.jabberon.ru). На conference.jabber.ru всё работает, как вы заявляете.
Jabberon заброщенный сервер. Я проверил ваш сервер. Действительно, на вашем сервере включен http upload, но неправильно настроен администратором сервера. Вам лучше всего сменить сервер.
Никакой другой сервер я проверять не собираюсь
Вам нужно пересмотреть свой взгляд и не быть таким консервативным и у вас все работать отлично.
В хмпп есть сервера новой волны и мессенджеры новой волны, они радикально отличаются по возможностям от старых серверов.
В жаббер не ограничение на вход в конференции с других серверов. Можно в конференции на жаббер.ру хоть со своего сервера с http upload входить и постить там картинки.
Конкретно на вашем сервере Jabber.ru, админ обещал обновить ПО и включить http upload этим летом
Я не смогу всю свою сотню контактов заставить пересмотреть их взгляды и повторить то же самое. А если все мои контакты продолжат использовать старьё, то какой толк от того, что я буду использовать всё самое новое и крутое? Ой, по-моему я вам это уже писал раза три.
И про http upload см. выше — на моём сервере он и так есть, как заставить его работать-то?
Это же жаббер, можно плодить аккаунты тысячами)
Умножаем эти тысячи на сотни контактов, которые должны ответить на presence type=subscribe, и получаем сотни тысяч проблем с переносом JID :)
На андроиде рекомендую заносить Jabber ID в адресную книгу, где номера телефонов.
Имхо это общая проблема всех ИМ. Те из которые поддерживают децентрализацию, шифрование и опен-сорс — недостаточно хорошо работают и не столь популярны как распиаренные проприетарные решения, которые увы рано или поздно оскайпиваются до такой степени когда пользоваться уже больше невозможно но и уйти нелегко.
А заставить всю сотню контактов переехать на новый протокол сможете?У протокола Matrix есть мосты в другие сети, поэтому можно прямо из любого Matrix-клиента напрямую общаться с пользователями других сетей — уже реализованы мосты в Телеграм, Gitter, IRC, Slack и в процессе разработки — Skype, Facebook, Hangouts и т.п.
Весь геморрой по переправке сообщений из Matrix в чужеродные сети и обратно берёт на себя Matrix-сервер, поэтому клиентское приложение не будет выжирать трафик, процессор и батарею.
Я пролистал XEP-0363, но не увидел там никаких настроек про время жизни файла. То есть обычный пользователь даже не может прямо через клиент узнать, сколько его файл проживёт? Только ходить на сайт выглядывать едва заметную надпись «HttpUpload 1Gb & 2 day»?
В долгосрочной перспективе цель проекта – создать открытую альтернативу существующим проприетарным мессенджерам, повторить в отношении мессенджеров то, что сделал Android в отношении операционных систем для мобильных телефонов.
Это сделал не android, а Google. Производителям мобильных устройств оказалось выгоднее использовать android который поддерживает огромный google, чем пилить каждые несколько лет свои собственные ОС не совместимые с друг другом. Сравниваем с apple у которой есть ресурсы на поддержания и развития своей собственной замкнутой экосистемы.
Текущие лидеры в мессенджерах взлетели тоже не на пустом месте, а чуть ли не буквально сжигая мешки с деньгами. Примерно тоже самое твориться с браузерами, компании лишенные денежной поддержки сдуваются (opera\mozilla). Что бы новый мессенджер в текущих условиях мог захватить хотя бы часть рынка, у него должно быть что то новое, чего нет во всех остальных, или должны быть огромные денежные вливания.
> Текущие лидеры в мессенджерах взлетели тоже не на пустом месте, а чуть ли не буквально сжигая мешки с деньгами
Аналогично, в 2006 году Microsoft и Nokia сжигали мешки с деньгами, создавая свои мобильные операционные системы, а всех победил Андроид, с финансированием на два порядка меньше конкурентов.
Сравнение с браузерами не вполне корректно, т.к. в браузере сетевые эффект слабые — мой выбор браузера никак не зависит от выбора браузера моих друзей.
Насчет лидеров — WhatsApp продемонстрировал ровно обратное, никакого сжигания мешков.
Мы не знаем как все было на самом деле, но у WhatsApp была определено большая фора. В WhatsApp первыми додумались использовать номера телефонов, как Jabber ID-ы. Они загнали в ejabberd базу номера телефонов и делали подписки в зависимости от того, есть номер в адресной книги или нет.
Далее пошла реклама: Бесплатные смс-ки! Налетайте все!
IMHO без End-to-end шифрования, в т.ч. групповых чатов — точно не взлетит. Сложно или нет, но многие мессенджеры эту фичу уже осилили, кто-то лучше, что-то хуже, и пути назад уже нет. Что касается "что знают трое" — это, конечно, правда, но далеко не вся. Риск утечки увеличивается с ростом числа участников, но не становится равным 100% начиная с трёх человек. А вот число посторонних желающих получить информацию, которая их никак не касается — постоянно растёт. Пока это были только спец.службы — это было относительно терпимо, хотя в случае наших ещё и был шанс что информация от них уйдёт "налево" и попадёт к конкурентам. Но сейчас информацию хотя вообще все подряд, для показа рекламы, для продажи, просто на всякий случай чтоб было… End-to-end шифрование позволяет отсечь 99.999% любопытствующих, оставляя место только добровольному разглашению одним из участников (с чем можно бороться разными методами, от технических до юридических) либо утечке с заражённого малварью устройства одного из участников (с чем тоже можно бороться).
Кстати, а чем не устроил Matrix?
IMHO без End-to-end шифрования, в т.ч. групповых чатов — точно не взлетит
Никто не спорит, что шифрование нужно. Вопрос приоритетов. А приоритеты определяются соотношением потребности к потраченным силам на разработку. Потребность в шифровании, конечно, есть, но она не выглядит так, что нужна абсолютно всем и без нее никуда. Где-то видел статистику, что в Телеграме шифруется меньше 1% чатов.
Или пример емейла. Из крупных игроков еще год назад TLS для межсерверной передачи данных был только в gmail. Не end-to-end шифрование, а эквивалент HTTPS для передачи почты между серверами. И что, все из-за этого ушли с mail.ru на ProtonMail?
Кстати, а чем не устроил Matrix?
Хороший проект, но с другими целями и приоритетами.
Потребность есть, нет потребности что-то ради этого делать. Именно поэтому в телеграме шифруется мало чатов — потому что нужно нажать лишние кнопочки, да и вообще просто задуматься о необходимости их нажать. Плюс в десктопном клиенте они не поддерживаются, и в веб вроде тоже.
Что касается email, то TLS там никого не волнует вообще — кому нужна безопасность тот использует PGP/GPG.
В общем, суть в том, что шифрование должно работать из коробки, чтобы люди об этом не задумывались вообще. А когда задумываются — чтобы могли сверить отпечатки ключей удобным способом, чтобы убедиться что общаются именно с тем, с кем думают.
Посмотрите как выдавливают http и любой ценой заменяют на https. И на TLS в почте, да. Суть в том, что времена не шифрованных коммуникаций заканчиваются, поэтому чтобы выжить в ближайшие годы — нужна поддержка шифрования, причём не для гиков, а удобная и прозрачная настолько, чтобы обычные юзеры её использовали по умолчанию и толком даже не замечали этого.
Согласен, все верно. Вопрос ведь не в принципе, а в приоритетах — можно потратить время на OTR, а можно на что-то другое. Что важнее пользователям, на то и нужно тратить. Сейчас, например, больше всего запросов на повторение функционала Slack-а в каком-то виде.
На OTR время тратить не надо. Я его нежно люблю, но поддержки групповых чатов и синхронизации истории между устройствами в нём, насколько мне известно, не предвидится, а значит будущего у него нет.
Вероятно, что-нибудь на базе Double Ratchet Algorithm, напр.: используемый в XMPP OMEMO, Signal Protocol, Matrix…
А поподробней можете описать чем ваши цели и приоритеты расходятся с Matrix.org?
Сейчас у меня ощущение, что вы переизобрели жаббер, а ваша простота API и компактные RFC — вещи, которые со временем превратятся в талмуды к какому-нибудь релизу «v2.0»
WhatsApp выбрал eJabberd из-за того что он обладает высокой отказоустойчивостью. 2 000 000 человек на одной ноде, из-за этого и любят XMPP(в особенности разработчики проприетарных мессенджеров). На дешевом VPS с eJabberd-ом можно расположить сервер с тысячами человек в онлайне
Стресс-тест Ejabberd. 2 000 000 в онлайне на одной жаббер-ноде blog.process-one.net/ejabberd-massive-scalability-1node-2-million-concurrent-users
Во-первых, для отправки онлайн статуса не вижу в этом необходимости — это может сделать клиент, раз он онлайн. Тот же ping + timeout решит проблему offline.
Во-вторых, может я не хочу иметь все контакты на всех устройствах. Может я хочу завести 2+ аккаунта (рабочий, личный, ...) Да и вообще не хочу делиться контактами хорошего сантехника с сервером. Было бы неплохо (да и оригинальная фича) сделать выборочную синхронизацию контактов. А еще интереснее, сделать разделение контактов на «Саша мобильный», «Саша компьютер», «Саша рабочий» с возможностью отсылать сообщения конкретному субконтакту (и не забыть сделать возможность отсылать себе «на мобильный»!) и контакту в целом (путь принимают все, кто онлайн).
На счет репутации мысль дельная, но, как я понял, это будет только репутация серверов для межсерверного общения? Т.е. единичные клиенты могут слать спам безнаказанно, подключившись к конкретному серверу? Или для них тоже есть репутация? Как она будет тогда вырабатываться? Не ясно.
Ну, и присоединяюсь к вопросу выше — зачем придумывать еще один протокол/стандарт? А не выбрать существующий, благо их тысячи.
это может сделать клиент, раз он онлайн
Не может. Его Android просто убил т.к. память на телефоне кончилась.
Тот же ping + timeout решит проблему offline
Кто и по каким адресам его будет рассылать, если клиент уже убит операционной системой, а на сервере вы предлагаете контакты не хранить?
Т.е. единичные клиенты могут слать спам безнаказанно, подключившись к конкретному серверу
А это будет уже проблемой конкретного сервера/узла. Если из узла идет спам, то он потеряет репутацию и от него перестанут принимать сообщения.
Т.е. в рамках одного узла можно рассылать спам, затем подключаемся к другому узлу и рассылаем там.
А в ios вообще невозможно такое сделать.
У того же вацапа или вайбера или телеграмма идет открытое сообщение через пуш сервис гугла и Эпла.
Ведь приложение в этот момент не работает, а сообщение можно прочитать.
Следовательно их енд-2-энд не работает.
Т.е. и гугл и эпл в курсе всей переписки всех мессенджеров.
По идее надо делать так чтобы приходило шифрованное пуш сообщение и только в момент запуска пользователем приложения оно бы расшифровывалось (кстати такие мессенджеры есть).
Вот так делать — совсем другое дело.
А так получается что все эти end-2-end на самом деле с гуглом и эплом посередине.
И почему-то никто на этот факт внимания не обращает.
Не получится. Во-первых, невозможно надежно показывать онлайн статус без контактов на сервере. Во-вторых, web-клиент удобен, а web-client требует контактов на сервере. Не пробовали пользоваться web.wechat.com? Настолько неудобно, несколько вообще можно себе представить. А там просто сообщений старых нет.
То, что вы предлагаете — другой продукт с другими целями. Возможно, кому-то он нужен, и может быть кто-то захочет его создать.
На сервере можно хранить и ростер и переписку, но только в виде шифрованного блоба.
Реквестирую больше конкретики: чем шифровать и кто, как и где расшифровывать будет?
Эти xmpp-сервера имеют разные подходы к доставке сообщений. На jabber.ru хранится история сообщений. На сервере 404.city сообщения не хранится. На 404.city сообщения напрямую передаются на онлайн устройства, как в описанном вами предложения.
Поскольку я на практике знаком с обоими подходами, что лучше хранить историю на сервере или нет, я сказать не могу.
С одной стороны, подход с отсутствием хранения истории на сервере большой плюс к приватности.
С другой стороны, когда два устройства включаются поочередно ( оставил включенным пк, а мобильная сеть пропадает на минут пять), сообщения приходят не туда.
На Jabber.ru, где есть серверное хранение истории, так не происходит. Приходится выбирать между большей приватностью или удобством (ну или просто отключать второе устройство)
К тому же, отсутствие хранения истории сообщений не удобно тем кто любит перечитывать старые сообщения (да, есть такие люди и их много)
Как раз эти проблемы разных вкусов и предпочтений и пытается решить XMPP, со множеством XEP-ов
Проблема переноса аккаунтов в жаббере, частично решена в клиентах.
В декстопном Gajim, есть возможноcть экспорта контактов из одного аккаунта в другой.
В мобильном Conversations, есть возможность хранить жаббер-контакты в адресной книге андроида, как номера телефонов.
Существует так же мобильный жаббер kontalkt, где JabberID это номера телефонов. Он работает по принципу добавления контактов так же как WhatsApp, Telegram и т.д
2)Перечитывать можно и оффлайн. Особенно если предусмотреть удобную синхронизацию состояния(контактов\истории\etc) без участия сервера(по вафли в одной сети\через файл).
Задумка у XMPP была хорошая, как раз создать один такой единый стандарт коммуникаций для всех мессенджеров, а дальше пускай бы писали свои расширения, но она запнулась об это.
Сегодня WhatsApp разрешит писать в него с жаббера, а завтра все кто недоволен WhatsApp, но вынужден его держать удалит его и компания потеряет часть пользователей.
Был такой мессенджер, Meebo, ещё до воцапов с телеграмами — он делал именно так, как вы описали, позволял подключить кучу разных мессенджеров и объединял их все в обном удобном веб-приложении и приложении для телефона.
Мои знакомые неудомевали, как это я в аське круглосуточно онлайн, даже когда лечу над Тихим oкеаном.
А потом из купил Гугл и закрыл.
Зачем писать Postgres если есть MySQL? Зачем писать Mongo если есть Postgres и Mysql? Зачем писать Redis, если есть Mondo, Postgres и Mysql? Зачем писать RocksDB если…
У каждого проекта свои цели и приоритеты. Signal про криптографическую безопасность. Tinode про федерацию, удобство пользователя и гибкость настроек.
И не забудьте решить проблему смерти серверов в федерации. А то мне уже приходилось разок эвакуироваться с умершего jabbus.org — это весьма неприятно.
Скачал в плеймаркете — ввел адрес сервера — авторизовался — и общаешься спокойно, не боясь рос******зора.
Интересный проект, я бы попробовал… С чего лучше начать?
С 2002 года пользуюсь разными месенджерами. ICQ и клоны получили распространение, так как в те времена просто не было ничего подобного. Skype дал возможность бесплатно общаться голосом по всему миру, при этом требовал минимальных усилий от пользователя, легко пробивал всякие NATы, файрволы.
WhatsApp пришёл как бесплатная замена SMS и при этом тоже требовал минимальных усилий привязываясь к номерам телефонов, установил и всё. Телеграм акцентировался на безопасности и, конечно, личность Дурова играет большую роль.
Киллер фичей была бы возможность обмениваться трафиком между разными сервисами, но это не выглядит реалистичным, абсолютно.
Плюс ещё момент, что на месенджерах до сих пор никто не смог зарабатывать. Заработок происходил только в момент продажи предыдущими владельцами Майкрософт, Фейсбук и т.д.
Кстати, скоро будет 10000, но действительно, сделать массовым мессенджер нелегко.
Чтобы был виральный эффект, нужно набрать критическую массу, может быть 100 тыс, а может и 1 млн.
Т.е. на первом этапе нужно продвигаться в любом случае.
Мы этим пока не занимались, потому что допиливали видеозвонки и Live TV режимы, вот только на днях выложили версии со стабильными и качественными видео и Live.
Еще одна проблема — нужно сделать все теже самые фичи что например в WhatsApp и добавить свое, т.е. по сути в идеале нужно сделать продукт, который умеет все тоже самое и плюс на голову выше их по другому функционалу.
Вдобавок к этому мы попали под раздачу РКН в связи с блокировкой Телеграм, т.к. мы хостимся на Амазоне и возможно в РФ он не работает (по крайней мере несколько раз пользователи жаловались и в тоже время у них же через впн все работало).
А если мы хотим сделать что-то, чего в Телеграме нет? А если Телеграм хочет сделать что-то, что мы считаем неправильным? Если если Дуров пришлет нам письмо "Прекратите использовать нашу интеллектуальную собственность"?
2) это проблема — да.
3) ну это. пошлёте ему в ответ фоточку стольмана, поедающего козявку с подошвы ноги. ну или ещё что-нить смешное про gpl
> А если мы хотим сделать что-то, чего в Телеграме нет?
… сделайте…
> А если Телеграм хочет сделать что-то, что мы считаем неправильным?
… выкиньте…
> Если если Дуров пришлет нам письмо «Прекратите использовать нашу интеллектуальную собственность»?
… сошлитесь на GPLv3.
Вроде сходится?
Код десктопной телеги — сравнительно простой и достаточно продуманный. Приличный современный C++. Чтобы сделать что-то подобное самим — придется сильно потрудиться. И это только fontend и только десктоп. А есть ещё мобайл во всех его красках без которого современный мессенджер обречен на смерть ещё не родившись.
Даже на приличный современный frontend нужно ресурсов. Потяните с нуля?
Форкнитесь и…
Разговор про "дорисовать свой backend". И какой смысл реверс-инженирить сервер, чтобы сделать из него несовместимый продукт? Профит в чем?
… сошлитесь на GPLv3.
Речь не про клиентские приложения, а про гипотетический сервер.
Код десктопной телеги
А вот интересно, насколько популярен десктопный клиент? Есть где-нибудь цифры?
С клиентскими приложениями тоже не все отлично, т.к. GPL затрудняет создание независимых коммерческих проектов.
Разговор про «дорисовать свой backend». И какой смысл реверс-инженирить сервер, чтобы сделать из него несовместимый продукт? Профит в чем?
Несовместимый с чем? Как раз наоборот, совместимый.
С клиентскими приложениями тоже не все отлично, т.к. GPL затрудняет создание независимых коммерческих проектов.
Это если брать код и делать свою коммерческую версию на его основе, если же пользовать ПО, то никаких трудностей нет. Насколько я понимаю, в этом проекте коммерции (на коде) не предполагается. Ну и к слову, Red Hat c Oracle что-то не жалуются на GPL.
Если мы говорим за messender широкого плана, то наличие и десктопной и мобильной версий — это IMHO must have. В противном случае mobile only версия конечно наберет свою пользовательскую базу, но скажем для рабочих процессов это использовать уже не получится.
Ну и голосовые конференции конечно же. Без возможности пообщаться голосом причем нескольким участникам — это ни о чем. Видео не так важно.
Возможно, blockchain (но не криптовалюта) может быть использован в качестве основы для построения распределенной системы репутации, хотя пока и не очевидно каким образом.
.
Блокчейн — не поможет, это централизованная и уязвимая структура.
Вам следует использовать распределённую сеть доверия.
Блокчейн — не поможет, это централизованная и уязвимая структура.
В статье критикуется не блокчейн вообще, а блокчейн в той форме, в которой он используется в криптовалютах. Критика разумна, но не по адресу.
Вам следует использовать распределённую сеть доверия.
Скорее всего будет какая-то производная от https://en.wikipedia.org/wiki/EigenTrust
Возможно, стоит написать отдельную статью про распределенную систему учета репутации.
Вот что-то не получается ни у кого сделать такое. Обычно, либо оно централизованное, либо очень неудобное и убогое. На Tox можно для примера посмотреть.
Каким образом предлагается обслуживать полтора миллиарда мобильных клиентов как, к примеру, у WhatsApp?
Если не считать торренты, то децентрализация получилась только у раннего Скайпа. И то, в эпоху десктопов было немало жалоб на прокачку чужого трафика на клиентах выбранных супернодами.
Плюс были проблемы массовых сбоев когда оказывалось, что суперноды не спешили обновлять клиента.
Так же есть риски визита спецслужб, если вдруг окажется, что через ваш компьютер прокачивался какой-то не очень хороший трафик. А эти риски сейчас совсем не нулевой вероятности.
тут ведь можно сочетать.
Сделать что-то централизованное, неудобное и убогое?
А если серьёзно, прежде чем пытаться сочетать, надо тщательно проанализировать почему раньше ни у кого не получалось. Интуиция подсказывает, что тут мешает что-то фундаментальное. Совместить распределённость, синхронизацию, и эффективность кажется, если не невозможной, то очень сложной задачей. А каким должен быть оптимальный компромисс — не совсем понятно.
Эта стратегия, кстати, позволит решить множество других проблем, связанных с приватностью и анонимностью.
Практически всё, что вы описываете и планируете сделать, там уже реализовано на вполне юзабельном уровне. Есть даже уже несколько разных имплементаций клиентов на разных языках программирования matrix.org/docs/projects/try-matrix-now.html#clients и серверной части matrix.org/docs/projects/try-matrix-now.html#servers
И даже есть рабочие шлюзы в Телеграм, Гиттер, IRC, Skype и другие мессенджеры.
Мне кажется будет логичней и эффективней присоединиться к команде Matrix, чем изобретать свой велосипед.
Фиг с ним, с убогим REST, но — чё там с вебсокетами?)
Как раз можно заняться допиливанием этого PR, чтобы всем прибыло вёбсокетового счастья :)
разработчики пока не увидели особых преимуществ в срочном переходе на них по сравнению с HTTP Long Polling
И тут вся моя остававшаяся вера в Matrix развалилась окончательно. Если в сабже будет нормальная федерация, возможно поддержу его
А если текущий HTTP Long Polling «просто работает» и всех устраивает, зачем ломать и переделывать в срочном порядке? Кому надо побыстрее — пусть присоединяются к PR и дорабатывают.
И они уже огромный объём работы проделали, особенно по реализации федерации. А вам с новым мессенджером ведь придётся всё это заново писать, это огромный объём работы.
И в итоге нужно будет официально поддерживать целых два способа подключения и в клиентах, и в серверах, при том что один из них просто лишний (лонг-поллинг, ага). Говорю же, устраивают легаси с самого начала. Не надо так.
Теперь лучше уж сделать новый нормальный протокол, своровав хорошие идеи из XMPP и Matrix (чтобы объём работы уменьшить) и не накосячив с лонг-поллингом :D
И ещё использовать CBOR вместо XML/JSON будет нелишним. Сабжа тоже касается.
Кстати, никто не мешает написать свой вариант сервера Matrix с блекджеком и вёбсокетами, но совместимого с Federation API — вот примеры такой реализации: mxhsd и Ruma
В общем, Matrix окончательно умер в моих глазах.
Я мог бы написать, что messaging — потоковая архитектура, и реализовывать ее на транзакционном REST-API немного нелогично, но не буду.
Мог бы сказать, что причина в том, что Matrix в первую очередь API, а потом уже приложение, построенное на нем, и, как результат, API слишком широкий, но это было бы неправдой.
Сказал бы, что Go для написания потоковых приложений подходит лучше, чем Python, но тоже не буду. Кто что умеет, тот то и отстаивает.
Сказал бы, что хочу разрабатывать систему с единомышленниками, которые не пишут "добавление вёбсокетов — у них в планах есть, но пока в низком приоритете". Но это тоже не было причиной.
А реально причина "чем не устроил уже существующий открытый и активно развивающийся протокол Matrix" очень проста — его не было в 2014 году.
Почитал спецификацию как в matrix устроено присутствие:
https://matrix.org/docs/spec/client_server/r0.3.0.html#id62
И, мягко говоря, был удивлен. Они реально предлагают использовать pull, т.е. периодически спрашивать сервер об онлайн статусе контактов? Без шуток, в 2018 году спрашивать сервер раз в 10 или 20 секунд? Вот прямо так, с мобильного телефона и спрашивать? Или я все-таки что-то недопонимаю в их спецификации?
Вообще в мессенджерах присутствие — это процентов 50 сложности. Если кто-то делает присутствие как pull, то, скажем так, он неправ.
pull — возможно единственный способ доставки евента
Нет, конечно. Например, емейл настолько распределенная система, насколько это бывает, и сообщения там ходят от сервера к серверу как push. Даже в XMPP, несмотря на то, что я его не люблю, надо отдать должное, присутствие сделано как push. У меня прямо-таки взрыв мозга, что кто-то может всерьез в 2018 году предлагать pull как механизм обновления присутствия.
Даже в XMPP, несмотря на то, что я его не люблю
Очень жаль. Из вашего приложения, мог бы получится неплохой веб-клиент для декстопа
На мой взгляд задача вполне может решаться пошагово, а не «все или ничего». Начать достаточно с устойчивости системы, сравнимой с емейлом. И дальше по мере необходимости добавлять фичи типа DHT для нахождения пиров.
Даже в XMPP, несмотря на то, что я его не люблю, надо отдать должное, присутствие сделано как push.Интересно, как это через PUSH реализовано? Напрямую не пошлёшь, т.к. все мобильные девайсы за NAT-ом, получается только через сервисы гугла-яндекса рассылать, а там есть лимиты на кол-во отправок.
Да и вообще — если у меня 1000 контактов, и изменение статуса каждого контакта мне PUSH-ем будет прилетать на мобилу — с таким подходом батарею от Камаза надо будет ставить на мобилу ;)
Ээ, серьёзно? Тогда не удивительно, чего презенсы на matrix.org вообще отрубали нафиг. Ещё один гвоздь в крышку гроба мертворожденного Matrix
Без шуток, в 2018 году спрашивать сервер раз в 10 или 20 секунд? Вот прямо так, с мобильного телефона и спрашивать? Или я все-таки что-то недопонимаю в их спецификации?
А у других мессенджеров это как-то лучше реализовано? У того же воцапа с его xmpp+костыли, или у вайвайбера который на базе SIP протокола разрабатывался?
Для мобил — в Matrix уведомления о новых сообщения через PUSH прилетают, а изменение статуса контактов через PUSH гонять — это уже совсем бред.
Поэтому активного соединения не поддерживается и батарея не жрётся в фоне. А для активного приложения — варианта два: либо вёбсокеты (которые matrix скоро всё же прикрутит) либо long polling, или ещё что-то есть интересного?
Поддерживать постоянное активное вёбсокет-соединение в фоне на мобильном девайсе с динамическим ип и нестабильным интернетом — это практически то же самое для батареи и трафика.
Немного мелочей по сабжу: не обнаружил в протоколе использования SASL, это не очень хорошо. CRAM-MD5, в который меня тыкали носом выше в комментах, есть в SASL, и поддержать всё это дело будет правильно.
Немного странно изобретать «random 64-bit number» вместо стандартного UUID.
Тырить юзер-агент из HTTP — плохая идея, это довольно убогая штука. Получение информации в том же XMPP сделана очень хорошо, например.
Лонг-поллинг не нужен. Вебсокет тоже избыточен, но фиг с ним, для веб-клиентов пригодится.
SASL… поддержать всё это дело будет правильно.
Зачем? Не троллю, на самом деле спрашиваю. Если добавить SASL, то что это даст пользователю, разработчику или администратору системы?
Немного странно изобретать «random 64-bit number» вместо стандартного UUID
Рассматривали, долго дебатировали. int64 лучше поддерживаются в базах данных и короче. Наличие стандарта, описывающего конструкции разных UUID не является какой-то полезной фичей само по себе.
Тырить юзер-агент из HTTP — плохая идея
Поменять несложно. Можно поподробнее?
Лонг-поллинг не нужен
Да, думаю, что в 2018 году больше не нужен. Когда начинали был нужен.
Зачем?
Стандарт же. SASL используется много где (хоть те же джаббер и почта), уже есть куча готовых реализаций и куча алгоритмов аутентификации на любой вкус (тот же CRAM-MD5). SASL абстрагирует механизм аутентификации от остального протокола (Tinode) и позволяет творить с аутентификацией что угодно, в том числе переиспользовать готовые реализации — а это уже должно быть полезно для разработчиков, которым не придётся городить велосипеды (ну или будет проще адаптировать и переиспользовать существующие велосипеды) (при нормальной архитектуре реализаций, конечно же, хех).
Сильно не вчитывался и могу ошибаться, но, как я понял, сейчас используется обычная PLAIN аутентификация, которая не очень хороша, потому что пароль попадает на сервер в открытом виде. Если очень хочется продолжить использовать PLAIN, то в SASL аналогичный алгоритм тоже есть.
Поменять несложно. Можно поподробнее?
В юзер-агентах всё свалено в одну кучу и каждый пишет что попало, а в jabber:iq:version по-нормальному разделены имя, клиент, версия и ОС — намного удобнее обрабатывать программно.
SASL абстрагирует механизм аутентификации от остального протокола (Tinode)
Так оно сейчас и работает. Поддерживаются три разных механизма аутентификации и нет никаких проблем добавить еще 30. Механизм авторизации абстрагирован от остальной логики. Может быть то, как сейчас работает, и не называется SASL, но концептуально очень-очень похоже.
В юзер-агентах всё свалено в одну кучу и каждый пишет что попало, а в jabber:iq:version
OK, спасибо.
Так оно сейчас и работает.
концептуально очень-очень похоже.
Вот поэтому и нужно как можно скорее брать стандартный SASL, а не клепать ни с чем не совместимый велосипед без причины ;)
нет никаких проблем добавить еще 30
И в SASL это уже сделано до вас.
А что значит "стандартный SALS"? Это ведь не библиотека, не API, а протокол, который определяет обмен сообщениями между клиентом и сервером. Давайте я скажу тогда, что у нас реализовано подмножество SASL?
И в SASL это уже сделано до вас.
Мы говорим о разных вещах.
Давайте я скажу тогда, что у нас реализовано подмножество SASL?
RFC 4422 предъявляет вполне конкретные (и довольно простые, несмотря на длину RFC) требования без всяких там подмножеств. Давайте вы не будете выпендриваться велосипедами и вносить дополнительную неразбериху в и без вас творящийся хаос в мессенджерах?
Да, вы совершенно правы. Пойду удалю проект с Гитхаба, чтобы не вносить неразбериху.
А если серьезно, то так, как вы пишете: "мне нравится RFC 000, давайте вы разберетесь зачем он нужен и его реализуете" — не очень полезно. Полезно бы было "я внимательно посмотрел на ваш код/документацию, у вас так-то, а если было бы так-то, то это позволило бы то-то и то-то". А еще лучше "вот вам pull request, он добавляет поддержку того-то что полезно потому-то".
Был такой формат картинок — TIFF. Я когда-то в стародавние времена писал для него писалку-читалку. Писалку для него делать — одно удовольствие. Пиши как хочешь и все получается по стандарту. А вот читать — убийство. По сути TIFF только назывался стандартом, а реально являлся десятком разных форматов под одним зонтиком. SASL, похоже, что-то аналогичное.
Можно примеры каких-нибудь B2С приложений, использующих SASL?
Не знаю, о каких B2C речь, мне достаточно того, что SASL работает в джаббере и почте, и работает хорошо. Другие примеры использования вы вполне можете найти самостоятельно, вас же в гугле не заба… а, ну да :(
Сравнивать с TIFF некорректно. Вас никто не заставляет реализовывать и читать абсолютно все алгоритмы — никто не запрещает вам оставить один-единственный PLAIN. Но если вы задумаетесь над комментами других хабраюзеров и захотите прекратить передавать пароль открытым текстом, то с SASL можно было бы просто взять готовый CRAM-MD5, а у вас сейчас, похоже, ничего подобного в протоколе ещё нет. (Здесь ещё можно было бы припомнить совместимость с другими существующими базами данных, но я сам не в теме)
Раз вы не хотите SASL, давайте проверим одну простую вещь — что нужно сделать, чтобы запилить в Tinode аутентификацию с помощью OAuth?
Другие примеры использования вы вполне можете найти самостоятельно
Ну ок, будем считать, что поговорили
Раз вы не хотите SASL, давайте проверим одну простую вещь — что нужно сделать, чтобы запилить в Tinode аутентификацию с помощью OAuth?
Написать соответствующего провайдера с таким интерфейсом:
https://github.com/tinode/chat/blob/master/server/auth/auth.go
Написать соответствующего провайдера с таким интерфейсом
А чуть подробнее? Для OAuth нужны следующие шаги (примерно):
- получить ссылку на какой-то веб-сайт;
- сходить по ссылке, дать пользователю потыкать сайт и по результатам забрать токен (точнее, даже два токена, но пока упростим задачу);
- отдать этот токен серверу.
Как это запхнуть в интерфейс по вашей ссылке, я как-то не понял. Не исключаю, что я тупой и/или не выспался, расскажите как, а?
Ну вот так и сделать, как вы написали. Покажите, что вам на самом деле интересно, а не просто поспорить хочется.
Я знаю, что можно сделать так, как я написал. Я не знаю, как это сделать в показанном вами интерфейсе. Как сервер должен скормить в него ссылку? Как в нём открыть браузер? Не увиливайте от ответа, пожалуйста — мы тут обсуждаем фундаментальные проблемы протокола вообще-то.
1. Каждое сообщение симметрично шифруется случайным ключом. Случайный ключ шифруется публичными ключами каждого из участников. Для очень больших чатов возможен такой вариант: каждый участник публикует свой случайный ключ, который будет действовать следующие n часов, зашифрованный открытым ключом каждого из участников чата, после чего постит только сами зашифрованные сообщения, без ключа.
2. Каждый клиент сам выбирает, какую информацию он предоставляет другим участникам чата. По умолчанию, другие участники не могут видеть даже его глобальный ID. Вместо этого они видят его локальный ID, уникальный для каждого чата, который является функцией от ID группы и глобального ID клиента. Таким образом, у наблюдателя, который в чате #mylittlepony видит участника $7fdc8a00, а в чате #kde2 — участника $1120fc07, нет возможности узнать, каков глобальный идентификатор каждого из них, и являются #mylittlepony$7fdc8a00 и #kde2$1120fc07 одним и тем же клиентом или нет.
Некоторые другие соображения:
Не вижу причин, почему некоторые противопоставляют синхронизацию истории и приватные чаты. Можно сделать хранение и подгрузку защищённой отдельной парой ключей, не связанной с основной перепиской.
"пишем…" на хабре раньше под таким заголовком допускались только статьи либо с простыми решениями, либо с детальным анализом существующего. В любом случае был подробный рассказ про архитектуру с небольшими кусками кода
У Вас же получилось что-то в духе "Tinode еще один open source чат".
И почему же?
Тупо добавить поле вроде replace к самому обычному сообщению, чтобы сделать его сообщением-редактированием. Так сделано в XMPP и (предположительно) Telegram. Ну и просмотр истории сообщений немного пропатчить, чтобы эти replace учитывать, и пару дополнительных индексов в базе прокинуть — версионирование получится само по себе
?
Интересное совпадение. На XMPP, для Линукс недавно появился мессенджер Dino dino.im, это немного созвучно с Tino. Дизайн и внешний вид похожи. Это совпадение?
Кому интересно, можете установить и посмотреть сами:
Что ж, поджытожим.
Проекту скоро три года, а федерации до сих пор нет. А с этого вообще-то нужно было начинать.
Шифрования тоже нет. А то, которое будет — не OMEMO. И шифрования групповых чатов, похоже, не будет — в общем, без киллер-фич, всё это уже есть в других мессенджерах — да в том же XMPP.
Нет SASL. А велосипедная аутентификация состоит ровно из одного round trip'а: {login} от клиента и {ctrl} от сервера. Впихнуть сюда многоступенчатую аутентификацию вроде OAuth невозможно в принципе.
Описание протокола невнятное. Я так и не понял, каким именно {ctrl} должен ответить сервер на успешную аутентификацию. Лучше уж длинный XMPP Core, но зато чёткий, понятный и с наглядыми пошаговыми примерами. Кр. — с. т. здесь не работает.
Нет редактирования сообщений — базовая фишка всех современных мессенджеров.
- Нет транспортов, и, похоже, автор не желает их делать. Переезд с других мессенджеров будет болезненным.
Вердикт: в текущем виде не взлетит.
Пишем мессенджер с открытым исходным кодом