LINUX.ORG.RU

Каковы практические проблемы Jabber?

 ,


1

4

У меня два вопроса.

1) Каковы практические проблемы использования XMPP, кроме малой популярности?

В дискуссиях об XMPP можно услышать общие доводы как то «множество неинтероперабельных реализаций», «фрагментированная поддержка возможностей», «протокол из частей». Нередко звучат и ложные заявления о якобы преимуществе JSON над XML, которые, что важно, малорелевантны практическому использованию Jabber.

Примером практической проблемы могло бы быть, например, «в популярном сервере jabber silently пропадают сообщения, но остальные серверы еще хуже», «частичная поддержка unicode, например буква ё не поддерживается», «нет ни одного клиента для Windows».

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


Второй вопрос.

2) «Пуш-уведомления», насколько я понимаю, работают через вендора ОС. То есть чтобы отправить пуш-уведомление в андройд аппарат, нужно обратиться к серверам Гугула (или посредников). Получается, что self-hosted jabber серверу придется обращаться к гуглу, чтобы отправить в мобильный клиент пуш-уведомление. В jabber серверах на практике это реализовано? Сколько за это нужно платить?

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


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

Ну, с передачей файлов, вроде, всё срослось сейчас.

Вот именно что «вроде», нет 100% гарантии что с 2 сторон все срастется у пользователей

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

А что, открыть ссылку на второй стороне (любым способом) уже является проблемой? Иначе при чем тут «2 стороны»?

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

Да всё это либо есть, либо не так чтоб сильно нужно (если не превращать чат в IDE). Проблема в том, что чтобы всё работало, нужен современный клиент и современный, правильно настроенный сервер. В случае, когда vasja@example.org хочет поговорить с petja@example.net у нас есть 4 (четыре) разные сущности, сбой в каждой из которых приводит к нытью «опять ваш джаббер не работает».

К сожалению гибкость и обилие возможностей приводит к обилию способов что-то сделать неправильно. Тут только административными методами решать.

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

2 стороны - это 2 клиента (точнее связка клиент+ сервер), файлы не всегда проходят, но самое раздражающее что у получателя (да и у отправителя) может даже ошибки не высветится, что что-то пошло не так и нужно переспрашивать дошел ли файл. Это при условии поддержки http upload, конечно.
Вот в этом и проблема что оно должно работать но на практике непонятно и такие мелочи действительно раздражают.

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

Есть решения работающие децентрализованно без серверов с прямым P2P соединением между конечными клиентскими устройствами. С поддержкой клиентов *nix, android, apple, windows. Поддержка, чата, голосовых и видео звонков, групповых чатов и конференций прочие..

tox что-ли? ну да он работает, причем и файлы и звонки были норм (давно не использовал его).
Тотальный недостаток - он жрет очень много трафика в пустую, на десктопе приемлимо, но вот мобильный интернет страдает. Ну и push (которые многие хотят) на децентрализованной платформе реализовать енвозможно скорее всего.
Ах да, еще адовые логины в виде хешей (tox dns вроде не взлетел), причем в конце есть динамическая часть (защита от спама), которая может изменяться и опубликовал ты где-то свой хеш, потом перегенерировал «защитную» часть и надо по новой публиковать.

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

Ну, HTTP Upload вроде как, везде работает. Геморрой может быть с самоподписанными сертами (у той-же Psi наблюдал, но де-факто она мертва).

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

Ну, делают некоторые. Да до сих пор половина манов в сети - генерируем серты сами. Остальная половина на Let’s Encrypt-е.

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

tox что-ли?

Tox пойдет, но я имел ввиду другой, их много сегодня разных p2p чатов-звонилок.

У него имеются полнофункциональные клиенты для всех платформ. Есть возможность переноса экаунта между своими устройствами с синхронизацией чатов. Логины сразу читабельные. Реализованы пуш уведомления в p2p системе. Разрабатывается GNU с благословения FSF, освящён RMS…

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

Разрабатывается GNU с благословения FSF, освящён RMS…

GNUNet? Оно разве под мобильные платформы есть?

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

Удали, эти ссылки, а то в РКН сдадут и заблокируют… Кому надо сам найдет.

