LINUX.ORG.RU

Gitter становится частью сети Matrix

 , , ,


2

3

Компания Element приобретает Gitter у GitLab, чтобы адаптировать сервис для работы в условиях федеративной сети Matrix. Это первый крупный мессенджер, который планируется прозрачно перенести в децентрализованную сеть вместе со всеми пользователями и историей сообщений.

Gitter является свободным централизованным средством для групповой коммуникации между разработчиками. Помимо типовой функциональности командного чата, по сути своей схожей с несвободным Slack, Gitter также предоставляет инструменты для тесной интеграции с платформами совместной разработки, вроде GitLab и GitHub. В прошлом сервис был проприетарным, пока его не приобрела компания GitLab.

Matrix же представляет собой свободный протокол для реализации федеративной сети, построенной на основе ациклического графа событий (DAG). Основной реализацией этой сети является мессенджер с поддержкой сквозного шифрования и VoIP (аудио- и видеозвонков, групповых конференций). Эталонные реализации клиентов и серверов разрабатываются коммерческой компанией Element, сотрудники которой также возглавляют некоммерческую организацию Matrix.org Foundation, курирующую разработку спецификации протокола Matrix.

На данный момент пользователи Gitter и Matrix общаются с помощью «моста» matrix-appservice-gitter, релея для пересылки сообщений между ними. При отправке сообщения, например, из Gitter в чат с подключённой интеграцией в Matrix, «мост» создаёт виртуального пользователя для отправителя из Gitter на сервере Matrix, от имени которого и доставляется сообщение в чат со стороны Matrix, и наоборот соответственно. Подключение такой интеграции возможно прямо из настроек чата со стороны Matrix, но этот способ коммуникации будет помечен устаревшим.

В краткосрочной перспективе пользователи не заметят никаких видимых изменений: они смогут пользоваться мессенджером так же, как и до покупки. В дальнейшем процесс трансформации из централизованного сервиса в децентрализованный субъект федерации будет совершён благодаря организации нового сервера Matrix и интеграции «моста», по аналогии с matrix-appservice-gitter, прямо в кодовую базу Gitter. Существующие чаты в Gitter будут доступны как Matrix-комнаты, вроде «#angular_angular:gitter.im», с импортированной историей сообщений.

После успешной интеграции пользователи обеих сетей получат свою выгоду: пользователи Matrix смогут прозрачно общаться с пользователями Gitter, а пользователи Gitter смогут использовать клиенты Matrix, например, мобильные, так как разработка официальных приложений Gitter была прекращена. В конечном итоге можно будет считать, что Gitter станет одним из клиентов сети Matrix. Но, к сожалению, Gitter значительно уступает по возможностям, чем эталонный клиент Matrix — Element, поэтому вместо доведения Gitter до паритета в функциональности с Element, было решено реализовать все недостающие возможности из Gitter в Element. В долгосрочной перспективе Gitter будет заменён на Element.

Из полезных особенностей Gitter, которые могут адаптировать для Element:

  • Высокая производительность при просмотре чатов со значительным количеством пользователей и сообщений;
  • Тесная интеграция с платформами совместной разработки, вроде GitLab и GitHub;
  • Иерархический каталог чатов;
  • Дружелюбный к поисковым системам статический вид публичных чатов;
  • Поддержка разметки в KaTeX;
  • Древовидное ветвление сообщений (threads).

Компания Element обещает, что фронтенд Gitter будет заменён на Element только в том случае, когда Element достигнет паритета в функциональности. До тех пор кодовая база Gitter будет поддерживаться в актуальном состоянии без регрессий в функциональности.

Сотрудники Gitter будут также трудиться и на пользу Element.

>>> Подробности

★★★★★

Проверено: alpha ()

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

Для TCP они недоступны.

Почему это недоступны? o_O Сокет открываете — и вперёд.

Какой сокет?

Обычный AF_INET, man 2 socket.

Это IPv4-семейство протоколов. А тип-то какой?

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

Это не оправдание.

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

Шматрице уже 6 лет, а она до сих пор не готова.

«Не готово» - понятие субъективное. Я наоборот считаю, что готов. Для замены XMPP-конференций/IRC - вполне. Про замену типичных мессенджеров - не уверен. Но к этому всё и идёт.

Может, лучше было всё же на причёсывание XEP-ов время потратить?

И потратить драгоценное время, пока какой-нибудь Slack захватывает рынок. А то и потерять шанс на получение гранта и дальнейшее развитие. А зачем? Чтобы угодить какому-то анонимусу с ЛОРа. Почитайте что такое MVP ещё раз и не несите околесицу. С вами как со стенкой разговаривать.

Лучше просто нанять грамотного архитектора на полученные гранты, чтобы вредрять фичи слоями, как команда Дурова. А когда придёт время (время 2.0), недочёты исправят.

И форкнуть готовый клиент, как это сделали, например, для вышеупомянутого Я.Онлайн, у которого десктопный клиент основан на Psi+?

Не знаю никакого Я.Онлайн. Это вы про XMPP от Яндекса? Он давно уже всё и окончательно. И как бы это не было иронично, но они вместо него сделали Яндекс.Мессенджер и без всякого XMPP.

А глюки? — какие глюки? Гаджим во времена 0.1x железобетонным был

Ну как я и предполагал, весь ваш опыт стабильности клиентов основывается на одном уютненьком клиенте. А то, что существовали Empathy, Pidgin, Kopete, Psi+… а, это вы просто «не тем» пользовались. А вот Gajim вот, вот он…

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

А вы им заплатили

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

Я наоборот считаю, что готов

Где ж готов, когда клиентов нет?

Но к этому всё и идёт.

Ну-ну, попробуйте пересадить пользователей с няшной шустрой проприетарщины типа Telegram/Viber на тормозную электроноподелку :P Скайп так уже пользователей растерял. (Кажется, Мы уже писали об этом в этом треде, нет?)

пока какой-нибудь Slack захватывает рынок

Slack нишевый и в его нише конкурентов навалом и без шматрицы.

Почитайте что такое MVP

Не многовато ли 6 лет для MVP? И тут ещё @metaprog умудряются ругать, что долго пилят в одно рыло, мда.

нанять грамотного архитектора

Это надо было в начале делать, сейчас уже поздно.

но они вместо него сделали Яндекс.Мессенджер и без всякого XMPP

