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 ()

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

их идеи не очень вписывались в картину мира

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

Ломать другие протоколы в нужную им сторону

Зачем ломать? Можно реализовать XEP-ом иной способ передачи данных и установки соединений, BOSH тому пример.

Это уже демонстрация того, что оно является более агностичным к возможным задачам

уже отдано на откуп фантазии разработчика

Сферический понь в вакууме? Где эти фантазии-то, они хоть в теоретическом виде существуют, или существование таких фантазий — фантазия шматрицефанатиков? :DDDD

уже есть чаты на ActivityPub

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

утихомиря своё XMPP-фанбойство?

WUT? Мы вообще за конкретные мессенджеры не топим так-то. Как и за мессенджеры вообще, ибо находим форматы коммуникации, не дающие времени обдумывать сообщения, неудобными.

У нас расцвет технологий, каждая из которой приживётся в своей нише в конечном итоге

Нет, это называется зоопарком мессенджеров, который порядком подзадолбал пользователей, вынудженных держать ради разных людей кучу однотипных мессенджеров (кроме libpurple/Franz/транспортобогов, и то ограниченно ;)). Апологеты свободного ПО могли бы что-то сделать с этим зоопарком (поскольку причина этого зоопарка — венорлок — им чужд), предлагая единый свободный стандарт, но вместо этого они точно так же плодят зоопарк в виде Matrix, Tox, BitMessage, Ring и кого там ещё (у вас точно для всего этого зоопарка транспорты в шматрицу есть? ;)). Ждут, видимо, когда им власти наконец насадят единый стандарт, как это было с microUSB. И совершенно не факт, что этот стандарт устроит свободное сообщество.

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

Вы ещё POSIX, IP или Bluetooth фашизмом обозвите, ну-ну. Даёшь свой протокол в каждой сетевой карте, даёшь наушники только от производителя телефона!

mertvoprog ()
Ответ на: Ну дык... от Moisha_Liberman

Ну это к Вам вопрос, зачем исходники откапывать и зачем вообще что-то выковыривать — мешает, что ли? Оно даже в Интернет не лезет по дефолту, как и абсолютно весь прочий предустановленный софт — аппарат ещё из той эпохи, когда мобильный интернет был жутко дорогим и стучаться в фоне куда попало было моветоном ;)

mertvoprog ()
Ответ на: Отвечу сразу двоим. от Moisha_Liberman

Вот как раз лет десять назад мы и использовали то ли jabberd, то ли jabberd2 в качестве прообраза для своего подлия, которое вот уж около 10 лет просто работает. И в код ни кто особо не лазит. И проблем нет.

Это уже другой вопрос, и он никак не относится к доступности чата в случае, когда выключается сервер.

P.S.: к тому же, если вы не сталкивались с проблемами, то это не означает, что их нет, это означает, что вам повезло и вы с ними не сталкивались.

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

Это если сообщения дошли до его сервера с сервера отправителя.

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

Расскажите, пожалуйста, каким образом сервер xmpp должен понимать, что сообщение дошло до другого сервера, и каким образом, он может сделать повторную отправку?

ma1uta ★★ ()
Ответ на: Не... от Moisha_Liberman

Пока ещё нет.

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

сбор данных об абонентах

Чего там собирать? SIM и на связи-то появляться нужно лишь раз в год.

это основа биллинга и идентификации абонентов

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

они предпочитают работать на упреждение

Это если работой не завалены ;) Иначе, гоняясь за приколистами, шлющими через GMail слово «бомба», начнут прозёвывать реальные преступления.

обмениваться контактами только при личной встрече. Ножками.

WUT? Даже в прошлом веке ни разу не видевшие друг друга люди переписывались по почте (причём спокойно публиковали свои домашние адреса и телефоны, а не тряслись над защитой ПД, как и сейчас); а/я заводили полтора параноика. А в век фриланса/удалёнки и прочих знакомств по Интернету (взять хоть написанный ещё в 2007-м трек, двумя соавторами, живущими вообще в разных странах (Франция и Финляндия), и обменивающимися кусками файла по электронке) — высказывать подобное вообще бредово.

как лет 10 назад завели

10 лет назад шматрицы и не было ещё ;)

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

Это точно в протоколе IM должно быть что-то про виджеты?

Практика показывает, что если чего-то нет в протоколе, то оно реализуется через нижнее полушарие или совсем никак.

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

Для XMPP тоже надо реализовать сам клиент, да.

Так для XMPP за два десятилетия клиентов уже понаписано вагон и маленькую тележку, а для шматрицы за 6 лет до сих пор ни фига толкового нету, кроме жирноэлемента.

http fil upload

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

да только при реализации возникают такие вопросы, что проще выкинуть всё и велосипедить что-то своё

Неосиляторство, ясно. Под таким предлогом Метапроги всякие появляются ;)

об этом прямым текстом пишет автор транспорта

Авторы часто излишне самокритичны; хоть не сожгли, как второй том «Мёртвых душ» ;)

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

Не якобы, а да. При наличии ущербных нетекущих реализаций и неущербной текучей предпочтительнее второе, поскольку решаемо банальным супервайзером. Не telegram-purple же жрать, который криво пытается мапить имена на регистронезависимые JID’ы и даже супергруппы не может через Spectrum2 пробросить.

