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

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

Толку в таком случае от смузихлёбов, что они наплодили xep-ов, если ими никто не пользуется?

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

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

Ну-ну ;) Мы вот вчера ещё одну печальное зрелище обнаружили: шматричные клиенты, оказывается, при посылке body и formatted_body кладут в body не просто плейнтекст, а плейнтекст с исходной разметкой, в том числе велосипедной, которую другие клиенты понимать не обязаны. И эта разметка пугает получателей, почистить её в общем случае и нельзя, выходит. В то время как джабберный XHTML кладётся в отдельный тег, а в <body></body> чистый плейнтекст.

хочу переустановить приложение на мобильном устройстве

Дебилизм. Ещё шындовз переустановить предложите ;)

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

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

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

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

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

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

В адекватном протоколе есть

Протокол протоколом, а пущай клиенты научатся :P Пришлось руками переносить, файликом. Даже не строчкой.

Как это сделано в xmpp? Или это не нужно?

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

избитые мантры

Мантры у Вас в голове ;) Нас так в вялендосрачах в мантрах про сетевую прозрачность иксов обвиняли, хотя Мы про неё и не заикались никогда.

здесь что забыли?

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

Более того, я уже неоднократно показывал, что в «базовом протоколе» xmpp есть проблемы, которые ни за 10 лет, ни сейчас никто не решает.

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

Даже если клиент разросся до 2 гигабайт, но их все использует - то это не утечка

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

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

Которую?

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

Это отнюдь не с потолка; нафиг нужен одноразовый чат, который не пишет логи?

Начнём с того, что клиенту не нужно хранить историю (вопрос на звёздочку - объяснить почему так), это задача сервера. Только вот что и IRC, что в XMPP «базовый протокол» так хорошо работал, что либо лепили костыли, чтобы на клиентах хранить историю, либо добавляли новые сущности (irc bounce). И эту багу сделали фичёй. Правда потом прикрутили XEP-0313, но работает оно порой через одно место: https://xmpp.is/2019/02/11/status-update-on-mod_mam/

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

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

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

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

И в случае с мостом наличие этого самого моста явно видно для посетителей чата, даже если мост — не просто клиент, а имплементит своё пространство юзернеймов, то видно, что это юзернеймы этого моста; транспорт же — это клиент-марионетка; в идеале только пользователь знает, что сидит через транспорт из мессенджера2, а не с клиента к мессенджеру1 ;)

Не обязательно явно видно, можно легко сделать, чтобы в xmpp в muc сидело три участника, но только двое из них - это отображение других участников из matrix к примеру. В итоге что видит xmpp-пользователь - конференцию где переписываются три участника, а matrix-пользователи видят комнату, где тоже три участника, только по факту там 2 человека сидят в matrix, а один в xmpp. И это ещё молчим про s2s-мосты, которые связываются на уровне протокола.

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

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

Что за чушь вы несёте? Почитайте про OAuth2, и тогда, возможно, поймёте, что OAuth2 - это ни про какую привязку к левому сервису. Вы, возможно, путаете SSO (Single-Sign-On).

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

У вас с логикой беда.

Во-первых, в xmpp есть вышеозвученные проблемы, в matrix их нет. Смысл тогда использовать xmpp и мучиться с проблемами, если есть протокол, где этих проблема нет?

Во-вторых, с такой логикой XMPP не нужно, т. к. есть FidoNet и IRC.

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

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

Т. е. xmpp только для смузихлёбов раз больше некому пользоваться?

Ну-ну ;) Мы вот вчера ещё одну печальное зрелище обнаружили: шматричные клиенты, оказывается, при посылке body и formatted_body кладут в body не просто плейнтекст, а плейнтекст с исходной разметкой, в том числе велосипедной, которую другие клиенты понимать не обязаны. И эта разметка пугает получателей, почистить её в общем случае и нельзя, выходит. В то время как джабберный XHTML кладётся в отдельный тег, а в чистый плейнтекст.

Вот только отправка реплаев никак не относится к форматированию текста. Вы смешали тёплое с мягким.

Дебилизм. Ещё шындовз переустановить предложите ;)

Ответа нет, поэтому вы сливаетесь? Хорошо, засчитано.

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

Решение задачи синхронизации устройств мессенджера закладывается в протокол этого мессенджера.

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

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

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

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

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

Протокол протоколом, а пущай клиенты научатся :P Пришлось руками переносить, файликом. Даже не строчкой.

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

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