О чём и речь, тенденция закапывания XMPP попсовыми мессенджерами давняя, и Яндекс спрыгнул одним из последних как раз. Проприетарщикам не выгодна федерация, им выгоден вендорлок. Непонятно только, почему разработчики свободных мессенджеров подражают проприетарщикам и так же начали пилить гору несовместимых протоколов. Сила опенсорса в единстве, а со всей этой горой Matrix, Bitmessage, Tox, Ring и чего там ещё вместо единого протокола — дела не будет, и не взлетит вообще ничто. Когда васяны выпускают свою поделку под свободной лицензией и не сотрудничают с другими васянами — это ещё не опенсорс, это просто СПО.

А то, что существовали Empathy, Pidgin, Kopete, Psi+… а, это вы просто «не тем» пользовались

Да отнюдь, Мы много чем пользовались продолжительное время: как минимум Psi+, Pidgin, QutIM, Thunderbird. На мобиле ещё BombusMod и Jimm Aspro. А непродолжительное время тыкали куда больше клиентов. И именно в плане стабильности в перечисленных жаловаться не на что. В то время как во всяких телеграмах и скайпах, бывало, тупо отваливалось соединение, и замечали Мы это аж через несколько дней.

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

Не многовато ли 6 лет для MVP?

Спонсоров на удочку долго ловили, по факту хоть что-то начало шевелиться только в 2018-2019 году ­— тогда действительно попёрло. А годом ранее, в 2017, они на весь интернет попрошайничали, потому что не на что было зарплату разработчикам давать.

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

Какой же продукт открытый, если он от бюджета зависит? ;)

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

Пердолинг с тулкитами не всегда весёлая и полезная в жизни вещь.

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

Ну тоесть, вы даже не знаете, для чего нужен Electron и с чем его едят, но осуждаете. Прекрасно.

Основания у Electron есть и они следующие:

  1. UX. Приложение устанавливается в систему, создаёт ярлык в главном меню, отображается в системной рамке окна без вкладок и прочих элементов интерфейса браузера, регистрирует mime-типы (а значит, может открывать файлы)… В общем, ведёт себя как обычное такое нативное приложение и без сюрпризов, вроде тех, что происходят по нажатию F12.
  2. API и выход из Browser sandbox. Потому что это Node.js. Всё что умеет Node.JS - может и приложение. Доступ к файлам - это лишь самый базовый уровень. Иначе говоря, Electron - это GUI для Node.js с привычным для веб-разработчиков DOM.
  3. Runtime. Всё что необходимо для запуска приложения находится в самом приложении, включая браузер, ноду, страницы и скрипты. Не нужно гадать, установлен ли в системе нужный браузер нужной версии, с нужным движком, на котором точно всё есть… И т.д. В теории, можно сделать что-то вроде Electron runtime, но… ¯_(ツ)_/¯
  4. Приложение выполняется полностью Offline. Без веб-сервера.

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

Можно на всё той же вебне писать приложения, которые запускают фоновый демон и открывают вебморду в браузере пользователя (примеров полно: taskwarrior-web, gone, syncthing…)

Это не приложения, а сервисы с веб-мордой. Ничего против не имею, но что-то вроде VSCode я в таком виде не представляю. Например, файлы то как из файлового менеджера по двойному клику открывать?

А PWA-то, PWA тут при чём?

PWA тут притом, что это встроенный в браузер механизм, на основе Web API реализующий веб-приложения в браузере. С возможностью фоновой активности с помощью Service Worker и хранения данных на клиенте.

А если очень захочется, можно перейти на сайт приложения, например, того же web.skype.com, нажать на кнопку «Установить» и тебе добавится ярлык в главное меню, зарегистрируются типы и т.д. Ничего не напоминает?

Только вот от Sandbox не спасёт. Может и правда, для того и купили GitHub, чтобы выполнить Embrace и Extend на Electron.

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

свободные человеко-часы и мотивация в него вкладываться

Из чего проистекает очевидный вывод, что эффективнее эти скудные человеко-часы вкладывать в небольшое число продуктов.

для чего нужен Electron

Для того, чтобы задействовать в разработке дешёвых web-макак вместо дорогих и редких Qt-макак. А ещё из-за лицензии, поговаривают, но на это случай есть ещё более редкие wxWidgets-макаки и Lazarus-макаки ;)

без вкладок и прочих элементов интерфейса браузера

Параметры для window.open Вы там не осилили, да?

регистрирует mime-типы (а значит, может открывать файлы)…

И где это нужно, кроме всходоатомов?

API и выход из Browser sandbox

А не надо было в этот сандбокс залезать изначально. В XULRunner никакого сандбокса не было, творите себе через XPCOM чего хотите ;) Но нет, выбрали анально огороженный жирнохромог, а потом обмазали его ещё более ужасными жирнокостылями.

Не нужно гадать, установлен ли в системе нужный браузер нужной версии

Угу, виндузятники не осилили бороться с DLL Hell, поэтому растащили свой подход на все платформы. Неудивительно, что подхватил эту поделку именно майкрософт.

Приложение выполняется полностью Offline. Без веб-сервера.

Давно жопоскрипту сервер нужен, чтобы работать оффлайн? ;) При чём здесь сервер вообще?

файлы то как из файлового менеджера по двойному клику открывать?

Сервис регистрирует MIME-биндинг, при открытии отрабатывает путь к файлу и открывает его в существующем инстансе UI или открывает новый, problem?

того же web.skype.com

А, ну там действительно, не заметили ;) А ещё?

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

Э, не, опенсорс по принципу «у кого больше бабла — те и круче» не работает :P

Это опенсорс. И заплатить можно не только деньгами, но и делом. А точнее - своим временем. Если вы не вкладывались в проект достаточно значимо, то кто вы такой, чтобы перед вами оправдываться? ;)

До сих пор этого не понял?

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

Где ж готов, когда клиентов нет?

Есть конечно. А если не устраивают имеющиеся, что мешает сделать клиент самому или вложиться в имеющийся? Или вам на всё готовенькое? Ммм? Есть и на GTK клиент, и на Qt клиент, и им как раз не хватает рук.

Ну, потому с вами разговаривать, что об стенку горох. Скукота. Одно и тоже по кругу.

Это надо было в начале делать, сейчас уже поздно

Дааа, классная логика для всех видов стартапов. А главное, какая полезная. Не можешь сделать сразу замечательно, лучше не берись. Всё равно кто-то уже сделал или сделает лучше. Пойди лучше, закинься пивасиком на диване, а потом в петлю.