С таким же успехом можно сказать, что реализация element в виде web-клиента - это тоже проблема преувеличена (если это вообще проблема)

Ну дык шматрицефанатики так и вещают.

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

и он при этом не течёт

Ещё как течёт ;) Причём уже на старте дофига сжирает, так что и перезапускать бесполезно.

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

волнуют больше, чем задачи бизнеса™ и проблемы обычных пользователей

Matrix уже принимается как средство коммуникации и для бизнеса (государства, вроде Франции, некоммерческие организации, вроде Mozilla, коммерческие компании, вроде TeamSpeak), и для обычных смертных. Слушая претензии и бизнеса, и пользователей, делая продукт для них, способный конкурировать с другими сервисами на рынке. Потому что у Matrix есть ответственное лицо в виде Element, которое лично бегает ко всем подряд, спрашивая, как они могут стать лучше. Возможно ли такое в условиях ленивой XMPP-бюрократии, где способны только бумажки с XEP перебирать, отдавая реализации на откуп кому попало?

Можно реализовать XEP

Нельзя? То есть, текущий вид работы с данными в Matrix не прикрутить сбоку расширением. Сообщения являются чуть ли не блокчейном с математическим алгоритмом для сравнения разницы между состояниями истории событий N+1 серверов. Уже исходя из фундаментальной особенности такой работы реализовываются вообще вся последующая функциональность в Matrix.

они хоть в теоретическом виде существуют

А что тебе надо? Тебе даётся HTTP API, с помощью которого у тебя появляется возможность отсылать и хранить произвольные текстовые данные, и управлять идентификаторами. На основе этого уже можно запилить себе секцию комментариев на сайт, блог на этот сайт, аутентификацию на этот сайт, шифрование коммуникаций между пользователями на этом сайте. Это так, примеры с неба, которые уже реализованы. Помимо этого, по федерации можно обращаться к данным у других серверов. Сейчас в таком виде у нас есть децентрализованные списки блокировок, стикеры и эмодзи. Доступ по федерации к произвольным данным, вообще любым.

Да это-то не удивительно

А почему тогда с Matrix удивительно? Почему от одного чата тебя рвёт изнутри, а от другого нет?

Мы вообще за конкретные мессенджеры не топим так-то.

Эмпирически ты являешься XMPP-фанатиком, потому что каждый раз, когда заходит речь про Matrix, ты вылезаешь именно с ним.

Я пишу про Matrix, потому что вокруг него что-то происходит. XMPP мёртв в информационном поле, увы, я понятия не имею, что с ним происходит. Если бы у XMPP был такой же удобный формат новостной ленты, как у Matrix, где они еженедельно рассказывают о всех важных событиях, я бы и про ситуацию в XMPP писал. Про серверы ActivityPub я пишу, потому что ими пользуюсь. А ещё пользуюсь десятком других проектов, о которых тоже время от времени пишу. И проприетарщиной. Являюсь ли я от этого фанатиком чего-либо?

предлагая единый свободный стандарт

На каждый единый стандарт найдётся другой единый стандарт. Нет, такое не работает, работает конкуренция в рыночных условиях.

Вы ещё POSIX, IP или Bluetooth фашизмом обозвите, ну-ну

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

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

государства, вроде Франции

Где гарантии, что там не повторится мюнхенский сценарий?

вроде Mozilla

Которая сейчас в жопе из-за подобных решений, ну да ;)

способный конкурировать с другими сервисами на рынке

Не заметно. Когда догонят Telegram или хотя бы Signal, тогда и приходите. Пока что это столь же маргинальная поделка, как и жаббер.

отдавая реализации на откуп кому попало?

Зачем «кому попало»? Element «кто попало» пилят?

с математическим алгоритмом для сравнения разницы между состояниями истории событий N+1 серверов

И в чём принципиальное преимущество перед MAM? Ну кроме того, что MAM работает только от сервера к клиенту, а не в S2S? ;)

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

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

Сейчас в таком виде у нас есть децентрализованные списки блокировок, стикеры и эмодзи

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

Почему от одного чата тебя рвёт изнутри, а от другого нет?

Да рвёт и от того, ибо там отнюдь не только чатик, и это отдельная тема, которая уже обсуждалась в недавнем федивёрсотреде ;)

Эмпирически ты являешься XMPP-фанатиком, потому что каждый раз, когда заходит речь про Matrix, ты вылезаешь именно с ним.

А с чем ещё вылезать? С IRC? С e-mail?

А ещё пользуюсь десятком других проектов

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

работает конкуренция в рыночных условиях

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

на POSIX кладут кто только может

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

в текущих условиях означающее охренительное количество постоянно появляющихся и меняющихся задач

Вы о модных веяниях, и о том, как проприетарные мессенджеры друг у друга модные фичи воруют, являясь в итоге несовместимыми вариантами одного и того же с разной пользовательской базой? А шматрица нужна, чтобы новомодные плюшки оперативно воровать, забивая болт на всё остальное? ;)

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

Где гарантии, что там не повторится мюнхенский сценарий?

Никакой, но Matrix приняли ещё Германия и Нидерланды, потенциально ещё в другие государства пробъётся.

Которая сейчас в жопе из-за подобных решений, ну да ;)

Это не единственный пример.

Telegram или хотя бы Signal