Ну, в matrix и xmpp тут аналогично.

Мантры у Вас в голове ;) Нас так в вялендосрачах в мантрах про сетевую прозрачность иксов обвиняли, хотя Мы про неё и не заикались никогда.

Неа, это вы рассказываете мантры про то, что сферический сервер xmpp в вакууме что-то запрашивает к клиентов, не я.

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

И это обязывает идти в темы про matrix со своей пропагандой?

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

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

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

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

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

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

А вот E-Mail — это продукт, или?..

«E-Mail» — не продукт, а собирательное название группы протоколов и смежных с ними фич. А, например, «Gmail» — продукт.

Разве это не очевидно?

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

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

Что значит «имеют доступ в аккаунт»? Технически все, кто знает сервер, логин и пароль, имеют доступ в аккаунт.

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

Зависит от. Иногда храню, иногда ввожу.

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

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

А хотите объективные недостатки покажем?

Конечно!

Всё ещё хочу.

Если вторые в молодости не освоили, то потом уже поздно.

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

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

Аппаратные клавиатуры от падений тоже портятся.

Раскладки не осилили

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

А если аппаратных кнопок просто меньше чем букв, и какой-то кнопки нет вообще? (например, «ё», «ъ», «ю» - привет nokia n900)

А спец.символы: евро «€», градус «°», кавычки-ёлочки, длинное тире — как их набирать? На десктопе хоть Compose Key есть. А на мобилке?

А ещё Swipe-ввод на экранной клавиатуре сильно ускоряет набор текста. Мировой рекорд скорости набора подтверждает.

Всё есть, MidpSSH видели? ;)

Нет, и уже даже посмотреть негде. Как там Shift+F4 нажать?

У пользователей просто взяли и отняли контроль над процессами

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

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

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

Это всё тоже текст.

Да, это костыли, чтобы передать через текст то, что текстом не является. Что и требовалось доказать — в чате и раньше пытались передавать не только текст.

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

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

Ну да, а что ещё делать?

Пересылать в сообщении, без внешних ссылок же!

Бан учётки в мессенджере — это не проблема, по-Вашему?!

Если учётку забанили, то сообщение я не получу в любом случае. И не важно, картинка там была или внешняя ссылка.

Вы же сами выше распинались, что качать полностью не обязательно ;)

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

Может, оно этому пользователю вообще не надо: одним глазком глянули, что там такое, и передали дальше кому надо.

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

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

Давайте сравним. Только, уточните, что именно. Клиент element зареганный на matrix.org и pidgin... зареганный где? Какой протокол, какой сервер?

Они не развиваются независимо, а просто паразитируют на гугловском движке

А это плохо или хорошо? В смысле, независимый от хромиума браузер — это хорошо, а независимый от XMPP матрикс — это плохо? 😉

JivoSite, ClickDesk, LiveSupporti

Э... И какой из них матриксовцы могли форкнуть и доработать под себя?

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

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

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

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

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

клиенту не нужно хранить историю

WUT????!! Это уже какая-то терминальная стадия Интернет-зависимости, лечитесь. Или предлагаете на каждом локалхосте сервер поднимать?

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

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

Почему нельзя адекватно отобразить из одного мессенджера в другой?

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

В итоге что видит xmpp-пользователь - конференцию где переписываются три участника

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

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

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

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

Смысл тогда использовать xmpp и мучиться с проблемами, если есть протокол, где этих проблема нет?

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

с такой логикой XMPP не нужно, т. к. есть FidoNet и IRC

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

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

Т. е. xmpp только для смузихлёбов раз больше некому пользоваться?

Ну а кому ещё надо реализовать свои нескучные мессенджеры, когда для реальных задач есть проприетарный мейнстрим? ;)

Вот только отправка реплаев никак не относится к форматированию текста.

А должна?

Ответа нет, поэтому вы сливаетесь?

Хорошая тактика: насрать в штаны, а потом обвинить сбежавшего от вони собеседника в трусости ;)

Решение задачи синхронизации устройств мессенджера закладывается в протокол этого мессенджера.

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

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

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

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

Как необходимость хранить в одном месте говорит о запрете хранить в другом?

И как же сервер xmpp запрашивает у другого клиента?

Так в XMPP синхронизации истории и нет. Она была в домайкрософтовском Skype, например.

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

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

Неа, это вы рассказываете мантры про то, что сферический сервер xmpp в вакууме что-то запрашивает к клиентов, не я.

