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

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

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

Да, ничто не даст гарантированной 100% надёжности. Но в большинстве случаев это работает.

А мессенжер, в котором это работает в 99% случаев явно лучше, чем мессенжер, в котором это работает в 0% случаев. 🙃

В XMPP эта фича тоже есть, если что. Хотя и не во всех клиентах. В XMPP Compliance она числится в Advanced Client.

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

По ней у меня отдельный вопрос. У меня два syncthing-устройства уже некоторое время считают друг-друга «disconnected». Вот бы выяснить, где проблема, и как заставить их снова друг друга увидеть...

Но к мессенжерам это не относится.

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

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

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

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

А в xmpp по ресурсам можно сказать только про подключенные устройства, в нём нельзя получить все ресурсы, включая offline устройства.

Так нельзя узнать число устройств же. 🙂 Ни в каком протоколе. Ни в ssh, ни в xmpp, ни в матриксе. Можно узнать только число ключей/токенов. В случае XMPP — можно узнать число сессий, которые сервер считает валидными — по ресурсам.

При этом xmpp устройство может быть выключено и физически уничтожено, а начатая им сессия висеть в ожидании SM resume.

Я на токен могу выдать определённые роли, как такое же сделать с паролем?

Отдельный пароль. В случае ssh для этого традиционно отдельный юзер заводится.

А вы можете выдать токену определённые роли? Вот, например, в ssh у всех ключей «роли» одинаковые.

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

Нужная юзерам фича.

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

в большинстве случаев это работает

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

два syncthing-устройства уже некоторое время считают друг-друга «disconnected»

Did you try to turn it off and on? ©

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

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

Юзер хочет фичу — знать, что сообщение было доставлено получателю. Чему его обучать?

в большинстве случаев это работает

Вообще не факт. Вероятность краша ОС или оборудования запросто может быть выше вероятности краша программы.

А вероятность отсутствия крашей ещё выше. И при отсутствии крашей — всё работает, и я узнаю, что получатель сообщение получил.

Лишь в редких случаях, когда таки что-то закрашилось, или мобилка сдохла, или её выкинули в жерло вулкана Килауэа — и я всё ещё буду видеть сообщение как недоставленное, я могу переспросить, получил ли он его.

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

Did you try to turn it off and on? ©

Много раз. Одно из устройств — мобилка.

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

Чему его обучать?

Тому, что мессенджер не может этого гарантировать. Мы реально встречали дятлов, которые ведутся на эти галочки и даже чего-то предъявляют на их основе ;)

и я всё ещё буду видеть сообщение как недоставленное

Так речь как раз о том, что отмечено доставленным оно будет, но получатель не успеет это увидеть, вдобавок сообщение по факту не успеет сохраниться. Как Вы в таком случае узнаете, что на той стороне вообще произошёл какой-то сбой?

Много раз

Уже любопытнее. А с другими устройствами те же директории синхронизируются?

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

Тому, что мессенджер не может этого гарантировать.

В мире вообще никто ничего не может гарантировать. Гарантия и не нужна. Достаточно, чтобы оно работало в большинстве случаев.

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

Мы сейчас про какую галочку — про «доставлено» или про «прочитано»?

Если про «доставлено», то она и не гарантирует увиденности.

Если про «прочитано», то она отправляется после того, как юзер откроет сообщение. Он его, что, открыл и зажмурился? Или как он смог его не увидеть?

Уже любопытнее. А с другими устройствами те же директории синхронизируются?

Теперь уже не проверю. Для эксперимента перекинул каталог вручную по usb, убил syncthing на мобилке, установил заново, и заново добавил устройство и каталог. Пока синхронизируется...

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

Достаточно, чтобы оно работало в большинстве случаев.

А толк с этого какой? С таким же успехом можно на будку с собакой повесить табличку «не кусается» — а она возьмёт и укусит таки кого-то раз в жизни. Лучше перестраховаться и не вешать таких табличек.

Он его, что, открыл и зажмурился? Или как он смог его не увидеть?

Вариантов масса:

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

  • чат может открыть кот/спиногрыз/товарищ майор;

  • клиент может упасть в аккурат после открытия сообщения;

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

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

А толк с этого какой? С таким же успехом можно на будку с собакой повесить табличку «не кусается» — а она возьмёт и укусит таки кого-то раз в жизни. Лучше перестраховаться и не вешать таких табличек.

Вы опять пытаетесь придумать те редкие случае, когда что-то не работает. А это — тупиковый принцип.

В смысле, принцип «не пользоваться никогда тем, что иногда не работает» — не работает. 🙂 Потому что мы тогда вообще ничем не будем пользоваться.

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

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

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

В смысле, принцип «не пользоваться никогда тем, что иногда не работает» — не работает

Речь не об этом. Речь о том, что сами уведомления о доставке как таковые — индикатор работоспособности. И поскольку свою задачу они выполнять не могут by design, то они не нужны и даже вредны, поскольку могут вводить в заблуждение.

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

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

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

В 80–90-х гг. в СССР/бСССР, кстати, были крутые телефоны (например): набираете номер, жмёте звёздочку — и телефон сам по кругу пытается дозвониться ;)

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