Оно конкурирует со Slack и его клонами.

Зачем «кому попало»? Element «кто попало» пилят?

Упоролся? XMPP реализует кто попало. Энтерпрайзы, вроде ProcessOne, у которых ejabberd с нужной функциональностью проприетарный и вообще SaaS-only местами, а у сообщества кастрат.

И в чём принципиальное преимущество перед MAM?

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

https://github.com/matrix-org/matrix-doc/blob/master/proposals/1442-state-resolution.md

чатик в виде набора сообщений, только представления иные

С фига ли отправленный нейтральный JSON стал сообщением чатика? Это сообщения чатика являются JSON-объектами, и называем мы их сообщениями потому что клиент внешне рендерит это как сообщение, потому что оно имеет тип сообщения. А ещё есть JSON-объекты, которые не являются сообщениями, их в чатиках нет. Такие события отвечают за состояние комнаты и аккаунта.

Например, есть тип JSON-объектов im.ponies.room_emotes в комнате — его нет в спецификации, он был добавлен какой-то понёй в комнату. Эта поня хочет с помощью этого типа записывать в состояние комнаты информацию об эмодзи. После отправки нескольких событий в комнату с добавлением эмодзи, они будут доступны в каждом клиенте, который реализует использование такого типа JSON-объектов. С любого сервера в сети, который есть в этой комнате. Даже если сервер, откуда эти эмодзи добавили, помрёт.

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

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

распределённое хранилище файлов

Файлы реплицируются между серверами и доступны в виде внутрипротокольных MXC-ссылок.

https://gospel.sunbutt.faith/_matrix/media/r0/download/sunbutt.faith/11b0dbe2b0c03fd2b76bed6d3c33da937c6518ee
https://matrix.inex.rocks/_matrix/media/r0/download/sunbutt.faith/11b0dbe2b0c03fd2b76bed6d3c33da937c6518ee
https://ru-matrix.org/_matrix/media/r0/download/sunbutt.faith/11b0dbe2b0c03fd2b76bed6d3c33da937c6518ee
https://matrix.org/_matrix/media/r0/download/sunbutt.faith/11b0dbe2b0c03fd2b76bed6d3c33da937c6518ee
https://disroot.org/_matrix/media/r0/download/sunbutt.faith/11b0dbe2b0c03fd2b76bed6d3c33da937c6518ee

Здорово, правда?

А с чем ещё вылезать?

По возможности не вылезать, пожалейте время больного на голову поне.

агрессивно не форсим

Пару новостей в месяц в лучшем случае на мёртвом LOR. =/

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

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

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

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

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

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

Типа такого: XMPP Compliance Suites 2020?

Оно почти каждый год обновляется (2019, 2018, 2016 ... 2009).

Ну как, это решило проблему? 😉

созданием сверхстандарта

Обязательная ссылка на https://xkcd.ru/927/

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

потенциально

Скоро, скоро, очень скоро ©

Оно конкурирует со Slack и его клонами.

Будто Slack с его клонами не является частью одного большого зоопарка, который хорошо бы объединить и заменить полностью, а не по нишам ;)

XMPP реализует кто попало

Matrix-клиенты тоже, но к Element это отношения не имеет ведь. Так при использовании XMPP почему их должно было бы волновать, кто там чего с XMPP делает и какие XEP-ы шизики пропихивают?

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

Это всё можно реализовать служебными сообщениями, зачем сущности плодить? ;)

Что из этого MAM реализует?

О том и речь, что не реализует, потому что не для S2S. Так сделали бы для S2S, зачем сущности плодить? Причём не обязательно в виде DMUC, можно синхронизировать с локальной историей каждого пользователя, минуя сервер, с которого пользователь подключается к MUC на другом сервере.

С фига ли отправленный нейтральный JSON стал сообщением чатика?

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

они будут доступны в каждом клиенте, который реализует использование такого типа JSON-объектов

А остальные видеть не будут без какого-либо фоллбэка, да? XMPP-шные сообщения <body> ... </body> так или иначе имеют, все прочие навороты типа XHTML кладутся в иные теги.

Даже если сервер, откуда эти эмодзи добавили, помрёт.

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

Вся история событий реплицируется между участвующими серверами, всегда

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

пожалейте время больного на голову поне

Вас кто-то заставляет отвечать? (Как и Нас, впрочем…)

Пару новостей в месяц

Это типа мало?

мёртвом LOR

Которое он там десятилетие умирает уже?

и не вымещают друг друга каждые несколько лет?

Представляете себе — нет. Попробуйте-ка выпереть Viber из Украины или WeChat из Китая ;) Или Skype из местного фриланса. Они захватили рынок и выйдут с него уже только вперёд ногами.

Есть чем хвастаться

Зато клиентов нету, ага.

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

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

А в некоторых клиентах это даже по дефолту делается. И это — ПЛОХО. Потому что я могу кинуть в чат ссылку на свой хостинг, и получить айпишники всех членов чата, даже без их ведома.

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

Потому правильный обмен файлами — всегда через сервер. И правильный клиент должен автоматически общаться ТОЛЬКО со своим сервером. Никаких сторонних хостингов.

LightShot так и делает, только сразу же выгружает и короткую ссылку даёт ;)

Тогда уже FlameShot, чтобы онтопик. 🙂