А между каких строк Вы прочли, что речь о XMPP? Речь о Matrix вообще шла изначально, Вы же зачем-то сначала полезли сравнивать список устройств с ресурсами, потом так же синхронизацию истории начали сравнивать.

И это обязывает идти в темы про matrix со своей пропагандой?

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

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

А тут классика: пока начали решать, стало уже поздно ;)

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

Опять хрень несёте. Мы вообще о протечках не упоминали, это Вы ими начали в морду тыкать. И речь не о мосте шла, а о транспорте.

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

Вы из какой ветки это вообще притащили? Мы и транспорты/мосты обсуждали, и серверы, и клиенты. Все они текут по-разному ;)

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

А почему не продукт?

Для пользователя E-Mail — это вполне сформированный бренд: то, где шлют письма с заголовками, где адреса через знаменитую «собаку», где к письмам вложения прикрепляют. Вне зависимости, кто, как и где этот E-Mail реализует. То есть E-Mail как таковой вполне себе продукт, вне зависимости от поставщика.

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

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

Всё ещё хочу.

Мы же их перечислили в том же сообщении — самые базовые, для затравки ;)

Аппаратные клавиатуры от падений тоже портятся.

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

слепого набора не бывает

Как раз-таки бывает. Мы нередко печатаем с мобильника вслепую.

и какой-то кнопки нет вообще?

Ну точно старичок, которому на всё отдельная кнопка надо ;)

На десктопе хоть Compose Key есть

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

Мировой рекорд скорости набора подтверждает.

Скорости набора словарных слов? Unfair. Сравните-ка на ohmoogi4Doofu5viy5IXo9eik1veeQuae4bueze4eweoj3oolah2eeQuug5shuoRokeuKib4geitee6aesh5ooWoo2gieQu4aezah3Poh0Ahm2yoo9ooxaiYe5nohmie каком-нибудь ;)

и уже даже посмотреть негде

Шо, MicroEmulator негде запустить? Кошмар, с утюга пишете?

Как там Shift+F4 нажать?

Это что ещё за новости GUI-фантазий? ;) Вы же в курсе, что в VT100 F-клавиш как таковых нет (как и многих других вещей), и они эмулируются через escape-последовательности (конкретно в случае F4 — ^[OS)? Куда Вы там Shift засовывать собрались? Сразу видно — Vim/Emacs/MC и прочим чем-то сложным консольным не пользовались, ну или не пробовали там биндить на какой-нибудь Ctrl+Shift+S ;)

Что в этом плохого?

То, что нужные приложения могут быть выгружены в любой момент без спросу, и ничего с этим сделать нельзя. Методички для Android-разработчиков издревле содержат требование восстанавливать состояние Activity на момент её завершения, но на практике это труднореализуемо.

убрать токены, перепроверить и т.д.

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

Если учётку забанили, то сообщение я не получу в любом случае

Но старые-то останутся, если озаботиться их хранением. Даже анально огороженный кацап умеет делать бэкапы ;)

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

Но в процессе просмотра оно всё равно скачается.

Вообще не факт, если видео большое.

И даже для этого ссылку надо открыть

Не обязательно. И даже при открытии не понадобится содержимое по ссылке выгружать (а upload, к слову, обычно медленнее download).

Какой протокол, какой сервер?

А в том и цимес, что пиджин все протоколы реализует одинаково хреново. Хоть встроенными протокольными плагинами, хоть сторонними. В первую очередь потому, что сам он довольно тупой по функциональности, и натягивать её не на что, даже при желании. Чатики (личные и групповые) без редактирования, удаления и без БД сообщений; форматирование, смайлики; списки контактов с группами; поиск комнат; вкарды; передача файлов — вот и всё, пожалуй. Ну XMPP реализован чуть получше, там ещё звонки работают и отладочная консоль есть ;)

Вполне уровень Element, не? Что Element может прям такого крутого предложить, на фоне какой-нибудь телеги, где мощные инструменты администрирования групп, боты с программируемыми клавиатурами, подписи к файлам и прочие плюшки? ;)

А это плохо или хорошо?

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

Аналогия с XMPP кривая, тут скорее OSCAR стоит вспомнить, который вроде как и был публичным стандартом, реализованным в нескольких мессенджерах, но по факту только ими и контролировался. XMPP на порядки свободнее, на его развитие может влиять кто угодно; бюрократии многовато, конечно, но кто мешает использовать черновик XEP уже сейчас, пока его рассматривают? Патч в Chromium наверняка не примут, если он не соответствует идеологии Google, а вот XEP-ы от любых васянов в основном принимают.