И это резонно. Включение/выключение — стресс для техники: перепад напряжения, раскрутка, загрузка ОС, и так далее. Посему лучше не выключать, а обеспечивать постоянную работу или хотя бы уводить в сон вместо выключения. Это и удобнее, так как ЭВМ всегда доступна.

ведь иногда они перегорают

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

Не будем пользоваться спичками/зажигалками, потому что иногда они не зажигаются.

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

Не будем покупать одежду, потому что иногда она рвётся.

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

Нужно что-то более веское.

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

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

Речь о том, что сами уведомления о доставке как таковые — индикатор работоспособности. И поскольку свою задачу они выполнять не могут by design, то они не нужны и даже вредны, поскольку могут вводить в заблуждение.

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

В цивилизованном мире это именно так работает. Посему, например, там запросто могут запретить анальгин, хотя из-за него умирает всего пару процентов детей.

Только если есть более хорошо работающая альтернатива.

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

Это — байка. 🙂 Нет смысла перечислять список всего, что нельзя делать. Этот список бесконечен. Пишут просто что «производитель не несёт ответственности».

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

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

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

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

То ли дело современные электрические плиты, они куда практичнее ;)

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

Приличные люди одежду не покупают, а шьют: для себя, на совесть.

Не, шить тоже нельзя. Потому что нечем. Швейная машинка может сломаться, нитка может порваться, а иголка может палец уколоть. Нельзя так рисковать...

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

А эта причина есть всегда — оно работает. Пусть и не в 100% случаев.

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

Если делать программу «как для идиотов», то только идиоты и будут ей пользоваться.

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

У них нет задачи быть идеально точными в 100% случаев

А пользователей кто об этом предупреждает? Пока нет такого закона, как для кук, чтобы на самом видном месте предупреждать пользователей, что что-то со 100%-ной гарантией не работает. И тупые пользователи по дефолту на эту гарантию рассчитывают, и искренне удивляются, когда галочка не соответствует действительности. Так что нехрен отстаивать полурабочие решения.

Только если есть более хорошо работающая альтернатива.

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

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

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

Но по этой логике и мессенжерами тоже нельзя пользоваться, ведь интернета может не быть, или сообщения могут не дойти…

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

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

Именно так, если свет моргает, то он наверняка скоро моргнёт ещё — прямо во время загрузки, что особо чревато. Лучше переждать. Ну или обзавестись ИБП наконец ;)

Те что с электроподжигом?

Кого там поджигать?

Швейная машинка может сломаться

Могут и ломаются, надеяться на них не стоит.

нитка может порваться

Нитку не жалко, как и спички ;)

иголка может палец уколоть

Напёрстки для чего придуманы?

А эта причина есть всегда — оно работает

Этого мало. Нужны обоснования для внедрения.

Если делать программу «как для идиотов», то только идиоты и будут ей пользоваться.

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

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

Зрачкорасширяющие капли, которые действуют лишь несколько часов, это запретить не помешало

Кто-то запретил врачам использовать мидриацил?

Вообще-то англосаксонское прецедентное право именно так и работает.

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

А пользователей кто об этом предупреждает?

Лицензионное соглашение: «This program is provided „as is“ without warranty of any kind».

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

Нет, речь именно об этом. Мы либо пользуемся вещами, не дающими 100% гарантии, либо отвергаем их. Если отвергаем, то мессенжеры также должны быть отвергнуты. Как и все остальные вещи в мире.

Напёрстки для чего придуманы?

Для того, чтобы иголка с них соскальзывала и втыкалась в палец. В общем, напёрстки тоже 100% защиты не дают.

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

А теперь давайте поменяемся ролями, и я скажу «не совсем». 🙂 Они не вытесняют, а совершенствуются.

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

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

И так везде, не только в мессенжерах. Раньше одноэтажный дом строили несколько лет. А сейчас можно за несколько ДНЕЙ возвести 15-этажное здание или уложить 5 километров дорожного полотна.

Этого мало. Нужны обоснования для внедрения.

Обоснование — эта фича экономит время/силы или даёт дополнительные возможности.

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

Кто-то запретил врачам использовать мидриацил?

Врачам — нет, но частным клиникам некоторое время достать тропикамид было проблематично ;)

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

Ну так в чём Вы расхождение видите? Решение о наказании есть — значит, запрещено. Или список непременно должен быть отдельной бумажечкой с пунктиками? ;)

without warranty of any kind

…to the extent permitted by applicable law, ага. Можно, конечно, это явно не указывать, но в некоторых юрисдикциях суд это будет подразумевать безотносительно того, чего в лицензии накалякано ;)

Мы либо пользуемся вещами, не дающими 100% гарантии, либо отвергаем их

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

и втыкалась в палец

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

Это нормально. Так и должно быть

Нет, объединение функциональности в одном продукте — это путь к монополиям. И, кстати, одна из причин, почему чистый рыночек нежизнеспособен и приходится его курощать госрегулированием. Напомнить, как мелкомягким запретили WMP с виндой поставлять в ЕС? Хотя пользователям-то удобнее, когда сразу плеер стоит.

А сейчас можно за несколько ДНЕЙ возвести 15-этажное здание или уложить 5 километров дорожного полотна.

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

Обоснование — эта фича экономит время/силы или даёт дополнительные возможности.

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

mertvoprog ()