LINUX.ORG.RU

Matrix - открытый и свободный IM-протокол как замена Skype/Viber/etc

 , , , ,


4

3

Познакомился я с ним недавно по наводке местных евангелистов и под впечатлением сочинил небольшой спич с видеодемонстрацией почему он круче, быстрее и сильнее остальных. Проект пока в бете, но текстовые чаты и аудио/видео звонки работают уже сейчас. Из главных плюсов - полная открытость как серверной так и клиентской части (не надо торговать своими персональными данными), мультилогин, синхронизация истории, WebRTC. Существуют клиенты под Linux, Android и другие ОС. В Matrix также существует lor и ru-комьюнити.

Enjoy!

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

Ага, идея «Простой клиент» была когда-то заложена в XMPP. Но время прошло, и простой протокол оброс таким количеством ХЕРов, что теперь язык не поворачивается назвать его простым.

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

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

Сложный клиент (для XMPP) мало кто сможет правильно запилить. Следовательно, правильно сделанных клиентов для XMPP мало или нет вообще.

Простой клиент (для Matrix) любой сможет правильно запилить. Следовательно, клиенты для Matrix будут появляться быстрее. А одну реализацию сложного сервера уж как-нибудь можно сделать.

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

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

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

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

Нет, неправильно. Само появление нового протокола делает лучше многим, если этот протокол намного лучше аналогов и в перспективе их заменит. А вот матрикс пока от аналогов ничем не отличается, кроме того что там json.

Простой клиент (для Matrix) любой сможет правильно запилить. Следовательно, клиенты для Matrix будут появляться быстрее.

А вот тут ошибка. Клиент который поддерживает все фичи матрикс на данный момент так же просто, как запилить базовый клиент для XMPP. А вот когда матрикс дорастёт до всего что есть в XEP'ах, он станет настолько сложным, что его запиливать не станут.

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

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

А вот матрикс пока от аналогов ничем не отличается, кроме того что там json.

Киллер-фичи нет ни в реализации, ни в планах.

MERKLE TREE, MOTHERFUCKER. DO YOU SPEAK IT?

Ок, ты победил. Киллер-фичи нет. Конечно, её нет.

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

MERKLE TREE

Чего это и где мне его увидеть с точки зрения пользователя?

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

Само появление нового протокола делает лучше многим

с точки зрения пользователя

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

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

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

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

например Алиен и его клоны решили что для них в общении самое главное это синхронизация истории,

Не увидел этого

Разумеется. Потому что это ложь.

(Alien)

anonymous ()

Matrix Console Android

Количество установок
100–500

Удачи, Matrix, она тебе пригодится.

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

Давай ты сам подумаешь, почему 1) JSON-over-HTTP вместо бесконечного XML поверх голого TCP, 2) синхронизация состояния между серверами и подписываемая история, 3) распределённые конференции и 4) стандартизированный сигнальный слой для WebRTC — это лучше, чем всё, что есть по этому поводу в XMPP.

И это я не упоминаю стандартизированное end-to-end шифрование для конференций, которое сейчас дебажат и ревьюят.

Кстати, а что там за тысячи XEPов, которые «в матриксе никогда не реализуют»?

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

1) ничего не меняет, это просто формат. 3) есть в XMPP. 4) весьма сомнительно, учитывая что реализовать они его так и не смогли. А вот насчёт 2) интересно, но непонятно, как это сделано. Может круто, а может нет.

Кстати, а что там за тысячи XEPов, которые «в матриксе никогда не реализуют»?

http://xmpp.org/xmpp-protocols/xmpp-extensions/

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

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

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

нет

Велосипедисты в треде.

нормально