Но это всё равно требует лишних действий с обоих сторон. Просто вставить картинку в чат — проще, быстрее и удобнее.

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

От видосов сервер должен отдать превьюшку и размер. Качаться видео будет тогда, когда юзер начнёт его смотреть. И выгружать его полностью и не надо — стриминг же!

Нет, продукт — Element.

Вопрос терминологии. Для меня Matrix — это продукт, у которого клиент Element (бывший Riot, который бывший Vector), сервер синапс, и инфраструктура настроенная и поддерживаемая Matrix Foundation. Но если вам больше нравится называть всё это словом «Element», пусть будет так.

Потому что то, что шматрицефанатики пилят свой нескучный протокол вместо улучшения XMPP — уже само по себе проблема.

Почему? Это их выбор. Они хотели протокол, над которым они имеют полный контроль, и могут менять его как хотят.

Они ведь начали свой продукт. Почему они должны были брать за основу именно XMPP? Почему не IRC, или AIM, или Skype, или ещё какой-то? И зачем им вообще брать XMPP и реализовывать все его фичи, если они им не нужны? Например, им не нужны ресурсы, но XMPP нельзя реализовать без механизма ресурсов.

Протокол Matrix был простым HTTP+JSON long polling протоколом, легко реализуемым и в вебе, и в мобилках. В смысле, тогда в 2015м он таким был — простой протокол для передачи текста/файлов/webrtc. Он был даже проще IRC, но новее и с большим числом фич.

А потом его начали допиливать, федерация, шифрование... Постепенно он разросся.

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

Файлы реплицируются между серверами и доступны в виде внутрипротокольных MXC-ссылок.
[...]
Здорово, правда?

О! Вопрос про репликацию знатокам матриксопротокола: а откуда эти ссылки берутся?

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

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

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

(если не помните или долго объяснять — ткните в пункт протокола, я там почитаю)

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

и получить айпишники всех членов чата

Будто IP являются ценностью большой. Ну и никто не мешает вайтлист сделать.

хостинг может сдохнуть, или картинка исчезнуть

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

чтобы онтопик

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

Просто вставить картинку в чат — проще, быстрее и удобнее.

Речь не о том, чтобы её как-нибудь вставить; речь о том, что с ней будет после.

И выгружать его полностью и не надо — стриминг же!

Где это Вы видали прикрученный к мессенджеру стриминг? Совсем упоролись.

Для меня Matrix — это продукт, у которого клиент Element (бывший Riot, который бывший Vector), сервер синапс, и инфраструктура настроенная и поддерживаемая Matrix Foundation

Ну охренеть, а всё остальное, что протокол поддерживает, тогда что?

Это их выбор

Так, ну тут уже к 5.3 катится.

Почему не IRC, или AIM, или Skype, или ещё какой-то?

IRC слишком уж примитивный (даже мультистрочных сообщений до сих пор нет), остальное проприетарное. XMPP по фичесету вполне может потягаться с Matrix; ключевая проблема именно в том, что им друг с другом приходится тягаться, то есть распылять усилия. Пока шматрицефанатики пилят кучу шматрицеклиентов, жабберонекрофилы пилят всякие консервы с динами и даже XEP-ы новые продолжают штамповать. В итоге ещё больше разброда и шатания.

тогда в 2015м он таким был

Причём от того уже ничего не осталось толком. А Jabber-клиент эдак 2002-го года вполне может подключиться к современному серверу.

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

У каждого сервера есть свой «content/media repository», куда складируются все загруженные файлы с присвоением уникального ID. На файловой системе это будет выглядеть как /matrix-for-yourserver.com/media/yourserver.com/some-id-of-a-file. Клиент может загрузить файл на сервер с помощью API, даже не находясь в какой-либо комнате, в ответ получив от сервера идентификатор файла.

Когда клиент находится в какой-то комнате, он может отправить этот файл для публики в виде JSON-события, типом которого будет являться файл, а в описании будет указан идентификатор ранее загруженного файла на сервер. Такие события, вместе с обычными сообщениями и вообще всеми другими вещами, составляют DAG — линейную историю событий. Эта история событий всегда реплицируется между серверами. Каждый сервер хранит свою копию DAG комнат.

Когда в чат присоединяется новый сервер, он начинает процесс копирования истории DAG. В этой истории событий есть отправленный нами файл, поэтому новый сервер просит у старого сервера отдать ему этот файл, чтобы скачать его себе локально и отобразить его для своих клиентов. Этот файл копируется и на новом сервере попадает на файловую систему в виде /matrix-for-anotherserver.net/media/yourserver.com/some-id-of-a-file.

https://matrix.org/docs/spec/server_server/r0.1.4#content-repository
https://matrix.org/docs/spec/client_server/r0.6.1#id66

То есть, MXC-ссылка является URI в виде «исходный сервер, по адресу котого нужно искать в локальном кэше скопированный репозиторий контента ИЛИ адрес сервера, у которого этот репозиторий надо запрашивать, если он отсутствует в локальном кэше» + «внутренний идентификатор файла, заданный в контексте этого репозитория контента».

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

Будто IP являются ценностью большой. Ну и никто не мешает вайтлист сделать.

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

(это — тоже вопрос к продукту, а не к протоколу)