А так из-за ковида этих p2p видеочатов куча развелось. А вот до дистрибутивов пока они не дошли.

anonymous
()
Ответ на: комментарий от MagicMirror

Самоподписанные серты? Это где такие мамонты остались?

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

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

Предложите схему как это могло бы работать.

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

Для автоматизированного подтверждения подлинности перед неопределённым кругом лиц. Нет нельзя.

Пусть например продаю мной разработанные программы.
Тем кто заплатил деньги при инсталяции программы передаю на свой сервер некоторые данные, которые идентифицируют компьютер владельца
программы и при её запуске проверяю имеет ли право владелец её использовать.
Алгоритма, создающего сертификат никто не знает, а потому и не сломает.
В этом случае услуги сертификационного сервера мне не нужны.

anonymous
()

Пуши для этих самых не нужны. /thread.

lx1
()
Ответ на: комментарий от anonymous

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

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

Можно. Но тогда КАЖДЫЙ участник такой сети должен САМ исполнять функции удостоверяющего центра. Пример OpenPGP. Децентрализованное подписание ключей самими участниками сети.

Да OpenPGP работает, но надо годы. Советую создать себе ключ PGP и подписать им ключи одноклассников, однокурсников, сотрудников на работе. Пройдут годы и у вас заработает децентрализованная идентификация подлинности ключей.

Примеры схем доверия между ключами: https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs

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

Пройдут годы и у вас заработает децентрализованная идентификация подлинности ключей.

Многим фирмам достаточно подтверждения того, что программа используется лицензионно.
Собственно об этом пост был, а не о решении задачи сертификации использования данных, …

anonymous
()
Ответ на: комментарий от Darth_Revan

Прошу прощения за глупые, может быть, вопросы. Плохо разбираюсь в сетевых тонкостях, увы. Но тем не менее.

  1. Значит, в зоне блокировки подключиться к XMPP уже невозможно или эффект должен быть другим? Открываю сейчас Conversations, там пару аккаунтов на данный момент онлайн без каких-либо ухищрений. Новые сообщения в случайной конференции вижу.

  2. Если проблемы с портом возникнут, как рядовому владельцу джентльменского набора (мобильный, настольный клиент) это исправить? Желательно малой кровью, потому что не все, например, из моих собеседников могут или хотят заморачиваться с обходами. Хотя бы в общих чертах понять последовательность действий.

  3. Имеется ли у РКН техническая возможность заблокировать XMPP в принципе? Допустим, публичные серверы забанены, кто-нибудь поднимает личный для себя и друзей, но в ответ режется сам XMPP-трафик. Если да, тут уже не будет шансов просто задурить этот перехват?

Спасибо!

anonymous
()

1) XML несёт большой оверхед

2) Проблемы с серверной историей (а она must have, если >1 устройства) - её умеют не все сервера и не все клиенты

3) Проблемы с передачей файлов

4) Иногда через одно место работает инициирование диалога с собеседником, с кем раньше никогда не общался (запрос авторизации не приходит и т д)

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

KivApple ★★★★★
()
Ответ на: комментарий от KivApple
  1. Проблемы с передачей файлов

Код, реализуюший функционирование протокола не умеет?

anonymous
()
Ответ на: комментарий от KivApple

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

Потому что обычно у Conversations видел расход порядка 1% относительно всего остального. Подключение постоянное.

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

Значит, в зоне блокировки подключиться к XMPP уже невозможно или эффект должен быть другим?

Возможно. Потому что XMPP может подпадать под заблокированное условие, но не обязан.
Практически любой XMPP-сервер предоставляет не-TLS подключение со STARTTLS на порту 5222 (потому что это стандартно). Оно не подпадает.
А ещё часто XMPP C2S делают на порту 443 для огороженных сетей. На этом порту TLS не заблокируют никогда.

Если проблемы с портом возникнут, как рядовому владельцу джентльменского набора (мобильный, настольный клиент) это исправить?

Ну, просто говоря, убедиться, что не используется порт 5223. Если сервер даёт порт 443, то вообще замечательно.

Имеется ли у РКН техническая возможность заблокировать XMPP в принципе?