Э… И какой из них матриксовцы могли форкнуть и доработать под себя?

А вот не помним, есть вроде такие штуки и self-hosted.

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

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

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

Ну в Debian ещё такого не завезли ;)

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

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

Впервые слышим, примеры будут? ;)

Была целая серия телефонов с выдвижными клавиатурами у разных производителей. Как на той же nokia n900. Экран к клавиатуре в разных моделях крепился по-разному. И некоторые при неудачном падении разлетались на части — клавиатура летела в одну сторону, а экран в другую.

Ну точно старичок, которому на всё отдельная кнопка надо ;)

Тогда уже молоднячок. Отдельная кнопка на всё сейчас только на экранных клавиатурах бывает. А старички — это те кто на T9 набирали.

Так-то можно вообще любой текст одной кнопкой набирать — азбука Морзе называется. Но зачем этот мазохизм?

Это где Вы клавиатуру нашли, на которой композё нарисовано — в музее? ;)

В setxkbmap-е.

Скорости набора словарных слов? Unfair. Сравните-ка на ohmoogi4...nohmie каком-нибудь ;)

Очень даже fair. В большинстве случаев набирается именно словарный текст, а не случайный набор символов.

Шо, MicroEmulator негде запустить?

Есть где. Как в нём нажать Shift+F4?

Сразу видно — Vim/Emacs/MC и прочим чем-то сложным консольным не пользовались

Вообще-то это и есть хоткей из MC.

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

На десктопе с OOM-киллером всё точно так же. Или на десктопе тоже отобрали контроль?

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

И помнить это для каждого хоста, которых сотни? Ну-ка, по памяти, от preview.redd.it надо откусывать токены, или нет? А хвост от ссылок на картинки в твиттере? А как надо давать ссылку на картинки с фейсбука?

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

Это не «необходимость», а добровольный мазохизм. Обычные люди делают «копировать»/«вставить», и ничего никуда не перезаливают.

Но старые-то останутся, если озаботиться их хранением.

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

Даже наоборот, ссылка к тому времени может сдохнуть, а сохранённая картинка никуда не денется.

И даже при открытии не понадобится содержимое по ссылке выгружать (а upload, к слову, обычно медленнее download).

Если картинка придёт в сообщении, то тоже не придётся ничего никуда upload-ить.

А в том и цимес, что пиджин все протоколы реализует одинаково хреново.

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

Что Element может прям такого крутого предложить, на фоне какой-нибудь телеги

Много чего. Например, независимость от мобильного номера.

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

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

Аналогия с XMPP кривая, тут скорее OSCAR стоит вспомнить, который вроде как и был публичным стандартом

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

А вот не помним, есть вроде такие штуки и self-hosted.

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

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

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

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

с выдвижными клавиатурами

Слайдеры и раскладушки априори хрупкие, клавиатура здесь при чём?

Отдельная кнопка на всё сейчас только на экранных клавиатурах бывает

Отнюдь. Это во времена WM/Palm OS на экран впихивали побольше GUI-элементов. У нынешних лопат огромные экраны и при этом лютейшая гигантомания в интерфейсах, вкупе со стремлением скрыть побольше за всякими бутербродами, оставляя место для контента™.

T9

Такое же зло, как новомодные свайпы и прочие автодополнения. Управление ЭВМ должно быть точным и предсказуемым, а не «диалогом».

Но зачем этот мазохизм?

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

В setxkbmap-е.

А мультипресс в GTK+ immodules ;)

В большинстве случаев набирается именно словарный текст

ШшТо Ви ГавАритЕ?

Вообще-то это и есть хоткей из MC.

Действительно, Shift+F4 генерирует ^[[1;2S. Ну вот его и шлите, можете макрос создать ;)

На десктопе с OOM-киллером всё точно так же

OOM легко отключается. Правда, и в этом случае есть ограничение размером свопа, по достижению которого начнутся сбои аллокации и падения программ, но система задолго до этого начнёт тупить, намекая, что пора почистить оперативку ;) С J2ME ещё проще, перехватываемое исключение java.lang.OutOfMemoryError.

И помнить это для каждого хоста, которых сотни?

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

Если на ссылку из поисковой выдачи попали, то проверять её не стоит: рабочая и публичная же, раз поисковик её скраулил.