Может, речь именно о том, что устраняется единая точка отказа. Если хостинг присобачен к Jabber-серверу, то сдохнет он весь и сразу.

Если сдохнет мой jabber-сервер, то я и залогиниться не смогу, не то что картинки смотреть. А если я могу залогиниться, то и картинки я точно увижу. Если, конечно, они передаются через сервер, а не через внешний хостинг.

Речь не о том, чтобы её как-нибудь вставить; речь о том, что с ней будет после.

С точки зрения протокола — не важно. Пусть хранится на сервере отправителя (в его истории) и на сервере получателя (в истории получателя). Главное, что получатель должен увидеть эту картинку сразу, без внешних хостингов.

Где это Вы видали прикрученный к мессенджеру стриминг? Совсем упоролись.

Хм... Сейчас по памяти всех не вспомню. Skype? Да и в Hangouts видео по факту приходит в виде ссылки, её можно смотреть не выгружая. В вайбере, точно помню, видео скачивается, но там большие видео передать нельзя. А слак, вроде, не выгружал, тоже смотрел онлайн.

Ну охренеть, а всё остальное, что протокол поддерживает, тогда что?

А всё остальное это... что?

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

Примитивный == простой. Это хорошо же! Хотя в IRC тоже не всё просто (actions (/me), цвета, контакт-лист, не говоря уже про передачу файлов и оффлайн-сообщения)...

Многострочные сообщения, кстати, спорный момент. Безопаснее, когда каждая строка — отдельное сообщение.

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

Причём от того уже ничего не осталось толком.

Совместимости нет. Но идея осталась — это всё ещё REST HTTP+JSON, пусть и с кучей наворотов. На базе XMPP такое не построишь.

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

Благодарю за пояснение!

Когда в чат присоединяется новый сервер, он начинает процесс копирования истории DAG.

Вот! Вопрос по этому месту — новый сервер обязан скопировать себе всю историю целиком? То есть все сообщения и все выложенные в этом чате файлы с момента основания чата?

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

Сервер обязательно должен совершить «initial sync», загрузив все события в комнате касающиеся того, кто из неё вошёл и вышел. Вроде бы, да, с самого начала её существования.

Не помню точно, но все остальные события, включая обычные сообщения, вроде бы, подгружаются по запросу. Сейчас идёт работа над оптимизацией этого процесса и введением «lazy loading» куда только возможно.

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

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

Я имел в виду...

Мобилы/смарты на том же ведре. Т.е., явно современнее чем тот же Siemens SL45 (Вы часто поминали J2ME, вот мне и вспомнилось). На тех мобилах мало что в Сеть без спросу вообще лезло. Точнее, ни чего не лезло и Вы тут правы – мобильный интернет тогда был дорог.

Это сейчас если хочется приватности, то AOSP в руки и вперёд за компиляцию. Интернет же дешёвый, пара мегабайт туда-сюда, пользователь и не заметит. А инфы о пользователе утечёт много. Ну, точнее, больше чем хотелось бы. Так что, либо кнопочный мобильник, без изысков, либо пересборка прошивки с вышибанием из неё дерьма, ну либо что-то INOI’e. Выбор невелик.

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

Вообще-то, нет.

Сервер А ни как не может и не должен знать дошло ли сообщение до абонента сервера Б. Это не его задача. Сервер А отправил сообщение на сервер Б через s2s, а дальше пусть сервер Б разбирается. Точно так же, как и в случае с e-mail. В большой сети, с большим числом серверов и большим числом абонентов, Вы гарантированно положите сервак, если будете контролировать всю сеть своих серверов-корреспондентов. Для этого сервера и делаются максимально независимыми друг от друга.

Если какой-то сервер Б временно улёгся, то на сервере А сообщения должны храниться либо до момента, когда сервер Б поднимется снова, либо некий разумный временно́й интервал. После этого они должны быть удалены. Иначе мы получим «атеросклеротические бляшки» в протоколе. И сервер (его очереди) может быть забит неактуальными и давно стухшими данными.

Больше ни как.

доступности чата в случае

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

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

Хэх! =)

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

Рыночек-рыночком, но в гробу я видел колупать прошивку некоего девайса с лопатофона. Честно. Даже на хорошем серваке. Уж лучше локально.

SIM и на связи-то появляться нужно лишь раз в год.

Да нет. Всякий раз при перерегистрации. Даже если на месте сидеть, то как минимум несколько раз в день (на память интервал уже не помню), а если на машине/метро будете мотыляться, то всякий раз, как будете менять зону LA, даже находясь в пределах своего HLR (своей сети). Так что, не волнуйтесь. И гугль и опсос знают точно где Вас найти. =)

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

Да прямое же! Без опсосовской инфраструктуры мессенджер работать не будет. А дальше есть прямая связь. Мобила, пользователь, сообщение, реквизиты сообщения. И вовсе необязательно в случае «если чё», запрашивать гугль. Или Вы думаете что в ряде случаев, когда в деле о терроризме фигурировали данные из телеги, то запрашивали серваки телеги? Я бы не был столь однозначно уверен. Лучший сервак мессейнджера это тот, который Вы контролируете и где лишних людей просто нет. Так всем проще. =)

Это если работой не завалены ;)

У них свои методы. Как-то справляются… =)

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