Ведь в самом начале можно было сделать лучше! Sic!

Ну-ну, попробуйте пересадить пользователей с няшной шустрой проприетарщины типа Telegram/Viber на тормозную электроноподелку :P

А вы не сравнивайте проприетарщину с FOSS. XMPP вон уже заменяет, как федеративный мессенджер. И мне норм. А с темпами разработки Паши ни один опенсорц не сравнится.

тенденция закапывания XMPP попсовыми мессенджерами давняя, и Яндекс спрыгнул одним из последних как раз. Проприетарщикам не выгодна федерация, им выгоден вендорлок.

А вы никогда не думали, что причина может быть не только в вендор-локе? Это правда, лицекнигам, гуглам и прочим гигантам выгоден вендор-лок. Но он выгоден далеко не всем, корпорациям поменьше он совсем не выгоден, т.к. у них нет такого количества хомячков, которым можно было бы диктовать свои условия.

Ну и + ещё, за вендор-лок, это как же так, конкурентам открывать свои драгоценные наработки? Нее…

Есть у отказа от XMPP и другая причина, которую ни один адепт XMPP не хочет видеть, как показывает практика в этом треде. И озвучивал её я ни один раз. Скорее всего, я на это получу отписку вроде «кококо, ниправда, вы всё врёти, это никому не мешает, просто это всё заговор! Говномамонтовость, штабильность рулит!…» и т.д. Но я всё равно озвучу ещё раз:

  1. Сложность разработки (накладные расходы), низкая скорость одобрения и распространения новых расширений протокола. Даже если это не какая-нибудь хотелка корпорации, а действительно важный функционал.
  2. Малый список «основных расширений», обязательных для реализации клиентами. И этот список не обновлялся. Никакой гарантии, что клиенты твоего уютненького сервера будут поддерживать нужный XEP.
  3. В связи с пунктом номер 2 - зоопарк. Можно конечно разрешать подключаться только с определённых клиентов, но мало это кому понравится. Ведь это же не федерация тогда.
  4. Оверхед самого протокола. Немасштабируемость. В том числе благодаря обмазыванию XML и статусными сообщениями.
  5. XEP-ов 100500 штук, а толку. Когда тупо перекинуть файл в пару мегабайт другу - это шаманство то ещё. И опять же, зависит от клиента.

Такое выглядит крайне непривлекательно.

Matrix, Bitmessage, Tox, Ring

Они все про разное. И федеративное - не совсем децентрализованное.

Сила опенсорса в единстве

Тебе самому не смешно? xD Единство шаткое какое-то, когда у нас тут 100500 дистрибутивов, тулкитов и пакетных менеджеров.

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

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

Параметры для window.open Вы там не осилили, да?

А по умолчанию? Ярлык на рабочем столе/меню? И чтобы вот так.

И где это нужно, кроме всходоатомов?

Transmission, лол. Чтобы открывать torrent-файлы сразу на инстансе по двойному клику.

Можно зарегистрировать кроме обработчика файлов - обработчик ссылки. Чтобы ссылки на ipfs:// открывались используя твой инстанс, и неважно какое приложение открывает ссылку.

В XULRunner никакого сандбокса не было, творите себе через XPCOM чего хотите

А XUL тут каким боком вообще? Вы бредите.

Угу, виндузятники не осилили бороться с DLL Hell, поэтому растащили свой подход на все платформы.

Вы забыли про Browser Hell.

Давно жопоскрипту сервер нужен, чтобы работать оффлайн?

C file:// будет работать оффлайн. А как распространять кучку файлов из нашего PWA на клиентские машины?

Сервис регистрирует MIME-биндинг, при открытии отрабатывает путь к файлу и открывает его в существующем инстансе UI или открывает новый, problem?

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

Electron/PWA уже это решает. А вы вместо решений предлагаете костыли, лишь бы не ненавистный Electron. У меня всё.

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

И заплатить можно не только деньгами, но и делом. А точнее - своим временем.

А зачем вкладываться в ненужно, и что при этом мешает критиковать ненужно за то, что оно ненужно?

что мешает сделать клиент самому или вложиться в имеющийся?

Минимизация человекочасов. Когда уже есть клиенты для XMPP — не нужны ни клиенты для шматрицы, ни сама эта шматрица, ведь уже есть XMPP.

Дааа, классная логика для всех видов стартапов.

Здесь вообще не имеет значения, стартап или не стартап. Речь о том, что протокол уже есть, стабилизирован и совместимость с ним впредь ломать не стоит. Как на эту почву должен архитектор и что он должен сделать? Переделать всё нахрен и выпустить новый несовместимый протокол? Так это уже не шматрица будет, название останется разве что. MTProto изначально разрабатывался расширяемым и наслаиваемым, а не через 6 лет разработки. С TON так же хотели сделать: задолго до запуска выпустили полную спеку с описанием блокчейна, языка Fifth и прочего, а не взлетело уже потом, ибо бюрократы завернули.

Пойди лучше, закинься пивасиком на диване

Вы Нас с кем-то путаете.

А вы не сравнивайте проприетарщину с FOSS

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

корпорациям поменьше он совсем не выгоден

И много нынче успешных мессенджеров от мелких корпораций?

низкая скорость одобрения и распространения новых расширений протокола

Но ведь это впрямь не нужно. Что мешает просто сделать свои нестандартные расширения, как было у HipChat? Даже такая полусовместимость лучше, чем совсем иной протокол.

Никакой гарантии, что клиенты твоего уютненького сервера будут поддерживать нужный XEP.

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

Оверхед самого протокола

А у шматрицы с огромными JSON’ами оверхеда типа нет?

Когда тупо перекинуть файл в пару мегабайт другу - это шаманство то ещё

Опять же, ничто не мешает в офффициальном™ клиенте просто сделать кнопочку выгрузки на фирменный CDN, которая выплёвывает в чат ссылку. Без заморочек со всякими XEP-ами. И пользователям намного удобнее, чем выковыривать файлы из мессенджера какими-то специфичными средствами.

Они все про разное

Что значит «про разное»? Все про обмен сообщениями.

когда у нас тут 100500 дистрибутивов

У винды тоже 100500 васянских сборочек, как это ей мешает? Чем васянские дистрибутивы единой операционной системы GNU/Linux (а она едина, бинарные тарболы, линкующиеся по минимум со всякими glibc и libm, работают везде) отличаются от васянских сборочек винды? В мире Android ещё больший швах, там у половины крупных вендоров своя оболочка со своим набором софта и специфичными приблудами.

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