А хвост от ссылок на картинки в твиттере? А как надо давать ссылку на картинки с фейсбука?

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

Обычные люди делают «копировать»/«вставить», и ничего никуда не перезаливают.

Ну да, если при копировании/вставке «под капотом» не заливаются куда-то сотни мегабайт, то не перезаливают, ага ;) Это что-то из разряда «мы ничего не качали, только ютуб смотрели, куда трафик ушёл??77семьсемь»

а сохранённая картинка никуда не денется

Сохранённая — да, если раскошелиться на её хранение.

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

Если картинка придёт в сообщении, то тоже не придётся ничего никуда upload-ить.

Сколько раз Вам ещё повторить. что upload понадобится, чтобы передать картинку дальше?

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

Ну давайте всё тот же XMPP ;) Сервер можно gajim.org, он довольно навороченный.

Например, независимость от мобильного номера.

Маргинальный кейс. Для многих пользователи с какими-то тами логинами вместо номера телефона как раз создадут неудобства при установлении связи с ними. С телефоном всё понятно: набор циферок, продиктовали и записали, а с логинами начинается — «эс как доллар», и в итоге всё равно неправильно ;)

возможность поднять свой сервер

Так для телеграма тоже есть реализация своего сервера. Но без федерации, да — с другими серверами взаимодействовать нельзя.

что какой-нибудь дуров психанёт, выключит сервера

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

и я не потеряю контакт с друзьями

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

OSCAR не был ни публичным, ни стандартом

Его лицензировали для эппловского iChat ;) И к концу 00-х частично открыли.

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

Ну Mibew, например ;) Он к тому моменту вполне развит был уже. Русскими, кстати, делается.

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

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

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

Слайдеры и раскладушки априори хрупкие

Моя раскладушка из 2008 и не знает. А слайдер непонятно как нужно задрачивать, чтобы сломать. Был слайдер еще раньше от самсунга, но мне показался неудобным, отдал соседу. До сих пор живы (и слайдер, и тот дед). Замена батареек один раз всего, как и у моей нокии.

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

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

И какой же клиент xmpp дотягивает до Element по фичам? Где-то появились реплаи?

WUT????!! Это уже какая-то терминальная стадия Интернет-зависимости, лечитесь. Или предлагаете на каждом локалхосте сервер поднимать?

Опять выдумываете про сервер локалхоста? Тут и вам лечиться надо.

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

Повторяю вопрос, который уже неоднократно задавал и на который до сих пор не был дан ответ, как сервер xmpp поймёт, что сообщение не дошло? В каком XEP или RFC это описано?

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

При чём тут вайбер? Вот в вашей IRC два пользователя с никами a и b. Это пользователи matrix зашли через транспорт или пользователи irc сидят напрямую?

И по жидам видно, что два ненастоящие, угу.

Вы пишете в личку пользователю m_home.org@xmpp.home.org. Это пользователь matrix или jabber?

А так, чтобы не видно было, и чтобы им даже в личку написать можно было (настоящую, по личному жиду, а не по конфа/юзернейм)?

https://wiki.calculate-linux.org/matrix_xmpp_bridge

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

Вы опять отсылаете к голой теории, которая на практике не реализована? ;) OAuth, по факту, кроме как для привязки учёток к полутора централизованным платформам почти не используется.

WUT????!! Это уже какая-то терминальная стадия Интернет-зависимости, лечитесь. Или вернитесь в реальный мир.

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

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

Например? Появился клиент xmpp, в котором есть реплаи и который догнал по фичам Element?

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

Что значит «имеют доступ в аккаунт»? Технически все, кто знает сервер, логин и пароль, имеют доступ в аккаунт.

Есть аккаунт, зашли два устройства в аккаунт, одно устройство выключили. И на вопрос, какие устройства имеют доступ в аккаун отображаются оба, а не то, которое online как в xmpp.

Кстати, а почему бы его не хранить?

А на кой промежуточной прослойке (клиент) знать пароль от аккаунта если достаточно выдать токен?

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

Мир не ограничен Android-ом.

Так почему бы не хранить?

Зачем хранить если можно не хранить?

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

Ну а кому ещё надо реализовать свои нескучные мессенджеры, когда для реальных задач есть проприетарный мейнстрим? ;)

Людям, которых не устраивает проприетарный мейнстрим?

А должна?

Нет, с чего бы?

Хорошая тактика: насрать в штаны, а потом обвинить сбежавшего от вони собеседника в трусости ;)

