LINUX.ORG.RU
ФорумTalks

Убийца XMPP по имени Matrix — никто не пробовал?

 , , ,


3

1

$subj. Имеем очень интересный IM по имени matrix (https://matrix.org), который я бы описал как «взяли концепции электронной почты и без изменений перенесли в IM». Есть т. н. homeserver'ы (== «почтовые серверы»), на которых хранится история; есть клиенты, которые к ним подключаются.

«Комнаты» могут быть раскиданы по нескольким серверам. Есть адекватная синхронизация истории, есть адекватный мультилогин. Ах да, это всё немного похоже на Git: ведётся обмен не сообщениями, а состоянием и историей.

Есть референсный homeserver с веб-клиентом (synapse), есть клиенты для iOS и Android. Деплоить они его предлагают через б-гомерзкий virtualenv, но я опакетил под арч.

Anyone interested? Или, может быть, кто-то уже юзает?

UPD: join us at #lor:matrix.org.

★★★★★

Последнее исправление: intelfx (всего исправлений: 3)

Ответ на: комментарий от intelfx

Да. Эталонное. Сферическое. Особенно сообщения из конференций/групповых чатов. У меня нет слов, чтобы передать, насколько это отвратительно.

leave ★★★★★
()
Ответ на: комментарий от leave

А если потушить реактивный двигатель на баттхёртной тяге и попытаться говорить по существу? :]

intelfx ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

У скайпа клиенты говёные. С распространением мобилок переходят на всякие телеграмы, потому что пользоваться там скайпом слишком мучительно даже для домохозяйки.

vurdalak ★★★★★
()
Ответ на: комментарий от leave

Да вы батенька упороты! Это как раз то за что современные IM и в почете. Сервер никогда не будет знать какой клиент приоритетен и активен (реально, а не декларативно). Если мне присылают сообщение, я его читаю с того устройства, где мне удобно здесь и сейчас, а не с того, куда сервер соизволил прислать.

Lordwind ★★★★★
()

фраза «try matrix nowl» в стиле opensource, да

swwwfactory ★★
()
Ответ на: комментарий от dormeur86

вайбер

где нельзя отключать уведомления для выборочных чатов или контактов - гениально блджад, или читай хронику всех чятиков или пропускай нужные приваты... еще один IM от мудаков в догонку к вацапу

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

Щемта приоритеты нормальные клиенты умеют автоматически повышать. А вот когда тебе лог релизного чата (с полмегабайта) в скайп на телефон прилетает - хочется медленно и страшно убивать человека, придумавшего эту ересь.

leave ★★★★★
()

Как и все остальное, будет интересно парочке гиков, а общаться реально будет не с кем. Так что не нужно.

Ghostwolf ★★★★★
()
Ответ на: комментарий от leave

в скайп на телефон прилетает - хочется медленно и страшно убивать человека, придумавшего эту ересь

знаю такое, у меня когда-то ойфон при запуске скайпа залипал минут на 10-15, пока все чаты не просрутся, но на то я и написал фразу «современные IM»

а во вторых приоритеты принципиально ничего не решают, например мне написали ссылку на рабочий проект, а получил я ее на мобилу, мне нужно зайти с компа по ссылке - упс, а на компе ссылки нету, сервер ее прислал на мобилу... наоборот еще интереснее выходит, особенно когда ссылки бородатые или файлы нестандартные

Lordwind ★★★★★
()
Ответ на: комментарий от mono

Нафига это всё, если есть вот-цап?

Ты хотел сказать telegram? Воцап без десктопного клиента не нужен.

xtraeft ★★☆☆
()
Ответ на: комментарий от vurdalak

XMPP — это просто передача сообщений. А здесь речь о синхронизации состояния и истории. Что-то гитоподобное.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от vurdalak

«Не подходит для веба» означает, что XMPP на клиенте заимплементить сложнее, чем Matrix (который построен на HTTP и JSON).

intelfx ★★★★★
() автор топика
Ответ на: комментарий от leave

А держать CA и сертификаты пусть лично тот-кого-нельзя-называть будет подписывать :)

Harald ★★★★★
()
Ответ на: комментарий от DeadEye