К моему величайшему сожалению, мир несколько изменился. И не в лучшую сторону. Я, живя в России, даже здесь, на ЛОРе, использую одну качественную и не убитую ноду Тора. Когда-то да, интернет был вполне безопасным местом. Сейчас излишняя открытость до добра не доводит. Если не прямой взлом, то неприятностей с мамкиными хакки́рами будет выше крыши. Лень так время убивать.

10 лет назад шматрицы и не было ещё ;)

Господи! Да пусть будет! =))) Я же написал уже что для мессейнджера жаба вполне годна. Для VoIP в любом сраном мобильнике есть клиент и на десктопе тоже есть. Астериск свой. Для видеочата есть свой stun/turn/ice сервер. Нигде без аутентификации не пролезешь. Я просто отбираю лучшее из букета технологий.

Сейчас вон, заказ есть на некую информационную систему. Там должен быть некий вебчат. С видео. Я Вам сразу скажу что это будет решение на WebRTC, но на своих серверах. Если кому-то нравится Матрикс, то почему бы и нет? Мне вот не нравится. Тоже в своём праве. =)

P.S. Пожалуй, добавлю. Знаете в чём разница между моим поколением (рождённые в конце 60-начале 70гг.) и современным? Нет, не в том, что мы не способны учиться новому. Мы-то как раз усвоили, что если остановился, то помер. Так что, учимся каждый день. Разница в том, что мы использовали интернет для передачи мыслей, а зумеры его используют для передачи эмоций. Мы привыкшие к longread’ам, «стенам текста», где человек развёртывант свою мысль. А зумерам подавай в формате sms/твита. Какую мысль Вы «утопчете» в 140 байт? Пару эмодзи, разве что. Вот почему им нужна сеть, где всё в одном. И текст и аудио и видео. Им нужна сеть аудио-видео. Текст им не важен. Поэтому и e-mail считается умирающим способом общения. Текст же, читать надо, думать. Вот в чём причина.

Существующие недостатки xmpp? Конечно они есть. Но менять рабочее решение на… что-то новое, только потому что это новое… Ну это как вместо сгоревшего предохранителя в машине, поменять всю машину. Можно, но смысла не вижу. ;)

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

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

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

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

Gitter после покупки компанией GitLab стал полностью бесплатным. После перекупки компанией Element он так же остаётся бесплатным, у них нет никакой коммерческой основы. В начале своего существования они продавали подписку командам, как Slack.

Element зарабатывает на продаже SaaS, тех. поддержки, развёртывании серверов по заказу и получает донаты/гранты.

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

Чем Gitter лучше Element? Хуже. Они просто купили пользовательскую аудиторию, по сути.

У Gitter помимо достаточно сносной отзывчивости интерфейса и интеграции с GitHub/Lab ничего нет, проект загибался.

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

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

Обычные сообщения можно и все выкачать. Это просто текст. И даже 100 мегабайт текста — не проблема с современным инетом.

Вопрос именно по MXC-ссылкам — их тоже каждый сервер должен выкачать к себе ВСЕ? А то ведь в какой-нибудь конфе с котиками все картинки могут занимать сотни гигабайт.

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

Не-не. Как раз так оно и не сработает.

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

Допустим, у нас lazy loading, и мой сервер запрашивает только то, что спросил мой клиент. А клиент старые сообщения не читал, поэтому мы ничего не загрузили. Пока всё хорошо.

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

Что делать? Где взять те старые сообщения и старые фотки из них?

Вот и получается, что либо распределённость (но качаем всё), либо lazy loading (но дохнем при уходе сервера). 🙂

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

костыль, подпирающий изначально кривое решение (внешний хостинг)

Нет в юниксвее ничего кривого. Чатику — чатиково, хостингу — хостингово.

Ведь чат должен быть удобным и безопасным из коробки

Нишевые требования сноуденопараноиков.

Если сдохнет мой jabber-сервер, то я и залогиниться не смогу, не то что картинки смотреть

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

С точки зрения протокола — не важно

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

Главное, что получатель должен увидеть эту картинку сразу, без внешних хостингов

Нельзя её увидеть «сразу», Вы чушь несёте. Чтобы увидеть картинку, надо её сначала скачать. Откуда — неважно.

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

Skype?

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

в Hangouts видео по факту приходит в виде ссылки

Там штатными средствами только картинки прикреплять можно. Или Вы о видеозвонках?

смотрел онлайн

А онлайн смотрят непременно стримы, что ли? Если видеофайл по ссылке открыть, он тоже может скачиваться и по ходу воспроизводиться. Стриминг — это потоковое видео, когда, допустим, пользователь начинает записывать видео, и его уже могут смотреть, а не лишь после того, как запись будет окончена. И такого в мессенджерах вроде нету ещё.

А всё остальное это… что?

А это уже шматрицефанатиков спрашивайте, Мы всего не упомним. Dendrite, Nheko, Quaternion, matrix-archive, matrix-client-el, purple-matrix, кто там ещё…

Примитивный == простой. Это хорошо же!

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

И всё, чат больше не почитаешь

Сфига? Удаление сообщений не завезли? ;)

REST HTTP+JSON

Это настолько абстрактно, что под него значительная часть прочих мессенджеров подпалает. Но не XMPP, конечно ;)

mertvoprog ()
Ответ на: Я имел в виду... от Moisha_Liberman