STARTTLS заблокировать очень просто, он с самых первых пакетов кричит, что он XMPP.
На прямом TLS XMPP выдаёт себя через ALPN. Но не всегда, ALPN не то чтобы обязательный.
Но XMPP может работать ещё и через WebSockets и HTTP Long Polling (BOSH), а это буквально HTTPS, который не заблокировать. Но поддержка клиентов ограничена, конечно.

Но тут есть вот какой момент: если заблокировать XMPP, можно невзначай заблокировать какой-нибудь технический сервис типа пуш-уведомлений. Но, может, их это уже не остановит.

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

а при межсерверном обмене у xmpp как выбирается протокол? там plain xmpp, plain+STARTTLS и TLS все на одном порту?

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

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

А вот что заблокировано, так это TLS-соединения на всех портах, кроме определённых нескольких (на 443 и на 8443 проходит).

я полагаю, такие суровые блокировки применяются только для трансграничных соединений к определенным серверам.
Иначе бы imaps/smtps на 993/465 не ходил.

MirandaUser2
()
Ответ на: комментарий от EXL

Отсутствие нормальной синхронизации истории и файлов на всех клиентах из-за децентрализации.

Это не из-за децентрализации, а из-за слабой поддержки соотв. XEP`ов на серверах/клиентах.
Е-mail тоже не централизован (т.е. федеративен), однако история доступна с любого клиента.

MirandaUser2
()
Ответ на: комментарий от jxpnw

а при межсерверном обмене у xmpp как выбирается протокол? там plain xmpp, plain+STARTTLS и TLS все на одном порту?

Так же. STARTTLS – это TLS на том же порту, что и plain.
Но про фактическое использование прямого TLS для S2S я не слышал. Какой вообще порт тогда должен быть (без SRV)? 5270?

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

я полагаю, такие суровые блокировки применяются только для трансграничных соединений к определенным серверам. Иначе бы imaps/smtps на 993/465 не ходил.

Пошёл проверять и заметил, что блокировки больше нет 🤷.
Куда делась – непонятно.

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

Возьмём например этот список:
https://jabber.at/clients/?os=any
Поддержка xep-0313 примерно в трети клиентов.
На мой взгляд преимущество XMPP в большом количестве клиентов: графические, консольные, мультипротокольные etc.
В данном случае это преимущество теряется, т.к. приходится выбирать из существенно более ограниченного набора.

Даже c xep-0313 все не просто: у сообщений как правило нет уникальных id (их вводит xep-0359) и даже timestamp`а нет, поэтому дедупликация осложнена.
См. https://docs.modernxmpp.org/client/protocol/#known-issues
(хотя я не очень понимаю, почему сообщения отправленные через carbons не попадают в архив)

Т.е клиенту нужно корректно мержить
- обычные сообщения (входящие и исходящие; без таймстемпа в протоколе)
- delayed сообщения (XEP-0297: Stanza Forwarding, XEP-0203: Delayed Delivery, XEP-0091: Legacy Delayed Delivery)
- архив (MAM)
- локальный архив (обычно таковой тоже есть)

По моим экспериментам в основном клиенты с этой задачей не справляются и даже простые delayed сообщения некорректно обрабатывают.
Более менее рабочее - это исторические сообщения в MUC (хотя там такие же таймстемпы как xep-91/203).