Ярлык на рабочем столе/меню?

А в чём проблема? Не осилили в ярлык ссылку класть?

Transmission

Ну так он издревле демоном работает.

А XUL тут каким боком вообще?

Прямой аналог Electron вообще-то. Вебня с доступом к системе.

Вы забыли про Browser Hell.

Browser Hell в нынешнем мире совершенно не сопоставим с тем, который был лет 10 назад. Мелкие несостыковыки в основном, которые фиксятся от силы за день.

А как распространять кучку файлов из нашего PWA на клиентские машины?

Архивы и инсталляторы тоже не осилили? ;)

В каком браузере открыть страницу, если их несколько?

На уровне MIME-привязок проблема нескольких браузеров никак не решена, дефолтным можно установить лишь один. Посему пользователи нескольких браузеров страдают и копируют ссылки ;)

И эта проблема далеко не только браузеров касается, но и прочих кейсов типа нескольких программ для просмотра/обработки изображений. Мы давно подумываем сделать программу-прослойку, которая перехватывает открытие и предлагает список программ, где можно хоткеем выбрать нужную. Ещё лет 10 назад подобное накостыляли, накидав программ на панельку Total Commander, но там драгндроп ;)

Electron/PWA уже это решает

Каким макаром? Как с помощью Electron открыть web-приложение на движке, ином от жирного хромого? Как PWA открыть без бубна в недефолтном браузере?

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

это ещё не опенсорс, это просто СПО

Какое-то жонглирование терминами. «Open source» не означает ничего, кроме программы с открытым исходным кодом, которая даже может быть под проприетарной лицензией. «Free software» как раз таки может быть идеологией, но по факту тоже ничего не значит, кроме программ под свободной лицензией.

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

Ну ясно, реализация без практического применения.

Тут вон некоторые голой теорией даже без реализации бравировать умудряются ;)

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

Вы в курсе, что такое мышечная память и слепая печать?

Да, но зачем тренировать её на мобилках?

На десктопе слепая печать быстрее за счёт (1) 10-пальцевого набора и (2) того, что не нужно прыгать глазами между экраном и клавиатурой. На мобилке нет ни того, ни другого.

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

Наоборот же! Опечатку в букве можно не заметить, а совершенно другое слово незаметить сложнее. 🙂

Зачастую пользователю нужен ответ не сразу. Написали сообщение, отправили: на экран смотреть не нужно

И всё равно пользователь будет ожидать, что сообщение появится на экране. То есть «диалог» останется.

весьма полезно иметь возможность отдать машине команды впрок

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

Вы предлагаете китайцам вот эти вот футбольные поля использовать вместо IME?

То шутка, конечно. На самом деле у них есть пиньинь и графический ввод. Оба удобны на тачскрине.

Придётся ESC жать, а потом уже макрос вызывать. И перехват одиночных нажатий ESC в настройках MC выключать, иначе не успеете.

А, ок, принято. Но когда есть более простые способы, я бы предпочёл их.

Мы вот отключили, с OOM жизни нет ;)

Вы таки считаете, что линукс «отнял контроль над процессами»?

А мне OOM помогает. У меня swap отключен. Поэтому ничто не тормозит. Никогда. А если браузер вдруг попытается сожрать всю память — ООМ его убьёт, и, если надо, я его перезапущу.

Это удобнее, чем лаги из-за браузера, который загнал другие программы в своп.

И где тут сотня? ;)

Думаю, найдётся больше сотни форумов же?

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

Скопировать/вставить ещё проще. Но... у гугла же нет вотермарков?

Картинку мессенджеры сами по ссылке на пост из meta-тега вытягивают ;)

Но не всегда. И не всегда ту, которую я хотел показать.

Если я хочу показать пост — я кину ссылку на пост. А если я хочу показать одну из его картинок? Писать «<ссылка> смотри 3ю картинку во 2й части»?

Ссылка останется доступной после этого, если хранить логи локально.

И картинка останется доступной, если хранить её локально. И не сдохнет, если сдохнет ссылка.

Синкайте домой рабочий хомяк, раз он нужен ;)

Синкать хомяки непросто... Да и мне не нужен хомяк. Мне нужно увидеть, что я писал.

Вы пытаетесь чисто средствами мессенджера решать более общую проблему

Это не общая, а вполне конкретная и очень распространённая ситуация — переписка с нескольких устройств. Многие мессенжеры её решают. И element её решает. Но не pidgin+xmpp.

В общем, вы спрашивали, чем Element лучше. Я привёл пример.

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

У китайцев — проблемы с установкой клиента, сервер они официальный используют.

Смысл мессенжера в общении. На своём сервере общаться не с кем. А поднять общекитайский не выйдет — его так же закроют, ещё и владельцу достанется.

Ага, и с другим доменом. Ещё и бэкапов актуальных может не быть.

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

А друзьям нужна чья-то воля или надёжный сервис? ;)

Друзьям начхать на надёжность. Им нужна связь со мной. Кто её обеспечит, я или дуров — им всё равно.

долой полумеры, сразу P2P тогда.

Если бы... Увы, это не школьный чатик написать. Даже централизованный хороший мессенжер — это не просто. А написать хороший p2p мессенжер невероятно сложно. Я уже лет 15 такой жду...

Вы же и утверждали, что матриксовцам нужен был веб-ориентированный протокол

Я о том, что тут не веб-протокол, а тесно интегрированный веб-сайт. В нём нет выделенного протокола.

Можно всех зарегистрированных делать «админами»

Админы между собой тоже общаться не могут. Только с пользователями.

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

Философское подведение итогов

В общем-то, эту нашу ветку спора можно сворачивать.

Он стал предсказуем: я описываю, как какая-то идея экономит время, а вы придумываете, как без неё можно обойтись.

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

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

Поэтому из нескольких вариантов я выбираю наиболее простой. Я езжу на машинах/поездах/самолётах, а не иду в другую страну пешком. И если мне нужно зажечь газовую плиту, то я не добываю огонь трением, а беру спички.

Вы в ответ скажете: «Может случиться, что самолёт разобьётся на необитаемом острове, и я окажусь без спичек, как добыть огонь?»

И с этим я тоже согласен! Я не испытываю неприязни к другим методам. Я с интересом смотрю видео Primitive Technology про добычу огня деревянной дрелью. Но я и не отвергаю спички.

И вот тут мы с вами расходимся.

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