Я имел в виду… Мобилы/смарты на том же ведре.

А к чему Вы его приплели? ;) Там клиенты для WirelessVillage запихивали? Для RCS вот пропихивают.

либо кнопочный мобильник, без изысков

У Вас какие-то стереотипы о кнопках? Фичерфоны и кнопочные смартфоны ещё не вымерли окончательно. KaiOS вообще пушка.

mertvoprog ()
Ответ на: Хэх! =) от Moisha_Liberman

но в гробу я видел колупать прошивку некоего девайса с лопатофона

Ну будете скоро отваливать кучу бабла за свои хотелки.

всякий раз, как будете менять зону LA, даже находясь в пределах своего HLR (своей сети)

WUT? Вы так говорите, будто в обесточенной и вынутой SIM’ке передатчик есть.

Без опсосовской инфраструктуры мессенджер работать не будет

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

Лучший сервак мессейнджера это тот, который Вы контролируете и где лишних людей просто нет

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

Когда-то да, интернет был вполне безопасным местом

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

Какую мысль Вы «утопчете» в 140 байт?

А есть ли у них вообще мысли? ;) Впрочем, Вы так говорите, будто эту аудиторию не стоит брать в расчёт.

Поэтому и e-mail считается умирающим способом общения. Текст же, читать надо, думать.

Вложения не осилили, что ли?

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

Копроэкономика так и работает.

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

Да я про WirelessVillage и не подумал даже.

Мне вообще не нравится идея, когда на базе carrier’s network чего-то гондобить начинают. Всё таки, опсос и провайдеры услуг должны быть разные. Ненужно все яйца в одну корзину складывать.

У Вас какие-то стереотипы о кнопках? Фичерфоны и кнопочные смартфоны ещё не вымерли окончательно.

Вообще-то, в ряде случаев я бы предпочёл не фичерфон, а самый что ни на есть dumb phone. Если бы у меня были задачи, требующие такого уровня отношения.

KaiOS

Спасибо, не. «Наелся». Это сразу в Африку.

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

Ага...

Ну будете скоро отваливать кучу бабла за свои хотелки.

И куда заказчик денется? Отвалит... =))) Бесплатно уже давно не работаю.

WUT? Вы так говорите, будто в обесточенной и вынутой SIM’ке передатчик есть.

Так мы о мобиле или об отдельных частях? Да и потом. Если Вы вздумаете позвонить, то IMEI даже с другой симкой засветится в логах контроллера. Самый простой выход в таком случае — вообще не иметь мобилы.

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

Ну а как? Как Вы предлагаете *с мобилы* выйти в интернет (хоть мессейнджером, хоть нет), минуя инфраструктурное оборудование опсоса, все эти ggsn/sgsn и прочее? Единственное, что приходит на ум, это RFC 1149, IP over Avian Carriers. =)))

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

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

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

Вот только даже раньше там не все телефоны публиковались. И даже во времена СССР. От райкома и выше, уже нет.

Впрочем, Вы так говорите, будто эту аудиторию не стоит брать в расчёт.

Стоит. Но редко. Иначе есть все шансы деградировать.

Moisha_Liberman ()
Ответ на: Да я про WirelessVillage и не подумал даже. от Moisha_Liberman

когда на базе carrier’s network чего-то гондобить начинают

Так пользователи к этому склоняют. Для них мобильные мессенджеры — просто удобная и дешёвая замена SMS/MMS.

Это сразу в Африку.

Ну где-то там и востребовано ;)

mertvoprog ()
Ответ на: Ага... от Moisha_Liberman

Так мы о мобиле или об отдельных частях?

Мы о привязке мессенджеров к номеру.

Если Вы вздумаете позвонить

Зачем? Достаточно принять SMS — всё.

вообще не иметь мобилы

А и не обязательно в мобилу SIM пихать, можно в свисток или ещё чего-нибудь потупее.

Как Вы предлагаете с мобилы выйти в интернет

А при чём тут мобила? Ну и кагбэ вайвай в мобилах давно есть ;)

ненужно фигнёй заниматься, чтоб не вламывались

Вы же выше писали, что всё равно превентивно вломятся.

От райкома и выше, уже нет.

Это пустяки ;) Вы бы ещё потребовали, чтобы лично генсеку все желающие могли дозвониться. Как сейчас Трампу в твиттырь пишут и Зеленскому в пейсбук.

Иначе есть все шансы деградировать

А аудитория за счёт этого немного поумнеет. Диффузия в обе стороны работает ;) А в противном случае Ваше поколение со временем уйдёт в небытие, а эта аудитория — останется.

mertvoprog ()
Ответ на: Дык. от Moisha_Liberman

Если бы пользюки хотя бы понимали к чему именно это всё ведёт…

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

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

Не...

Мы о привязке мессенджеров к номеру.

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

Зачем? Достаточно принять SMS — всё.

Ни обмен звонками, ни обмен SMS без регистрации в сети невозможен. Так что, можно даже не слать SMS. Для простоты, хоть это и не совсем так, как только Вы включили мобилу, секунд через несколько, она уже известна HLR и уже можно сказать где находится абонент. Пативэн уже можно в адрес высылать.

А и не обязательно в мобилу SIM пихать, можно в свисток или ещё чего-нибудь потупее.