Я считаю, что оно нужно и полезно за счёт того, что там другая базовая идея (гитоподобный обмен состоянием). Этим оно отличается от XMPP в корне. Остальное допиливается. Шифрование (end-to-end) уже делают. А ограниченность юзербазы — ну и что, все с этого начинали.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от leave

и будет он сидеть в бункере на острове и наблюдать на большом экране карту мира и светящиеся точки, показывающие запущенные инстансы системдэ. И прибивать по желанию левой задней пятки неугодные :)

Harald ★★★★★
()
Ответ на: комментарий от vurdalak

Из того, что я понял, разница сугубо количественная. HTTP и JSON уже есть. Примитивы обмена данными уже есть.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от vurdalak

Возможно, там есть какие-то более сложные причины. В худшем случае этот аргумент невалиден; что насчёт остальных?

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Single server per MUC is a single point of control and availability

Есть XEP для разбития конфы на несколько серверов.

History synchronisation is very much a second class citizen feature

Вот это хз, я не помню, был ли XEP на это.

Stanzas aren’t framed or reliably delivered (without extensions)

Не очень понял, что имеется в виду и где это выражается для юзверя.

Multiple device support is limited

Не сказано, что под этим понимается.

Baseline feature set is so minimal that good user experience cannot be guaranteed

А кто гарантирует, что разрабы клиентов матрикса будут всё реализовывать?

No strong identity system

А это что значит?

Not particularly well designed for mobile use cases (push; bandwidth-efficient transports)

И что там неэффективно? Только не надо рассказывать про многослоность XML: 99% клиентов умеют в gzip.

vurdalak ★★★★★
()
Ответ на: комментарий от intelfx

Была на xkcd картинка про стандарты и их введение. Полностью подходит к твоей ситуаии, только ну с ооооочень мелким количеством юзеров.

DeadEye ★★★★★
()
Ответ на: комментарий от Spoofing

Банер не плохой, аля 98-ые) Но зачем ты про бложек, в каждом треде твердишь?

daniilArch ★★
()
Ответ на: комментарий от vurdalak

History synchronisation is very much a second class citizen feature

Вот это хз, я не помню, был ли XEP на это.

Даже если был — это должно быть в ядре протокола, причём так, чтобы это нельзя было проигнорировать. А не сбоку на скотч примотано.

Stanzas aren’t framed or reliably delivered (without extensions)

Не очень понял, что имеется в виду и где это выражается для юзверя.

Часть сообщений может дропнуться, если соединение плохое, и никто об этом не узнает. Это, кстати, одна из причин моей лютой нелюбви к джабберу.

Multiple device support is limited

Не сказано, что под этим понимается.

Это FAQ (краткое описание происходящего), а не спор. Предполагается, что читатель осведомлён о ситуации. Так или иначе, речь о том, что концепция приоритетов ущербна. Всё должно приходить всем.

Baseline feature set is so minimal that good user experience cannot be guaranteed
А кто гарантирует, что разрабы клиентов матрикса будут всё реализовывать?

Если я понимаю правильно, то там протокол так сделан, что проигнорировать базовые фичи типа синхронизации истории нельзя. Более того, всю сложную работу делает homeserver, а клиент достаточно просто устроен.

Как сейчас в конференции сказал один из их разрабов: «the difference is where you draw the baseline, and what you put in it».

No strong identity system

А это что значит?

Нет централизованной идентификации. В matrix есть возможность привязать свой ID к чему-то общеизвестному типа номера телефона или почтового адреса (NB: возможность, а не необходимость). Называется «identity server».

Not particularly well designed for mobile use cases (push; bandwidth-efficient transports)

И что там неэффективно? Только не надо рассказывать про многослоность XML: 99% клиентов умеют в gzip.

Всё равно половина данных — изменения статуса. Ну и речь не только про bandwidth efficiency, а ещё про уведомления. Матрикс в них умеет, причём убергибко.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

УМНР.

Это у вас, любителей системг, всегда так. Не осилили , и давай писать свой велосипед. Оторвали одну из самых классных штук в XMPP и выдаёте это за преимущество. У меня сообщения при одинаковом приоритете приходят в оба клиента сразу. И я что-то не припоминаю, чтобы это когда-то где-то не работало.