Мы расходимся именно в этом «все должны, потому что некоторые могут».

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

Но, что ж, дело вкуса. 🙂

В целом, вроде бы, я понял вашу точку зрения. И вы, надеюсь, поняли мою.

В любом случае — благодарю за интересную беседу.

PS: И, к слову, я много лет использую, в том числе, XMPP. Просто я осознаю его недостатки.

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

На прикладном уровне имеем станцы. Станца при передаче дробится на TCP-пакеты. На каждый пакет пришёл ACK — значит, станца передалась. Не пришёл — не передалась. Что тут сложного-то, блин, зачем XEP-ы какие-то выдумывать?

Проблемы терминологии.

На самом деле всем пофиг, доставлено TCP сообщение или нет. Важно то, было ли оно обработано программой на другой стороне.

Потому что если сообщение попало в сокет, но прога упала при его вычитывании, то от того, что TCP доставлено, никому легче не станет.

То есть нужен не просто ACK, а сигнал от проги, что она вычитала сообщение, сохранила его, и даже если она сейчас упадёт, то после перезапуска она покажет это сообщение пользователю.

TCP этого не позволяет. Это — не его задача.

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

меняйте методичку, ваша устарела

Есть у отказа от XMPP и другая причина, которую ни один адепт XMPP не хочет видеть, как показывает практика в этом треде.

Есть. Как минимум три были озвучены в этом треде, но вы ни одной из них не назвали.

Скорее всего, я на это получу отписку вроде «кококо, ниправда, вы всё врёти, это никому не мешает, просто это всё заговор!»

Почти. 🙂 Но без заговора.

Сложность разработки (накладные расходы)

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

XMPP хорошо документирован.

А для матрикса вы справитесь только реверс-инженерингом Element-а.

низкая скорость одобрения и распространения новых расширений протокола.

Да. Но как раз это — не проблема. В XMPP для реализации расширения ничьё одобрение не нужно. Наоборот, наличие реализации способствует более быстрому одобрению.

Малый список «основных расширений», обязательных для реализации клиентами. И этот список не обновлялся.

А это ложь. Потому и сделанные из этого пункта выводы тоже ложны.

Как уже писалось в треде, есть XMPP Compliance Suites 2020.
И оно обновляется почти каждый год (2019, 2018, 2016 ... 2009).

Оверхед самого протокола.

Оверхед даже меньше, чем у многих других протоколов. Уверяю вас, оверхед HTTP хедера в матриксе очень немаленький.

Но, к счастью, всем пофиг. Сейчас передача мегабайтных картинок — норма. По сравнению с ними оверхед протокола вообще не заметен.

Немасштабируемость.

Да, ужасная немасштабируемость. 🙂 Один сервер может вытянуть всего лишь 2 миллиона одновременных подключений. Интересно, у кого масштабируемость лучше?

Такое выглядит крайне непривлекательно.

Если в вашей методичке ещё что-то есть — выкладывайте.

Если нет — обновляйте методичку, она устарела. 🙂

И, кстати, устарела во многом благодаря появлению других мессенжеров — это заставило XMPP-шников шевелиться.

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

Да, но зачем тренировать её на мобилках?

А зачем не тренировать? Дискриминацией мобилок попахивает.

10-пальцевого набора

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

не нужно прыгать глазами между экраном и клавиатурой

Вас кто-то заставляет смотреть на аппаратную клавиатуру на мобильнике? Набирать можно хоть в кармане, и даже управлять.

Опечатку в букве можно не заметить, а совершенно другое слово незаметить сложнее. 🙂

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

пользователь будет ожидать, что сообщение появится на экране

Зачем? И это делается один раз, если уж на то пошло, а не во время всего набора.

жму несколько кнопок впрок (хоть на аппаратной клавиатуры, хоть на экранной)

Это если UI переключать не надо (даже тупо раскладки или символьный режим на всё той же виртуальной клавиатуре). А речь шла более широко, об управлении в целом. Когда на экране переключаются интерфейсы, нереально надёжно передать тычок на следующий интерфейс до того, как он появился и отрисовался.

у них есть пиньинь

Угу, по два десятка иероглифов на одно произношение…

Но когда есть более простые способы, я бы предпочёл их.

А тут в консоли вариантов нет, всё на костылях. Мы давеча вон в top засылали патч с Vim-навигацией, а оказалось, что она уже есть, только с зажатием Alt. И вот из-за последнего и не работает в половине терминалов. Починить толком нельзя, ибо Alt как таковой реализован через костыли.

Если хотите писюковых хоткеев, то давайте уж лучше VNC какой-нибудь обсуждать. Вот J2ME VNC действительно ущербный ;)

А если браузер вдруг попытается сожрать всю память

Угу, в процессе чего-то важного. Нафиг-нафиг.

Думаю, найдётся больше сотни форумов же?

На которых одновременно торчит один и тот же пользователь?

Но… у гугла же нет вотермарков?

Зато гугл шакалит. А дятлы, которые любят тупо копировать/вставлять, это не всегда замечают.

А если я хочу показать одну из его картинок? Писать «<ссылка> смотри 3ю картинку во 2й части»?

Нет, дать ссылку на конкретную картинку, раз их в посте несколько.

если хранить её локально

Если есть место хранить тонну потенциально ненужных картинок (и тем более чего-то более жирного) локально. С текстовыми логами куда проще, их хоть на дискету можно напихать дохрена.

если хранить её локально

Что там непростого, если в отдельную директорию? Трафика жалко? :->

Да и мне не нужен хомяк. Мне нужно увидеть, что я писал.

Маргинальный кейс, не находите? То нужно, это не нужно…

Это не общая, а вполне конкретная и очень распространённая ситуация — переписка с нескольких устройств. Многие мессенжеры её решают

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

Смысл мессенжера в общении. На своём сервере общаться не с кем

А в маргинальных федеративных типа есть с кем, ну-ну.

чем вообще без контактов остаться

Чтобы не остаться без контактов — надо их резервировать. С дятлами, которые кладут на болт на принцип «не держать все яйца в одной корзине» (типа этого) — так не получится, конечно. Собственно, они ж виновны в усугблении зоопарка в первую очередь.

Им нужна связь со мной

А если наоборот?

В нём нет выделенного протокола

Кто мешает выделить и описать документацию? Клиенты к проприетарным мессенджерам вон и без этого всего делают, реверс-инжинирингом попросту.

mertvoprog ()
Ответ на: Философское подведение итогов от anonymous