Если тебе реально не до фени техническая сторона чятега и у тебя нет сравнительно абстрактных требований, мне тебя жаль. Идите вон с intelfx, пилите велосипед свой. Мне все интересно, сколько нулей будет до единицы в проценте использования протокола. (=

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

быстрее

И все говно. Кстати, эта же проблема с Jabber - дофига клиентов, но всего 3 нормальных.

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

идейно правильнее

Сколько раз вам объяснить? Никому. Это. Не. Надо.

То же самое надо говорить и сторонникам Jabber, если сабж - Jabber, а обсуждать соцсети в треде.

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

нечего реализовывать

И что у вас получится? Кривая недоделанная поделка, которой противно пользоваться?

Видишь ли, со всеми няшками и умением в XEP я таки выкинул Psi+ в пользу Vacuum-IM. Ибо тупо слишком запарно перенастраивать UI.

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

Я имею ввиду, что «простой клиент» для matrix имеет все шансы разжирнеть в будущем, когда требования в очередной раз перевернутся с ног на голову :(

P.S. я скорее сторонник matrix, чем противник

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

Джва года жду нормальный свободный IM с работающей синхронизацией истории искаропки! Если сабж допилят, то будет очень хорошо. Ждём стабилизации и впиливания в популярные мультипротокольные клиенты (или хотя бы выхода отдельных вменяемых десктопных под все DE), иначе не нужно. Я понимаю, что имеющееся сейчас написано на скорую руку для удобства тестирования, но IM в браузере всё равно невыносимо отвратителен.

И парочка вопросов:

  1. Jabber-подобных приоритетов, как я понимаю, сейчас нету от слова «совсем»? А планируются ли?
  2. Предусмотрена ли возможность для клиентов хранить историю локально?
  3. Есть ли возможность гибкого управления синхронизацией истории? Например, по умолчанию клиент запрашивает с сервера историю за последние N дней/сообщений (по выбору), но не более M килобайт (опционально), запрашивая остальное on demand, и чтобы всё это можно было настроить отдельно для каждого контакта/конференции?
  4. Возможно ли в нём полное End-to-End шифрование переписки, сейчас или в перспективе? А синхронизацию истории это не будет ломать?
  5. Передаваемые файлы проходят через сервер (или несколько серверов), или же передаются от клиента к клиенту напрямую? Если через сервер, то сохраняются ли они на нём?
  6. Серверная история бесконечная? Если да, то что будет делать владелец сервера, если у него закончится свободное место и не будет возможности добавить нового? Если нет, то получается, старые сообщения будут пропадать? Предусмотрен ли какой-нибудь аналог Message Carbons, чтобы синхронизировать историю от клиента к клиенту?
  7. Android-клиент планируют добавить в F-droid или как?
  8. VoIP на андроиде уже работает?
anonymous ()
Ответ на: комментарий от anonymous

Jabber-подобных приоритетов, как я понимаю, сейчас нету от слова «совсем»?

Именно.

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

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

Предусмотрена ли возможность для клиентов хранить историю локально?

Это не регламентируется. Клиент может хранить историю, может не хранить историю, может хранить частично... Текущие клиенты историю не хранят (вебня) или хранят последние N сообщений (iOS/Android).

Есть ли возможность гибкого управления синхронизацией истории? Например, по умолчанию клиент запрашивает с сервера историю за последние N дней/сообщений (по выбору), но не более M килобайт (опционально), запрашивая остальное on demand, и чтобы всё это можно было настроить отдельно для каждого контакта/конференции?

Что касается клиентов — см. выше. Что касается серверов — там всё всегда реплицируется полностью.

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

Возможно ли в нём полное End-to-End шифрование переписки, сейчас или в перспективе? А синхронизацию истории это не будет ломать?

Полное e2e-шифрование сейчас в состоянии «вот ещё чуть-чуть и зарелизим». Синхронизацию истории это ломать не должно, поскольку на уровне сервера содержание сообщения никого не волнует, а на уровне клиента... ну, как настроить. Тут уж либо PFS, либо возможность чтения старых сообщений. Whitepaper можно почитать здесь.

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

Проходят через несколько серверов; в текущей реализации сохраняются на серверах (но это implementation-defined).

Серверная история бесконечная? Если да, то что будет делать владелец сервера, если у него закончится свободное место и не будет возможности добавить нового?

В текущей реализации — бесконечная и страдать соответственно.

Предусмотрен ли какой-нибудь аналог Message Carbons, чтобы синхронизировать историю от клиента к клиенту?

История передаётся только от сервера к клиентам.

Android-клиент планируют добавить в F-droid или как?

Планируют.

VoIP на андроиде уже работает?

Не в курсе, cc: alien.

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

VoIP на андроиде уже работает?

Да.

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

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

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

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

Может быть и так.

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

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

я уже устал за вашими месенджерами бегать

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

1) ничего не меняет, это просто формат.

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

3) есть в XMPP.

Неужели? А я всегда думал, что MUC в жаббере имеют ровно один центральный сервер...

4) весьма сомнительно, учитывая что реализовать они его так и не смогли.

Что значит «реализовать они его так и не смогли»?

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

идейно правильнее

Сколько раз вам объяснить? Никому. Это. Не. Надо.

Это надо разработчикам, которые будут писать под это дело клиенты и библиотеки.

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

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

будет уметь

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

MUC в жаббере имеют ровно один центральный сервер...

Угу, а теперь увидь ejabberd, кластеризацию в нем и прозрей.

