- комментарий 0:
From: ярик сысоев
Date: 2026-05-12 09:14:25Z
Вот бы все эти силы на создание "нового защищённого мессенджера" направили на то, чтоб у xmpp сделали клиент/сервер с нормальным интерфейсом.
(Не в смысле "правильно скругления у кнопок поставить", а чтобы даже последний хлебушек мог понять, что за ошибки возникают и как их чинить)
- комментарий 1:
From: kmeaw
Date: 2026-05-12 12:40:22Z
> чтоб у xmpp сделали клиент/сервер с нормальным интерфейсом
Prosody в качестве сервера, Gajim (Windows, GNU/Linux) и
Conversations (Android) в качестве клиентов довольно неплохо работают, в вебе
достаточно инструкций по их настройке, и даже LLM про них знают.
- комментарий 2:
From: Sergey Matveev
Date: 2026-05-12 13:29:53Z
*** kmeaw [2026-05-12 12:41]:
>Prosody в качестве сервера
Обплевался в своё время от ejabberd и нарадоваться не мог Prosody.
В итоге везде только его и поднимал. Отличная штука, действительно!
- комментарий 3:
From: Sergey Matveev
Date: 2026-05-12 13:29:53Z
*** ярик сысоев [2026-05-12 12:14]:
>Вот бы все эти силы на создание "нового защищённого мессенджера" направили на то, чтоб у xmpp сделали клиент/сервер с нормальным интерфейсом.
А у меня нет уверенности что на это стоит бросать силы. Несколько лет
назад я поднимал XMPP, чтобы вспомнить и убедиться что это также легко
как и прежде (Prosody). Так только jabber.ru мог общаться с моим
сервером: остальные же отвечали что не могут мой TLS проверить, а без
него отказываются взаимодействовать. То есть де-факто уже годы назад
Let's Encrypt, грубо говоря, решал кто может участвовать в XMPP федерации.
Виноваты конечно админы которые так настраивают свои сервера, но ничего
же не поменяется. И без поклона к США не получить сертификат который бы
из коробки у большинства бы валидировался. Для меня это равносильно
отсутствию работающей федерации, что сводит на нет толк от XMPP как
"глобального" средства общения.
Да и никогда не нравился факт использования XML (надеюсь, на практике он
хотя бы сжимается?). Для него вообще толком нет ниш пригодных, тем более
для IM-а, благо, в котором не такой большой трафик у одного человека. Но
можно закрыть глаза.
Ни один мой клиент не поддерживал OMEMO шифрование. PGP или OTR поверх
-- это да, пожалуйста. Стоит ли бросать силы на впиливание этого OMEMO в
более широкий круг реализаций? Но, судя по
9087ba08ba2bd0a2de188c2dbfdb0c9085c3d149, там тоже зоопарк реализаций и
возникающие вопросы к криптографическим решениям в этом протоколе. Всё
же его более предпочтительнее бы использовать, чем архаичный и медленный
OTRv3, либо PGP без PFS. Но лично мне не особо нравится факт его тесной
интеграции в XMPP, жёсткой заточенности под него. Ведь если сжатие
потока работает, то и Base64 закодированные сообщения будут достаточно
эффективны. Хотелось бы что-то типа OTRv4, с современными алгоритмами (и
то, уже хочется и пост-квантовые обязательно) но его забросили. Всё грустно.
Хотя в целом XMPP это наверное меньшее что вызывает негативные эмоции из
предлагаемых массовых решений, если закрыть глаза на дебильную TLS-only
федерацию настраиваемую большинством с кем сталкивался.
- комментарий 4:
From: ярик сысоев
Date: 2026-05-12 14:50:25Z
>prosody, gajim
Вот ими и пользуюсь)
Но у них то не расшифровывается текст, то между устройствами не синхронизируются сообщения, то gajim вместо закрытия ставится на фон и если его не убить, то заново окошко не откроется.
Да и если бы ставил это условно "обычный работяга", он бы забил на это всё уже давно, т.к. заставить его работать правильно явно сложнее, чем "скачать телеграм и подтвердить вход по смс"
>Хотя в целом XMPP это наверное меньшее что вызывает негативные эмоции
Ну вот именно. "Если не он, то кто?".
- комментарий 5:
From: Sergey Matveev
Date: 2026-05-12 15:14:57Z
*** ярик сысоев [2026-05-12 17:50]:
>Да и если бы ставил это условно "обычный работяга", он бы забил на это всё уже давно
Распределённые/федеративные системы априори гораздо более сложные, ещё и
с зоопарком всяких реализаций и разношёрстных версий. Обеспечить в них
такую же простоту и QoS как в централизованных -- да почти невозможно.
Поэтому, конкурировать с централизованными (если те не падают, конечно
же, каждые пять минут, имеют достаточно ресурсов и поддержки) они в
общем-то не особо могут.
Я поэтому уже давно забил на мысль/мечту о том, что можно было бы
работяг пересадить на что-то технически более безопасное, независимое и
тому подобное. Не нужно им это. Плевать хотели на шифрование. Не парит
централизованный сервер, ведь там же целые организации поддерживают их
работоспособность.
>>Хотя в целом XMPP это наверное меньшее что вызывает негативные эмоции
>Ну вот именно. "Если не он, то кто?".
Взять и написать своё! :-)
С одной стороны шучу: потому что именно так и рождаются велосипеды.
С другой: XMPP придуман явно не парой человек, я "комитетом": а это
(почти?) всегда означает переусложнённый ад, который популяризуется
только за счёт продвижения через бизнес. Вот реализовать IRC: можно
быстро, очень. XMPP -- фиг. Это как TLS и X.509 -- ну типа вот оно есть
под рукой, давайте на их основе делать защищённый канал связи. Вот и
Prosody есть под рукой -- давайте поднимем сервер и вот уже через 10мин
есть возможность связываться. Но шаг в сторону, что-то где-то не
работает, и вот уже рехнёшься лазать или в OpenSSL или XMPP из-за
немалой сложности обоих.
Matrix вот появился: с одной стороны с ним должно быть проще, знакомые
технологии, но реализаций которые бы я на практике смог дома полноценно
развернуть и они бы работали я не нашёл несколько лет назад. Всё очень
плохо. О чём только ленивый не писал в своём блоге упоминая Matrix как
глобальный IM. И я даже не знаю с кем бы мне было проще отлаживаться:
XMPP или Matrix.
Помню был PSYC проект: http://www.psyced.org/ который мне по описаниям
нравился многим, что-то даже поднимал.
Лично мне, если бы между коллегами надо бы было поднять быстренько
средство общения (не глобальное), то это был бы IRC (у меня есть goircd
демон, в котором даже конфиг не нужен), либо вообще ssh-chat
(61881ab6195819666cf747d3c7ca5a76d8aae323). Что нам дал бы XMPP?
Многострочные сообщения? Нефиг их в IM слать: для этого есть почта.
Attachment? Даже в XMPP они не тривиально передаются. Для этого есть
файловые серверы -- отправляем ссылку. Сообщения пока кто-то в offline?
Нефиг важные сообщения дискуссионные писать в IM: для этого есть почта.
Ну и журнал сообщений никто не отменял -- можно посмотреть. И я с ходу
для себя не вижу преимуществ в XMPP по сравнению с IRC: либо use-case не
для IM, либо IRC хватает.
А то что люди не возьмут и не напишут что-то адекватно годное, говорит о
том, что мало кому нужна эта задача. Кто умеет писать: ему и IRC/email/XMPP
хватает. А со своими знакомыми обычными работягами всё равно нет альтернатив
кроме как централизованных решений, либо самостоятельной поддержки
локального сервера и постоянной возни с проблемами на стороне работяг,
что не каждому захочется.
- комментарий 6:
From: kmeaw
Date: 2026-05-12 15:34:43Z
> я с ходу для себя не вижу преимуществ в XMPP
Для меня это:
- работающая федерация;
- индикатор away;
- возможность отправлять сообщения, когда пользователь оффлайн;
- синхронизация истории;
- наличие клиентов, которые могут быстро посылать (очень полезно на смартфоне)
и показывать картинки.
В IRC это реализуется костылями типа баунсеров и *Serv, в email многое есть, но
нет клиента, кроме DeltaChat, который был бы более instant - сейчас я кручу
цикл на шелле, который печатает \a, если что-то упало в Maildir/new.
Всё собираюсь посмотреть на этот DeltaChat посмотреть, но до сих пор откладываю
обновление и перенастройку dovecot, чтобы делать push.
- комментарий 7:
From: Sergey Matveev
Date: 2026-05-12 15:51:37Z
*** kmeaw [2026-05-12 15:35]:
>- работающая федерация;
*Если* она работает :-)
>В IRC это реализуется костылями типа баунсеров и *Serv, в email многое есть, но
>нет клиента, кроме DeltaChat, который был бы более instant - сейчас я кручу
>цикл на шелле, который печатает \a, если что-то упало в Maildir/new.
По моему это попытка совмещать instant и async подходы. Для меня это
не пересекающиеся задачи в реальной жизни. Требуюшие, соответственно,
разного ПО.
>- индикатор away;
В IRC же вроде можно /WHOIS или чем-то таким посмотреть в online ли
пользователь, но могу путать. Или речь про то, что для проверки этого
нужно явно сделать запрос к серверу?
>сейчас я кручу цикл на шелле, который печатает \a, если что-то упало в Maildir/new.
А что в этом плохого? По моему нормальный способ. У меня zsh занимается
проверкой изменения директории и выводит сообщение. Либо я нажимаю F1
для показа состояния новых сообщений в ящиках. Если бы визуально нужно
было оповестить через \a, то поступил бы циклом и выводом bell, точно
также.
- комментарий 8:
From: kmeaw
Date: 2026-05-12 16:06:00Z
> Для меня это не пересекающиеся задачи в реальной жизни. Требуюшие,
> соответственно, разного ПО.
Тут я согласен. Я про релазицию instant подхода в XMPP, и то с какими
трудностями придётся столкнуться, если пытаться повторить его с тем же
набором фич в email и IRC. Если начну пользоваться DeltaChat, то скорее
всего заведу для него отдельный адрес, не совпадающий с email.
> >- индикатор away;
> Или речь про то, что для проверки этого нужно явно сделать запрос к серверу?
Про user experience. В XMPP-клиентах я просто смотрю на цвет иконки.
> А что в этом плохого?
Недостаточно быстро для instant. А для async всё хорошо, да.
- комментарий 9:
From: Sergey Matveev
Date: 2026-05-12 18:25:35Z
*** kmeaw [2026-05-12 16:07]:
>Если начну пользоваться DeltaChat, то скорее
>всего заведу для него отдельный адрес, не совпадающий с email.
Это уж точно разумнее будет.
>Про user experience. В XMPP-клиентах я просто смотрю на цвет иконки.
Понял.
>Недостаточно быстро для instant. А для async всё хорошо, да.
Ну можно же хоть раз в секунду смотреть на состояние директории. Или это
тоже не достаточный instant? Ну я могу только поразиться нетерпеливости :-)
- комментарий 10:
From: kmeaw
Date: 2026-05-12 20:00:02Z
> Ну можно же хоть раз в секунду смотреть на состояние директории. Или это
> тоже не достаточный instant?
Можно, конечно. Но тогда я буду видеть этот шелл в top, что будет по какой-то
иррациональной причине напрягать меня. :)
И, опять же, вопрос user experience. Сейчас у меня интерактивный шелл на
почтовом сервере по idle уходит в этот цикл, и когда я вижу bell в tmux,
то переключаюсь в это окно, нажимаю ^C и запускаю mutt, чтобы почитать почту.
От IM, даже если он использует те же технологии и каналы доставки, я ожидаю
другого. Тут у меня первое сообщение уже валится в notification manager,
картинки сразу скачиваются и отображаются (но только от уже известных
контактов). Typing notification тоже хочется видеть, чтобы понять, стоит ли
держать окно чата в foreground в ожидании ответа, или же лучше продолжить
дальше заниматься другими делами.
- комментарий 11:
From: Sergey Matveev
Date: 2026-05-12 21:10:11Z
*** kmeaw [2026-05-12 20:01]:
>Можно, конечно. Но тогда я буду видеть этот шелл в top, что будет по какой-то
>иррациональной причине напрягать меня. :)
У меня статус в dwm использует запущенные: top, iostat, netstat, sysctl.
runit держит тьму svlogd, плюс runsv процессов. А ещё вот прямо сейчас:
stargrave 8451 0,0 0,0 12732 2256 11 I 21:43 0:00,00 tai64nlocal
stargrave 8475 0,0 0,0 12732 2164 11 I 21:43 0:00,00 tai64nlocal
stargrave 8607 0,0 0,0 12732 2256 11 I 21:43 0:00,01 tai64nlocal
stargrave 9411 0,0 0,0 12732 2164 11 I 21:43 0:00,00 tai64nlocal
stargrave 9743 0,0 0,0 12732 2204 11 I 21:43 0:00,01 tai64nlocal
stargrave 10075 0,0 0,0 12732 2204 11 I 21:43 0:00,01 tai64nlocal
stargrave 10829 0,0 0,0 12732 2164 11 I 21:43 0:00,00 tai64nlocal
stargrave 11617 0,0 0,0 12732 2204 11 I 21:43 0:00,00 tai64nlocal
stargrave 12486 0,0 0,0 12732 2204 11 I 21:43 0:00,00 tai64nlocal
stargrave 12908 0,0 0,0 12732 2204 11 I 21:43 0:00,00 tai64nlocal
stargrave 13758 0,0 0,0 12732 2260 11 I 21:43 0:00,01 tai64nlocal
stargrave 14495 0,0 0,0 12732 2204 11 I 21:43 0:00,00 tai64nlocal
stargrave 16209 0,0 0,0 13660 3172 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-cert ; done
stargrave 16589 0,0 0,0 13660 3188 11 I 20:39 0:00,01 /bin/sh -c while :; do tai64nlocal <log-dane ; done
stargrave 17093 0,0 0,0 13660 3172 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-err ; done
stargrave 17291 0,0 0,0 13660 3176 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-http-auth ; done
stargrave 17838 0,0 0,0 13660 3172 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-tls-auth ; done
stargrave 18443 0,0 0,0 13660 3176 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-non-ok ; done
stargrave 19231 0,0 0,0 13660 3172 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-ok ; done
stargrave 19838 0,0 0,0 13660 3176 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-redir ; done
stargrave 20156 0,0 0,0 13660 3176 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-req ; done
stargrave 20384 0,0 0,0 13660 3164 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-tls ; done
stargrave 20843 0,0 0,0 13660 3180 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-various ; done
stargrave 21626 0,0 0,0 13660 3172 11 I 20:39 0:00,00 /bin/sh -c while :; do tai64nlocal <log-warc ; done
Красоты нет, но... да и фиг со всем этим :-)
>И, опять же, вопрос user experience. [...]
Поэтому я и говорю что нужны совсем разные программы для async и IM задач.
Хотя в целом то и оповещение о почте тоже же можно прокинуть с сервера
чтобы локальный notification появился.
>Typing notification тоже хочется видеть, чтобы понять, стоит ли
>держать окно чата в foreground в ожидании ответа
Ох, как я тут не согласен с этим желанием и вообще технологией. Просто
не перевариваю. По моему самое правильное это научиться корректно
общаться: явно давать собеседнику понять что вопрос решён,
вопросов/ответов больше нет (хотя бы написать "вот"), и всё в таком
духе. Культура общения. В фильмах мы сколько раз видели "приём! приём!",
"конец связи", "жду ответа" и всё в таком духе (в фильмах -- потому что
вряд ли много кто в реальности общался по рации, как мне кажется).
Да, я понимаю что всех (пере)воспитать не выйдет, но я считаю что ещё
хуже это придумывать технические решения для проблем связанных с
отсутствием культуры общения. Про это я уже писал в
https://habr.com/ru/articles/845172/ ("Давайте эффективно электронно
общаться на работе") и считаю что нефиг сюсюкаться и идти на поводу у
некультурных (или не проявляющих уважения к чужому времени) людей.
Если человек явно не дал, в течении адекватного времени, сигнала о том
что от него ещё что-то будет, то значит с чистой совестью можно идти по
своим делам от чата. Человек сам не знает может ли он что ещё написать?
Значит ему надо было валить в async режим (email).
Ну и ещё сам факт того, что куча JSON/XML/whatever гоняется по сети
просто чтобы показать что кто-то нажимает на кнопочки... меня угнетает и
мне жалко каналы передачи данных :-)
А то до чего так можно дальше было бы дойти? До отправки голосовых
сообщений чтобы не набирать? Oh shit, они уже здесь :-) (инвалидам --
исключение). А потом для удобства написать transcribing этих сообщений в
текст назад? Oh shit! А потом мы удивляемся почему все программы везде
тормозят, каналов связи не хватает, электричества/аккумуляторов всё на
свете жрёт как не в себя, RAM везде мало, и простейшие бытовые или
рабочие вопросы по самым разнообразным каналам связи не можем решить за
адекватное время, потому что люди не могут внятно задать вопрос/ответ. Я
убеждён что все упирается в сетикет, культуру, воспитанность. Я бы даже
сказал о нежелании думать: массы привыкли получать всё "здесь и сейчас",
и подумать хотя бы 5-10сек над вопросом/ответом, просто представив себя
на месте получателя.
Но это всё наверное просто продолжение темы Вечного Сентября:
https://ru.wikipedia.org/wiki/Вечный_сентябрь
У грамотных, воспитанных людей и с email, и с IRC, и с whatever нет
проблем с эффективным общением на практике. А у многих других они будут
везде, в любом IM, с любыми средствами ввода/вывода :-)