А для этого сложные действия должны становиться проще и быстрее

Вы смешиваете простоту освоения с простотой использования. Знаете поговорку «день ехать, чтобы за пять минут долететь»?

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

а сигнал от проги, что она вычитала сообщение, сохранила его

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

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

Вы смешиваете простоту освоения с простотой использования.

Я имею ввиду именно простоту использования. Не понимание, или реализацию, а именно использование.

Например, мало кто знает, как устроен магнетрон. Ещё меньшее количество людей могут сконструировать СВЧ-излучатель. Но пользоваться им могут почти все — микроволновка.

Знаете поговорку «день ехать, чтобы за пять минут долететь»?

Это, вообще-то, шутка из мультика «Крылья, ноги и хвосты».🙂

а сигнал от проги, что она вычитала сообщение, сохранила его

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

После того, как данные были сохранены за пределами программы. Программа сообщает о том, что она сохранила данные. Если после этого мобилку уронили в шреддер, купили новую, и данные восстанавливали из бакапа недельной давности, то это — не вина программы, она сделала, что могла.

Именно этот сигнал в других мессенжерах отображается как «сообщение доставлено».

Конечно, это ещё не значит, что юзер увидит сообщение. Он может вообще удалить программу не глядя на сообщения.

Поэтому есть ещё и другой сигнал: «сообщение показано пользователю». Он к TCP тоже отношения не имеет.

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

Но пользоваться им могут почти все — микроволновка.

Опять устройства под одну задачу сравнивают с универсальными ЭВМ, мда.

И к слову, пользоваться микроволновкой отнюдь не просто. Несмотря на кучу подстраховок, надо как минимум знать, что в неё можно класть.

Это, вообще-то, шутка

В каждой шутке есть доля шутки :P А про дровосека и пилу, или прапорщика и пальму — тоже шутки?

то это — не вина программы, она сделала, что могла

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

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

И зачем этот мусор? Может, от второго клиента и конфиг давно дропнут. У телеги та же проблема, кстати; Мы когда свой клиент тестили, накопились десятки одноразовых сессий, пришлось их чистить потом.

Это как раз функционал, который должен быть изначально, и только в недомессенджерах нет такого очевидного функционала.

WUT? Промежуточной между чем и чем?

Между пользователем и сервером, клиенту вообще не надо знать пароль.

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

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

В XMPP этой проблемы нет, поскольку нет единого «самого лучшего» клиента, есть много равномерно недоработанных (причём по-разному).

Возьмём fluffychat, он не дотягивает до Element, поэтому, следуя твоей логике, он говно. С другой стороны fluffychat на уровне conversations (лучший клиент под Android). Получаем, что и conversations - говно.

С другой стороны, в xmpp есть «много равномерно недоработанных (причём по-разному)» (на самом деле это означает, что ты признал, что все клиенты xmpp - говно), и им можно пользоваться, следовательно fluffychat-ом, который на том же уровне, тоже можно пользоваться. Получаем взаимоисключающие факторы.

Также фатальный недостаток Matrix в том, что нет вообще никаких клиентов под некромобилки.

Кто тебе сказал эту чушь? Не слушай его, он толкового ничего не посоветует.

То есть любым более-менее приличным клиентом можно пользоваться, не чувствуя ущемлённости,

Неа, нельзя, так как все недоделаны и все говно. В противном случае и клиентам Matrix можно более-менее пользователься, не чувствуя ущемлённости.

То же присуще e-mail, например: где единый самый крутой клиент для e-mail?

Некорректное сравнение. Тебе задача на звёздочку рассказать почему так.

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

Федеративность подразумевает, что каждый сервер является самодостаточным и способ обеспечить историей свои клиенты. Именно поэтому серверу matrix приходится вытаскивать историю и хранить как минимум state-граф. Именно поэтому, если один сервер matrix уходит в offline, чат не умирает, и пользователи продолжают там общаться. Если мы отказываемся от федеративности, то получает централизованные MUC-и из xmpp, где умер сервер чата == умер чат.

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

Их полно на самом деле.

Например, когда вы заходите в мобильное приложение facebook, вконтакте, …, то клиент не хранит пароль у себя, он хранит только токен, который передаёт на сервер. Так устроен клиент gmail, когда ходит на gmail. Так устроена интеграция между разными компаниями, например, когда вы оплачиваете в интернете, то через OAuth2 или по сертификату авторизуется мерчант в платёжной системе, а тот у эквайера.

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

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

А при чём тут XMPP, когда пункты были для Matrix? Для XMPP требование нерелевантно ввиду отсутствия аналога Element в экосистеме XMPP.

То есть все клиенты xmpp априори не дотягивают до этих пунктов, я вас понял.

Ну а как Вы предлагаете иметь локальную копию переписки на случай недоступности Интернета, сервера или удаления сообщений на сервере? Если утверждаете, что клиенту хранить сообщения не нужно?

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

На случай недоступности Интернета зачем нужна история?

Если хранить историю на клиенте, то сразу же получаем следующие проблема:

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

Ещё раз: это задача TCP, а не протоколов прикладного уровня. ССЗБ с долгоживущими соединениями, по которым непонятно, когда они оборвались — ССЗБ.

Как раз таки эту задачу TCP и не решает, перечитайте и попробуйте понять: https://www.ejabberd.im/faq/tcp/index.html Отлично, вы только что сами подтвердили, что все сервера xmpp - ССЗБ.

В этой ветке речь о мостах, а не о транспортах; Вы опять скачете туда-сюда? Если там мост, то никакого m_home.org@xmpp.home.org не будет, будет m_bridge@xmpp.home.org, который пересылает все сообщения от своего лица. Технически он может залогиниться в один и тот же MUC с несколькими ресурсами и выставить на них разные ники, но на практике Мы такого не встречали ;) @Darth_Revan, @pztrn, @derlafff, как идея?

И где там такие подробности описаны?