Ну и зачем вы насрали в штаны? ;)

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

Можно мою цитату, где я писал, что эта терминология не сооветствует реальности?

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

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

Как необходимость хранить в одном месте говорит о запрете хранить в другом?

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

Так в XMPP синхронизации истории и нет. Она была в домайкрософтовском Skype, например.

https://xmpp.org/extensions/xep-0313.html и https://xmpp.org/extensions/xep-0280.html тогда что делают?

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

Действительно, зачем в xmpp засунули OMEMO, OTRv3, OpenPGP, зачем заворачивать соединения в starttls, можно же через обычный http пересылать сообщения?

А между каких строк Вы прочли, что речь о XMPP? Речь о Matrix вообще шла изначально, Вы же зачем-то сначала полезли сравнивать список устройств с ресурсами, потом так же синхронизацию истории начали сравнивать.

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

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

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

Опять хрень несёте. Мы вообще о протечках не упоминали, это Вы ими начали в морду тыкать. И речь не о мосте шла, а о транспорте.

Вы сказали, что жабограм лучше транспорта matrix-telegram. Оказалось, что по функционалу они одинаковы, только жабограм течёт постоянно и его надо перезапускать. С чего тогда жабограм лучше?

И речь не о мосте шла, а о транспорте.

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

Вы из какой ветки это вообще притащили? Мы и транспорты/мосты обсуждали, и серверы, и клиенты. Все они текут по-разному ;)

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

Покажете аналог жабограма для шматрицы, который так же полноценно работает через плейнтекст?

Аналог по функционалу показал, только аналог в matrix не течёт в отличие от жабограма. Поэтому жабограм лучше? ;)

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

У нынешних лопат огромные экраны и лютейшая гигантомания в интерфейсах

В отличие от аппаратной клавиатуры, экранная клавиатура настраивается

Такое же зло, как новомодные свайпы и прочие автодополнения.

Фичи, экономящие время — зло?

Любопытно... А стиральная машина — тоже зло, и стирать надо руками на тёрке?

Управление ЭВМ должно быть точным и предсказуемым, а не «диалогом».

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

А тысячи кнопочек — не мазохизм? ;)

Тысячи — это для китайцев. Нам на буквы и цифры пол сотни хватает.

Shift+F4 генерирует ^[[1;2S. Ну вот его и шлите, можете макрос создать ;)

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

Но допустим. Как вписать это в макрос? «^[» — это же не два отдельных символа?

OOM легко отключается.

Но не отключают же. И никто не жалуется, что линукс «отнял контроль над процессами». Так почему мобилка его отняла, если там так же?

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

Да. Юзеры льют и в соц.сети, и на форумы, и на разные хостинги картинок.

Если на ссылку из поисковой выдачи попали, то проверять её не стоит: рабочая и публичная же, раз поисковик её скраулил.

Вместо картинки вы предлагаете слать ссылку из гугла? Такую? nttps://www.google.com/imgres?imgurl=https%3A%2F%2Flookaside.fbsbx.com%2Flookaside%2Fcrawler%2Fmedia%2F%3Fmedia_id%3D3023243777798979&imgrefurl=https%3A%2F%2Fru-ru.facebook.com%2Fpythonmeme%2Fposts%2F&tbnid=GBrm6DpGeV686M&vet=12ahUKEwiDko--uqrsAhUumYsKHRp2AhkQMygDegUIARCkAQ..i&docid=QDZz_B2s14T44M&w=500&h=308&q=python%20meme&client=firefox-b-e&ved=2ahUKEwiDko--uqrsAhUumYsKHRp2AhkQMygDegUIARCkAQ

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

В лучшем случае ссылку на пост, а не картинку. И не короткую. Найдите тут короткие ссылки на картинку: https://twitter.com/dev_humor

если при копировании/вставке «под капотом» не заливаются куда-то сотни мегабайт, то не перезаливают, ага ;)

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

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

Это не устранение, а добавление. Вместо одной — 2 точки отказа. Если сдохнет мессенжер — не придёт ссылка. А если сдохнет ссылка, то и при рабочем мессенжере я ничего не увижу.

Ну давайте всё тот же XMPP ;) Сервер можно gajim.org, он довольно навороченный.

Ок. Пример — переписка с разных устройств:

Неделю назад в офисе я отправил другу ссылку. Сейчас я дома, вспомнил о ней, хочу ещё раз глянуть. Element+matrix — открыл клиент, увидел старую переписку. Pidgin+xmpp — облом?