Для сравнения в других современных IM (тот же matrix) клиент просто циклично подтягивает с сервера последние страницы истории (с таймстемпами и уникальными id; туда же попадают outgoing). И всё.
Матриксовый протокол интересен отсутствием характерных для XMPP проблем. Но тут уже в другом проблема - клиентов относительно мало. :-(

MirandaUser2
()

Кто хорошо знаком с серверами jabber, а как там организована защита от подмены сервера? У smtp есть spf/dkim записи и проверка ptr, а что у xmpp?

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

В данном случае это преимущество теряется, т.к. приходится выбирать из существенно более ограниченного набора.

Выбирать из Gajim-а и Dino + MirandaNG на оффтопике. Консервы и её форков на Андроиде и ничего приличного на Mac. Ну и web-based converse.js. Всё.

Остальное или сдохло или в шибко зачаточном состоянии (и уже сдохло, как правило) или просто не держит современные протоколы (читай, как сдохло).

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

Вот представьте себе, что кто-то принялся критиковать линукс, используя аргументы: „Это какое-то говно! Там ничего не работает!“. А после дальнейших распросов выясняется, что «ничего не работает» означает — «ввод рандомных команд из советов со StackOverflow не помогает решать проблемы». А не помогают они потому, что в качестве линукса выступает Debian/kFreeBSD, не обновляемый с 2016-го года.

Согласимся ли мы с тезисом «линукс — говно» после столь блистательного примера? Наверное нет. Однако именно с такой критикой мы повсеместно встречаемся при обсуждении джаббера. Некто может использовать tkabber, разработка коего прекращена 10 лет назад. Базовые возможности более-менее будут работать. Но про новые расширения протокола конечно придётся забыть и здравствуй «Это какое-то говно! Там ничего не работает!».

Обилие клиентов на всякий вкус это конечно хорошо, но эта фрагментация и хоронит джаббер. Потому он находится в суперпозиции меж двух вариантов:

  • Ничего не работает. Одно сплошное страдание и конца и края не видно.
  • Прорывная технология, позволяющая человеку в одиночку на пятибаксовом сервере построить свой собственный ватсап/телеграмм.

При этом чем более мы административными методами подавляем фрагментацию, тем ближе ко второму варианту. В идеале: корпоративный сервер (совместимый сам с собой) со списком рекомендованных клиентов (совместимых с сервером). Тогда всё будет отлично работать.

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

Вот представьте себе, что кто-то принялся критиковать линукс, используя аргументы: „Это какое-то говно!

Разве только Linux?
Это повсеместная традиция такая …

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

К примеру на этом форуме всех без исключения форумчан ругают.

anonymous
()
Ответ на: комментарий от Darth_Revan

Но про фактическое использование прямого TLS для S2S я не слышал.

На самом деле - активно используется.

journalctl -u ejabberd.service | awk '/:5269/{stls+=1}; /:5270/{dtls+=1} END {print "STARTTLS: ", stls; print "Direct TLS: ", dtls}'
STARTTLS:  7953
Direct TLS:  3538


Какой вообще порт тогда должен быть (без SRV)? 5270?

Без SRV - никакого, как и для c2s (разве что ты влепишь Direct TLS на 5269, потенциально ломая совместимость с чем-нибудь).

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

Однако именно с такой критикой мы повсеместно встречаемся при обсуждении джаббера

Да что джаббер, мы повсеместно встречаемся с такой критикой при обсуждении линукса!

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

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

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

чем более мы административными методами подавляем фрагментацию, тем ближе ко второму варианту. В идеале: корпоративный сервер (совместимый сам с собой) со списком рекомендованных клиентов (совместимых с сервером). Тогда всё будет отлично работать.

будет отлично работать и не будет отличаться от популярных централизованных мессенджеров. Для пользователя это будет выглядеть как «работает не хуже, чем what-who-IM, даже без рекламы, только народу никого»

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

У меня так на одном IP висят 2 ежа и 1 Prosody :)

YAR ★★★★★
()
  1. Каковы практические проблемы использования XMPP, кроме малой популярности?

XMPP — технология, а не продукт и не сервис. Сравнения с другими мессенджерами поэтому некорректны, реализация XMPP даже не обязана быть мессенджером.

Серверы, клиенты, расширения протокола существуют в немалом количестве - готовых решений не так много, не спрашивая поисковики могу вспомнить только Cisco Jabber.

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

У почты недостаточно, потому и появились костыли для проверки что письмо пришло от сервера который имеет право отправлять письма от указанного (в письме) домена.

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

В нише корпоративного сервера «конкурентом» будет не whatsapp, а mattermost.

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

Почтовый протокол состоит из наслоений костылей, обратно совместимых на 50 лет назад. В XMPP таких требований просто нет. Я, честно, не вижу зачем в схеме:

  • запись SRV указывает, что за адрес user@example.org отвечает сервер xmpp.example.org
  • сертификат TLS должен соответствовать xmpp.example.org

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

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

Ну вот я сейчас смотрю конфиги ejabberd и prosidy, очень похоже на то что надо для каждого домена использовать валидные tls сертификаты, тогда проблем не будет. А если tls нет то пока непонятно, может действительно srv записей хватает (хотя они немного для другого нужны)

Kolins ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)