Вы меня либо не хотите, либо не можете понять, давайте я попробую ещё раз объяснить: в matrix большинство мостов являются транспортами, поэтому для них эти термины взаимозаменяемы. Во-вторых, если по моей ссылке (можно даже на русском https://wiki.calculate-linux.org/ru/matrix_xmpp_bridge) почитать, то можно увидеть такую фразу:

Для открытия диалога с пользователем user:matrix.example.org из XMPP, начните диалог с user_matrix.example.org@matrix.xmpp.example.org.

Другими словами, чтобы написать в личку пользователь xmpp должен написать сообщение пользователю m_home.org@xmpp.home.org, мост/транспорт дальше будет перекидывать это сообщение в личку пользователю @m:home.org из matrix. Если сидеть в MUC-ах, то ники у пользователей будет такие как derlaf, pztrn и так далее, мост/транспорт их уже отранслирует в комнату matrix.

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

Чтобы не привязываться к конкретному мессенжеру покажу на примере SSH. Я залогинился на сервер с одного компа, добавил свой публичный ключ. Выключил комп. Включил другой, залогинился с него, и добавил его публичный ключ.

В XMPP идентификатор залогиненного клиента — ресурс. Поэтому ответ про ресурсы — максимально правильный.

В случае ssh если каждый вход выполняется со своим ключом, который добавляется в ~/.ssh/authorized_keys, то можно сказать со скольких устройств был вход. И есть возможность отключить другое устройство, удалив его ключ. А в xmpp по ресурсам можно сказать только про подключенные устройства, в нём нельзя получить все ресурсы, включая offline устройства.

Пароль от токена не сильно отличаются.

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

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

Это как раз функционал, который должен быть изначально

Изначально можно много чего требовать. А между тем, минимально необходимую функциональность мессенджера обеспечивает даже netcat.

Между пользователем и сервером, клиенту вообще не надо знать пароль.

И как это организовать? Вводить пароль в отдельную доверенную программу, которая передаёт клиенту только хэш?

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

С другой стороны fluffychat на уровне conversations (лучший клиент под Android). Получаем, что и conversations - говно.

Ну так и есть. Консерва довольно примитивная, до тех же Xabber и Jasmine ей ещё ползти и ползти. Из киллер-фич там только мамка.

на самом деле это означает, что ты признал, что все клиенты xmpp - говно

Доброе утро, вокруг уже много десятилетий как одно говно, копроэкономика же :3

Кто тебе сказал эту чушь?

К чему этот визг? Покажите эти клиенты, если не согласны.

В противном случае и клиентам Matrix можно более-менее пользователься, не чувствуя ущемлённости.

Нельзя, потому что в мире Matrix есть Element.

Некорректное сравнение

Очень даже корректное, почта федеративна и выполняет почти те же задачи, что мессенджеры (с IMAP PUSH грань вообще стёрлась довольно). А федеративна она благодаря тому, что везде используются единые стандартные протоколы, если не считать унылую попытку мелкомягких зафорсить свой Exchange.

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

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

  1. Делаем плюшканейм.

  2. Начинаем утверждать, что всё, что без плюшканейм — говно, ретроградство и вообще не то, чем является.

  3. Поддаём остракизму несогласных.

  4. ????

  5. PROFIT!!!

Только есть небольшой нюанс: работает такая стратегия только на идиотах. А ещё нужно иметь огромное влияние на рынок, чтобы сработал п.3.

то получает централизованные MUC-и

Вы не поверите, но мессенджер вообще не обязан иметь MUC как таковые.

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

facebook

вконтакте

gmail

О чём и говорим: полторы централизованные платформы. Опровержение где?

когда вы оплачиваете в интернете, то через OAuth2 или по сертификату авторизуется мерчант в платёжной системе, а тот у эквайера

Давно в 3-D Secure используется OAuth2? пруф. Если где-то дополнительно поверх него нашлёпан OAuth2, то это частные случаи.

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

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

Действительно, есть же email, fidonet, irc, зачем плодить зоопарк в виде xmpp?

Ну и так почему Вы приравниваете одно к другому? Мы о форматировании «между делом» упомянули.

Воу-воу. Вот тут Gitter становится частью сети Matrix (комментарий) пишете

Выглядеть-то выглядят, только сам он их шлёт как-то иначе.

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

В рамках протокола одно, в реальности другое.

Если я переустановлю xmpp-клиент, то у него будет другой ресурс. В рамках протокола два разных ресурса, а в реальности одно устройство. Как дальше жить?

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

Если вы считаете, что это «нужно», то создавайте. Или у вас оно уже есть? Как называется, как попробовать?

И в итоге Мы уже который год ищем клиент, который их пишет, ага. Ни один не пишет, зараза. Кроме libpurple-плагина, который срёт всеми чатами при каждом реконнекте.

Что и требовалось доказать. До всех уже дошло ущербность попытки хранить историю на клиенте, но вы предлагаете продолжать жрать кактус дальше. Приятного аппетита. :)

Они не про то. MAM даёт клиенту доступ к истории на сервере технически унифицированным способом (вместо всяких там отдельных логов). Карбонка копирует только в момент отправки. Синхронизация же — про обмен свои логами, в том числе старыми, между клиентами.

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

А с чем связываться? Всякие велосипеды-новоделы априори хуже, потому что моложе и посему менее проработанные.

XMPP больше лет, но большей проработанность он не отличается.

С того, что XMPP-клиенты для некромобильников есть, а Matrix-клиентов нет. Посему какие-то там транспорты для шматрицы вообще мимо кассы, или предлагаете через два транспорта гонять?

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

Реплаи туда-сюда перебрасываются?

Как в xmpp могут реплаи перебрасываться, если их там нет? Цитаты - это не реплаи.

https://github.com/tulir/mautrix-telegram/blob/master/ROADMAP.md

Секретные чаты работают?

Сейчас нет, планируют добавить. Но вы же понимаете, что секретные чаты, что в жаббограм, что тут работают в режиме mitm? Что транспорт всё равно снифит и видит все сообщения секретных чатов? Смысл от таких секретных чатов?

Поиск по всей истории чата работает? Модерировать группы можно?

Да. Да.

Жабограмм умеет отображать кнопочки и голосовалки, pinning сообщения?

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

О чём и говорим: полторы централизованные платформы.

Вы специально проигнорировали, что я написал. Когда запускаете клиент facebook, то он цепляется к facebook не через пароль, а через oauth2. Это пример. Практически любое приложение так делает, чтобы предоставить доступ пользователя к ресурсами сервера.

Давно в 3-D Secure используется OAuth2? пруф. Если где-то дополнительно поверх него нашлёпан OAuth2, то это частные случаи.

Вы проигнорировали что я написал (я ни слова не написал про 3ds), что-то выдумали и хотите от меня пруфов на то, что сами же выдумали.

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

Изначально можно много чего требовать. А между тем, минимально необходимую функциональность мессенджера обеспечивает даже netcat.

Смотря что подразумевать под мессенджером. Так-то можно и через gopher файликами обмениваться и назвать это «мессенджером».