для телеграма тоже есть реализация своего сервера.

Это PoC для гиков. Умеет лишь часть функций. И только с патченым клиентом. Он не поможет, если основные сервера отключат.

Собственный сервер может гэбня прикрыть, или стихийное бедствие ;)

Его можно поднять снова на другом хостинге.

А для друзей какая гарантия, что Вы не психанёте и не погасите сервер?

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

Ну Mibew, например ;) Он к тому моменту вполне развит был уже.

Web-only. Разделение на админов (логинятся) и пользователей (подключаются динамически). Пользователи между собой общаться не могут. Протокола нет.

Тут нечего дорабатывать. Чтобы превратить это в мессенжер с webrtc, переписать надо... всё.

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

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

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

Что значит «имеют доступ в аккаунт»? Технически все, кто знает сервер, логин и пароль, имеют доступ в аккаунт.

Есть аккаунт, зашли два устройства в аккаунт, одно устройство выключили. И на вопрос, какие устройства имеют доступ в аккаун отображаются оба, а не то, которое online как в xmpp.

Вы пытаетесь подогнать условие под ответ. 🙂

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

Вопрос — сколько устройств теперь «имеют доступ к моему ssh-аккаунту»?

Правильный ответ — а хрен его знает. Может быть 2? А может ни одного, если я снёс приватный ключ. А может быть 10, если я скопирую приватный ключ на другие машины. А может другие 10, если я зайду с них логином/паролем.

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

Так же и с мессенжером — нельзя сказать «сколько устройств имеют доступ». Можно только сказать «сколько токенов, идентифицирующих клиента, сервер ещё считает валидными».

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

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

А на кой промежуточной прослойке (клиент) знать пароль от аккаунта если достаточно выдать токен?

Пароль от токена не сильно отличаются. Токен можно отозвать? Ну, можно. А пароль можно сменить. Учитывая, что нужно это почти никогда, разница ещё менее важна.

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

И какой же клиент xmpp дотягивает до Element по фичам? Где-то появились реплаи?

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

Опять выдумываете про сервер локалхоста? Тут и вам лечиться надо.

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

как сервер xmpp поймёт, что сообщение не дошло?

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

Это пользователи matrix зашли через транспорт или пользователи irc сидят напрямую?

По Whois видно.

m_home.org@xmpp.home.org

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

https://wiki.calculate-linux.org/matrix_xmpp_bridge

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

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

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

В XMPP этой проблемы нет, поскольку нет единого «самого лучшего» клиента, есть много равномерно недоработанных (причём по-разному). То есть любым более-менее приличным клиентом можно пользоваться, не чувствуя ущемлённости, что где-то есть намного более полноценный. То же присуще e-mail, например: где единый самый крутой клиент для e-mail?

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

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

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

И на вопрос, какие устройства имеют доступ в аккаун отображаются оба

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

промежуточной прослойке (клиент)

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

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

Людям, которых не устраивает проприетарный мейнстрим?

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

Нет, с чего бы?

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

Можно мою цитату, где я писал, что эта терминология не сооветствует реальности?

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

В рамках протокола это будут разные устройства.

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

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

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

Я писал, что хранить клиент не должен

И в итоге Мы уже который год ищем клиент, который их пишет, ага. Ни один не пишет, зараза. Кроме libpurple-плагина, который срёт всеми чатами при каждом реконнекте. Приходится matrix-archive запускать, но восстановить сообщения, которые были удалены между его запусками, он не сможет, вестимо (а некоторые поехавшие очень любят чистить сообщения скопом).

https://xmpp.org/extensions/xep-0313.html и https://xmpp.org/extensions/xep-0280.html тогда что делают?

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

можно же через обычный http пересылать сообщения?

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

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

Мы уже потеряли нить обсуждения, где конкретно?

всякое желание связываться с xmpp отпадает

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

Оказалось, что по функционалу они одинаковы

Точно? Давайте сравним ;) Реплаи туда-сюда перебрасываются? Вкарды из телеги подтягиваются, редактировать их можно? Секретные чаты работают? Поиск по всей истории чата работает? Модерировать группы можно?

С чего тогда жабограм лучше?

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

поэтому в данном контексте эти понятия взаимозаменяемы

А сравнивать-то с нешматричными их как тогда? ;) Выходит, что анало-говнет.

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

как сервер xmpp поймёт, что сообщение не дошло?

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