Black_Shadow ★★★★★
()
Последнее исправление: Black_Shadow (всего исправлений: 1)
Ответ на: комментарий от DeadEye

Это нерешаемая проблема (а, стало быть, и не проблема вовсе: просто мир так устроен).

Любой новый стандарт проходит тот этап, когда он всего лишь один из пятнадцати конкурирующих.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от Black_Shadow

Я указал равные приоритеты и получил хрен. Вывод — или сервер говно, или клиенты говно. И в любом случае XMPP говно, потому что он такой вариант вообще допускает.

С другой стороны, сабж так спроектирован, что в нём подобный факап в принципе невозможен (читать ОП про гитоподобность).

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Просто при имеющихся 14 15-ый велосипед не нужен. Только и всего.

DeadEye ★★★★★
()
Ответ на: комментарий от intelfx

Даже если был — это должно быть в ядре протокола, причём так, чтобы это нельзя было проигнорировать. А не сбоку на скотч примотано.

Кому должно? Если у разработчика 2 часа свободного времени, и запиливание всех расширений требует 10 часов, то лучше пусть он запилит базовую часть, чем вообще ничего. Из этого и исходил XMPP.

Часть сообщений может дропнуться, если соединение плохое, и никто об этом не узнает.

Есть подтверждение доставки.

Это FAQ (краткое описание происходящего), а не спор. Предполагается, что читатель осведомлён о ситуации. Так или иначе, речь о том, что концепция приоритетов ущербна. Всё должно приходить всем.

Это субъективизм. Мне вот не надо, чтобы всё приходило всем, мне надо только туда где я нахожусь. Т.е. туда где приоритет выше.

Если я понимаю правильно, то там протокол так сделан, что проигнорировать базовые фичи типа синхронизации истории нельзя.

Тогда просто никто не будет его реализовывать, так как разработчикам нафиг не сдалось тратить месяцы на всё что они запихнули в протокол.

Нет централизованной идентификации.

А JID это что тогда? Централизованный айди, уникальный в природе.

Всё равно половина данных — изменения статуса.

Ну а как ты предлагаешь уведомлять об этих изменения?

уведомления

На самом деле мобильные жаббер-клиенты многие их тоже умеют. И даже хз, как это можно запихнуть в протокол, учитывая что например ведроидовские пуши работают только через гуглосервер и никак иначе (в этом суть их реализации, один клиент на весь телефон и одно соединение вместо отдельных в каждой софтине).

vurdalak ★★★★★
()
Ответ на: комментарий от intelfx

Небось еще и ресурсы одинаковые. Все твои посты - одна большая история успеха под названием «Как я ниасилил Jabber».

DeadEye ★★★★★
()
Ответ на: комментарий от intelfx

Я указал равные приоритеты и получил хрен.

Я не знаю, что ты где указал, и за твои кривые руки отвечать не могу. Факт остаётся фактом - ты не смог сделать то, что у меня работало всегда. То есть, мне даже в голову не могло прийти, что это может не заработать.

Вывод — или сервер говно, или клиенты говно.

Вывод здесь совсем другой, и если я его озвучу, ты обидишься.

И в любом случае XMPP говно, потому что он такой вариант вообще допускает.

Он его допускает, потому что он многим нужен. Это фишка.

С другой стороны, сабж так спроектирован, что в нём подобный факап в принципе невозможен (читать ОП про гитоподобность).

Назначать приоритеты нельзя? Ну тогда твой Matrix - полное говно.

Black_Shadow ★★★★★
()
Последнее исправление: Black_Shadow (всего исправлений: 1)
Ответ на: комментарий от DeadEye

Имена ресурсов дефолтные (т. е. разные). И нет, настройка IM не должна быть rocket science. Протокол не должен быть таким, чтобы в нём можно было за три секунды отстрелить себе яйца.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от Black_Shadow

Назначать приоритеты нельзя? Ну тогда твой Matrix - полное говно.

Нет, ты. «Всё есть у всех» — это фича. А если тебе нужно обратное, берёшь и отключаешь уведомления.

intelfx ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.