И как это организовать? Вводить пароль в отдельную доверенную программу, которая передаёт клиенту только хэш?

я уже писал ответ на этот вопрос: https://tools.ietf.org/html/rfc6749

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

Ну так и есть. Консерва довольно примитивная, до тех же Xabber и Jasmine ей ещё ползти и ползти. Из киллер-фич там только мамка.

И вы сами подтвердили, что клиенты xmpp - говно. Что и требовалось доказать.

К чему этот визг? Покажите эти клиенты, если не согласны.

Для начала вы должны доказать, что отсутствие клиентов под старые и неподдерживаемые устройства - фатальный недостаток.

Нельзя, потому что в мире Matrix есть Element.

Можно.

Очень даже корректное, почта федеративна и выполняет почти те же задачи, что мессенджеры (с IMAP PUSH грань вообще стёрлась довольно). А федеративна она благодаря тому, что везде используются единые стандартные протоколы, если не считать унылую попытку мелкомягких зафорсить свой Exchange.

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

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

К чему этот визг? Покажите федеративность MUC в xmpp.

Вы не поверите, но мессенджер вообще не обязан иметь MUC как таковые.

Опять же, что подразумевать под мессенджером, так-то можно и файлами обмениваться через ftp и называть это «мессенджером».

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

То есть все клиенты xmpp априори не дотягивают до этих пунктов, я вас понял.

Неверно. Они не сравнимы, как комлексные числа с действительными.

На случай недоступности Интернета зачем нужна история?

Затем, чтобы не потерять к ней доступ, очевидно же. Или Вы думаете, что Интернет вечен? (или хотя бы в нём что-то вечно?)

надо клиент держать постоянно включённым

Да, а что делать? Серверной истории доверять нельзя, ибо такие фичи, как удаление сообщений на сервере и бан доступа к чатам, идут вразрез с сохранением локальной копии всех сообщений.

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

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

надо выдумывать костыли для синхронизации истории между клиентами

Если один постоянно онлайн, то такой проблемы нет, не находите? ;)

перечитайте и попробуйте понять: https://www.ejabberd.im/faq/tcp/index.html

Там шиза какая-то. Жалуются, что мобильные клиенты отваливаются, а если их часто пинговать, то батарея садится. А на хрена тогда клиент подключается сокетом вместо BOSH, если он батарею экономит?

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

есть же email, fidonet, irc, зачем плодить зоопарк в виде xmpp?

И это верно. XMPP нужен лишь: 1) ради дятлов, которые пользуются XMPP; 2) как промежуточный протокол ;) В отличие от прочих мессенджеров, для которых справедлив только п.1.

Вот тут Gitter становится частью сети Matrix (комментарий) пишете

Не-а, сначала перечитайте здесь и чините свой парсер русского языка, прозевавший переход ;)

Если я переустановлю xmpp-клиент, то у него будет другой ресурс

Некоторые клиенты вообще на каждую сессию рандомный ресурс генерируют.

Как дальше жить?

А в чём проблема? Проблему разработчики шматрицы выдумали дурацкой терминологией ;)

Или у вас оно уже есть?

Программы для синхронизации? Да тысячи их. Рекомендуем SyncThing ;)

До всех уже дошло ущербность попытки хранить историю на клиенте

До кого, до облакозависимых всяких? А Мы здесь при чём?

если полная история всегда есть на сервере?

По очевидной причине, что постоянный доступ к серверу не гарантирован. Сервер в общем случае хрен знает где (если это не подкроватный сервер), а клиент подконтролен.

XMPP больше лет, но большей проработанность он не отличается.

Он поныне намного проработаннее. Вот когда в шматрице реализуют все возможности XMPP со всеми XEP-ами, и даже больше — тогда и приходите.

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

Общее для кого?

Как в xmpp могут реплаи перебрасываться, если их там нет?

Жабограм реализует реплаи по id сообщений, как на бордах: >>15941146 Их можно слать даже с тупейших клиентов.

Что транспорт всё равно снифит

Транспорт может быть self-hosted ;)

Жабограмм умеет отображать кнопочки и голосовалки, pinning сообщения?

Не умеет.

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

Практически любое приложение

Какое любое? Вам предъявляют за полторы централизованные платформы — Вы эти же самые платформы и начали приводить в пример.

я ни слова не написал про 3ds

Но для означенной задачи-то используется в общем случае именно 3-D Secure. А OAuth2 здесь при чём? В каких банках такое?

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

Так-то можно и через gopher файликами обмениваться и назвать это «мессенджером».

Можно. В руках опытного шифропанка в мессенджер превращаются даже опечатки в постах или опавшие листья ;)

я уже писал ответ на этот вопрос: https://tools.ietf.org/html/rfc6749

При чём здесь OAuth, машувать? Вот purple-hangouts, например, работает через выковырянный из вебморды OAuth-токен. Который вводится — сюрприз! — в поле для пароля. Так в чём разница с паролями в итоге? В том, что пароли пользователи придумывают сами? — так пароли и автосгенерированными бывают, в том числе принудительно. В том, что токены временные? — так и пароли бывают временными. В том, что токены отдельные на каждое приложение? — так пароли тоже бывают отдельными на каждое приложение, см. «пароли для приложений» в почтах GMail/Ukr.Net/Yahoo!; вдобавок, пример с purple-hangouts наглядно демонстрирует, что токены можно шарить между приложениями. Так в чём разница-то?

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

Что и требовалось доказать.

А зачем доказывать, что что-то говно? Доказывать надо, что что-то не говно. По дефолту всё говно, при копроэкономике же живём.

Для начала вы должны доказать, что отсутствие клиентов под старые и неподдерживаемые устройства - фатальный недостаток.

А для чего ещё эти ваши свободные мессенджеры нужны? Реальные люди ими пользуются с пренебрежимо низкой вероятностью.

Можно.

Как Вы это себе представляете?

Неа, не справились с вопросом, давайте подумайте

В препода поиграть решили? ;)

Покажите федеративность MUC в xmpp.

А давно речь о федеративных MUC зашла? MUC внутри мессенджера — это иной уровень абстракции, чем сами мессенджеры.

Опять же, что подразумевать под мессенджером, так-то можно и файлами обмениваться через ftp и называть это «мессенджером».

Ну вот когда там в аське, например, групповые чаты появились, в конце 00-х аж? До этого она мессенджером не была, что ли?

mertvoprog ()