Нет, это часто встречающееся заблуждение. Задача TCP - это про целостность передачи потока данных. А про доставлено ли какое-то сообщение прикладного уровня - это задача уже прикладного уровня.

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

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

В отличие от аппаратной клавиатуры, экранная клавиатура настраивается

Зачем? Вы в курсе, что такое мышечная память и слепая печать? О какой слепой печати может идти речь, когда на каждый чих разный лэйаут мёртвых неощупываемых экранных зон?

экономящие время

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

А стиральная машина — тоже зло, и стирать надо руками на тёрке?

Вы не поверите, но в сельской местности без [стабильного] водопровода таки зачастую целесообразнее использовать машину активаторного типа, чем автомат. А ради пары трусов или носков нецелесообразно загружать машину.

Это всегда диалог: юзер дает команду, ЭВМ отвечает

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

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

Также машина может быть перегружена и тупить, для этого весьма полезно иметь возможность отдать машине команды впрок: они отработают позже, причём неважно: CLI ли это, хоткеи или управление GUI с клавиатуры. В случае с визуальными интерфейсами это невозможно, приходится каждый раз ждать смены экранного интерфейса. Посему отзывчивости таких интерфейсов сейчас уделяется большое внимание, особенно на iOS, но проблема глубинная и решаема лишь костылями типа повышения приоритета тредов, отвечающих за интерфейс.

это для китайцев

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

Опять костыли

Ну тут уж претензии к тем, кто прикручивают навороты PC-шных клавиатур к VT100 (ещё и на мобильники их тащат, которые вообще к PC отношения не имеют). Тут без костылей никак ;)

Как вписать это в макрос?

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

Но не отключают же

Кто не отключают? Мы вот отключили, с OOM жизни нет ;) При надобности он вызывается руками по Alt+SysRq+F, когда система совсем раком встала и как-то покультурнее уже поздно.

Так почему мобилка его отняла, если там так же?

Потому что на мобильных ОС долопатной эпохи была полноценная многозадачность (где она вообще была ;)) без замораживания фоновых процессов, как на iOS/WP, и без их бесконтрольной выгрузки на Android. Symbian, S40, A100/A200, MOTOMAGX, Windows Mobile — таким не страдают, процессы контролирует пользователь. Если не хватает памяти, то просто не будут запускаться новые программы, пока вручную, на усмотрение пользователя, не очистить память. OOM — штука чисто линуксячья так-то.

Да. Юзеры льют и в соц.сети, и на форумы, и на разные хостинги картинок.

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

Вместо картинки вы предлагаете слать ссылку из гугла?

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

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

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

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

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

Если сдохнет мессенжер — не придёт ссылка

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

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

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

Это PoC для гиков

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

И только с патченым клиентом

Будто что-то сложное ;) В Иране вон местная гэбня патченый клиент успешно распространяла.

Его можно поднять снова на другом хостинге.

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

Но это будет моя воля, а не желание дурова.

А друзьям нужна чья-то воля или надёжный сервис? ;) С таким подходом долой полумеры, сразу P2P тогда.

Web-only

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

Разделение на админов (логинятся) и пользователей (подключаются динамически). Пользователи между собой общаться не могут

Вы что-то имеете против анонимусов? ;) Можно всех зарегистрированных делать «админами», в чём проблема? Допилить им ещё ACL.

с webrtc

Ну тут уж глубже надо искать ;) Впрочем, действительно вряд ли на тот момент такое уже было, поскольку WebRTC был сырым. Но определённо были устоявшиеся решения, которые работали на Flash или Java и плавно переехали на WebRTC.

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

Задача TCP - это про целостность передачи потока данных. А про доставлено ли какое-то сообщение прикладного уровня - это задача уже прикладного уровня.

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

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

Дробление, ACK, повторная отправка, собирание из пакетов, пришедших в другом порядке,… - это всё детали реализации, которые не доступны на вызывающем уровне.

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

Идея чего? :)

Я писал мост в матрицу из xmpp, который бриджил в обе стороны ники (double puppet), все реализовывается хорошо, именно по описанному алгоритму - с одной учетки и разными ресурсами и никами.

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

Для TCP они недоступны. А если создавать свой протокол вместо TCP на сырых пакетах, то пришлось бы не только клиенты но и сервера переписывать. Всё понятно. ;) Так ведь получается, что проще использовать Matrix: меньше NIH.

gag ★★★★★ ()