Не. У некоторых российских адвокатов уровня Генриха Падвы вообще мобил нет. У них есть помощник с мобилой. Отдельно взятым «товарищам» вообще покупали каждый месяц по новой мобиле и по новой SIM-карте, регистрируя их на карту на какого-то бомжа. Не спасает. =))) Люди слабое звено. И технические ухищрения тут не работают.

А при чём тут мобила? Ну и кагбэ вайвай в мобилах давно есть ;)

Сильно удивлю, если скажу что одно из популярных мобильных приложений (сам анализировал) собирало данные о WiFi точках доступа в округе и сливало эту инфу на сервера? Так что… ;)

Вы же выше писали, что всё равно превентивно вломятся.

Где как не знаю, но в РФ ещё надо такое особо нежное к себе отношение «выпросить». Превентивно-то превентивно, но тут своя очередь есть, наверное… =))) Пока ко мне вот, тьфу-тьфу-тьфу…

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

Ну вот мы и добрались до этой самой privacy. Напомню, что в РФ нельзя собирать досье на граждан. Ааа… Зачем? Есть же соцсети.

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

По подсчётам одного довольно интересного антрополога, человечеству лет 200-300 осталось. Всего. Если не меньше. «Закон должен быть исполнен». См. Апокалипсис. ;) Так что, всему своё время.

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

Эммм...

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

Насчёт прослушивалась больше я бы поспорил. Можете погуглить про систему «Эшелон», которая начала работать в конце 40-х годов в Западной Европе на телефонных и телеграфных сетях и далее стала распространяться, требовала человеческих ушей и глаз. В цифровом мире это куда как проще реализуется. Вопрос только в ёмкостях винчестеров и скорости доступа.

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

Нет в юниксвее ничего кривого. Чатику — чатиково, хостингу — хостингово.

Юниксвей — про отдельные инструменты. А «чатик» — это продукт, сложная комбинация инструментов.

Многие этого не понимают, но «юниксвей» не говорит, что всё должно быть простым и убогим. Он говорит, что сложные вещи можно создавать простыми инструментами.

Нишевые требования сноуденопараноиков.

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

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

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

Нельзя её увидеть «сразу», Вы чушь несёте. Чтобы увидеть картинку, надо её сначала скачать. Откуда — неважно.

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

Первый случай — удобнее, быстрее и безопаснее. А какие минусы?

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

Андроидный hangouts умеет отправлять видео.

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

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

А это уже шматрицефанатиков спрашивайте, Мы всего не упомним. Dendrite, Nheko, Quaternion, matrix-archive, matrix-client-el, purple-matrix, кто там ещё…

А это остальное — это эксперименты комьюнити. Попытки интересные, но не часть продукта.

И всё это либо заброшено, либо эксперименты, либо пока не допилено («a proof of concept»), и «should only be used for testing purposes».

Типа как whatsapp-purple — для гиков забавно, но для обычных юзеров не годится, и к продукту Whatsapp отношения не имеет.

REST HTTP+JSON

Это настолько абстрактно, что под него значительная часть прочих мессенджеров подпалает. Но не XMPP, конечно ;)

Да. Вот поэтому они и не взяли XMPP за основу. Без всяких идеологии, «застарелых проблем» и другого фанатизма. Он просто был для них неудобен.

Сфига? Удаление сообщений не завезли? ;)

Куда? В MAM (XEP-313)? Нет, не завезли. 🙂 В message archive (XEP-136) завезли, но его ни один клиент не умеет.

А даже если бы умел, каждое удаление — это ручное действие на пол минуты, а отправлять тыщу пустых строк можно хоть каждую секунду. И это даже без изощрений, типа unicode of death.

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

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

Так для XMPP за два десятилетия клиентов уже понаписано вагон и маленькую тележку, а для шматрицы за 6 лет до сих пор ни фига толкового нету, кроме жирноэлемента.

Можно хотя бы три клиента, которые хотя бы дотягивают до Element? Чтобы и реплаи были, и пуши по-человечески работали, а не как в conversations? И чтобы хотя бы можно было бы увидеть, какие устройства подключены к аккаунту?

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

Неа, не работает, т. к. каждый клиент занимается костылестроениями, чтобы побороть базовый протокол. К примеру, замечал, что собеседники, которые сидят с conversations постоянно спамят станзами входа и выхода с причиной «Replaced by new connection»? Это одна из попыток побороть «базовый протокол», который работает через одно место.

Авторы часто излишне самокритичны; хоть не сожгли, как второй том «Мёртвых душ» ;)

Тем не менее он течёт, когда аналогичный по функционалу мост в matrix - нет.

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

Вот только https://github.com/tulir/mautrix-telegram обладает таким же функционалом как и жабограмм, то есть выбор между двумя реализациями с одинаковым функционалом, только одна реализация течёт, а вторая нет. И выбор почему-то отдаёт реализации, которая течёт. Л - логика.

Ну дык шматрицефанатики так и вещают.

Ну то есть жабберофанатики ничем не лучше матриксфанатиков, ладно.

Ещё как течёт ;) Причём уже на старте дофига сжирает, так что и перезапускать бесполезно.

Это, конечно же, вы не выдумали, и у вас есть пруфы, которыми вы можете поделиться?

ma1uta ★★ ()