Это надо разработчикам, которые будут писать под это дело клиенты и библиотеки.

Разрабам это нужно еще менее - давно есть соцсети и еще несколько я-не-такой-как-все-реализаций чатика, еще одну поддерживать - лишняя трудозатрата. Кому надо делать очередную НЕХ, когда работает другая? Разве что Леннарту, впрочем, не будем скатывать в поттерингосрач.

может (или в ближайшем будущем сможет) предложить хоть и немного, но достаточно важных вещей

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

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

Неужели? А я всегда думал, что MUC в жаббере имеют ровно один центральный сервер...

Не угадал. Есть XEP на межсерверные конференции.

Что значит «реализовать они его так и не смогли»?

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

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

intelfx , а зачем вообще в 2015 году, на заре тирании мессенжер с сервером?
Чтобы данные с сервера сливать спецслужбам можно было что ли?
Да, неясно как в чистом p2p сделать синхронизацию истории.
Но на самом деле можно ведь делать сопряжённую пару множество экземпляров клиента вошедших под одним пользователем и клиент робот, принимающий сообщения когда клиенты не в сети и при логине синхронизирующий историю.

К стати идея, предложу ка им это сделать.

Имхо лучше бы авторы Matrix к разработке tox присоединились.

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

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

В то же время безопасность достигается за счёт end-to-end-шифрования, устойчивость к отказам в обслуживании и захвату отдельных серверов — за счёт P2P между серверами (это называется федерация).

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

А теперь вопрос на миллион: чем этот клиент-робот будет отличаться от сервера в модели федерации? Не технически, а по степени доверия к нему.

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

Имхо лучше бы авторы Matrix к разработке tox присоединились.

Matrix и Tox — это совсем, совсем разные вещи. В этих проектах решаются разные задачи.

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

чем этот клиент-робот будет отличаться от сервера в модели федерации? Не технически, а по степени доверия к нему.

Тем что он у меня дома.

за счёт P2P между серверами (это называется федерация).

А в модели федерации сервера где? Тоже у пользователей?

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

Matrix и Tox — это совсем, совсем разные вещи. В этих проектах решаются разные задачи.

В смысле?
Мне нужен чат и тет а тет болталка.
У вас я понимаю так в клиенте будет тоже самое?

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

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

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

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

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

Другой вопрос, что ему белый IP-адрес нужен.

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

https://www.youtube.com/watch?v=7xRrktsNfyA

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

Matrix не нужно.

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

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

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

Неспроста в терминологии Matrix сервера называются «homeserver».

Каждая уважающая себя домохозяйка должна иметь в тостере маленький веб сервер.

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

P2P в матриксе существует только в отношении 1:1 VoIP звонков, и еще в jira есть тикет на разработку спецификаций для прямой p2p передачи файлов с использованием webrtc data channels (https://matrix.org/jira/browse/SPEC-146)

Если умеете - помогите проекту с SPEC-146. Прямые сверх-секюрные чаты (а-ля DCC) на том же принципе тоже обсуждались. Запрета на разработку нет.

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

Спасибо за ответы.

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

Просто глушить нотификации недостаточно. Простейший пример: допустим, у нас запущен Martix на десктопе и на телефоне. Пока десктоп активен, уведомления о сообщениях приходят только на него, а телефон в это время молчит. Потом мы отходим от десктопа, и он по таймауту выставляет у себя статус «Отошёл» или что-то вроде этого. Допустим, он перестал воспроизводить уведомления, но этого недостаточно: состояние телефона не изменилось, но теперь уведомления должен воспроизводить только он. Получается, клиенты должны иметь возможность узнавать о состоянии друг друга, чтобы понять, какие из них в данный момент активны.

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

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

Правила рассылки уведомлений энфорсятся со стороны сервера, насколько мне известно.

Кстати, как вообще обстоят дела со статусами?

«Как-то». Какая-то server-side эвристика. Кастомных статусов сейчас либо нет, либо нет в клиентах. Опять же, пинаем разработчиков — тем более что они давно соглашались с тем, что так жить нельзя.

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

жаббер

успешно выпилил гугл

Интересно, а как мне тогда на iamdexpl_на_гмыле сообщения приходят, и ответы уходят?

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

Интересно, а как мне тогда на iamdexpl_на_гмыле сообщения приходят, и ответы уходят?

Гугл пока оставил такую возможность, но в Hangouts xmpp уже не используется.

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

P2P в матриксе существует

Значит intelfx нагло врёт или ничего не знает.

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

Слой данных WebRTC (который действительно P2P) не имеет никакого отношения к протоколу Matrix.

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