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

Ответ на: Вообще-то, нет. от Moisha_Liberman

Сервер А отправил сообщение на сервер Б через s2s, а дальше пусть сервер Б разбирается.

Сервер А отправил сообщение на сервер Б, но сообщение не дошло до сервера Б (потеря связи). Сервер Б не будет ни в чём разбираться и что-то делать, до него же сообщение не дошло.

А потом начинается: «Ой, а почему xmpp теряет сообщения?»

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

Сервер Б не ложился, проблема с сетью, что cloudflare опять bgp пошатала и перенаправила трафик половины интернета в себя.

Каким образом сервер А поймёт, что можно отправлять сообщение на сервер Б? Где это в стандарте указано (XEP, RFC)? Как и в каких серверах это реализовано?

После этого они должны быть удалены. Иначе мы получим «атеросклеротические бляшки» в протоколе. И сервер (его очереди) может быть забит неактуальными и давно стухшими данными.

В каком XEP-е или RFC это описано? Как определить, что данное сообщение уже протухло?

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

Не, Вы это серьёзно? =)

Сервер А отправил сообщение на сервер Б, но сообщение не дошло до сервера Б (потеря связи). Сервер Б не будет ни в чём разбираться и что-то делать, до него же сообщение не дошло.

Сервер Б и делать ничего не должен. Это на сервере А нет уведомления о доставке до сервера Б. Сервер А просто должен переподать сообщения на сервер Б по восстановлении связи.

Всё логично.

Сервер Б не ложился, проблема с сетью, что cloudflare опять bgp пошатала и перенаправила трафик половины интернета в себя.

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

Каким образом сервер А поймёт, что можно отправлять сообщение на сервер Б? Где это в стандарте указано (XEP, RFC)? Как и в каких серверах это реализовано?

Вы это серьёзно или троллите так? =))) Это RFC 6120/6121. Прочтите, сделайте милость? Непонятные места я готов объяснить. И XEP-0198 заодно, там… про resumption тоже было.

В каком XEP-е или RFC это описано? Как определить, что данное сообщение уже протухло?

Потому что Вы не читали ХЕР-{0082, 0091, 0203} я теперь вынужден объяснять Вам что сообщения могут иметь временной штамп и иметь интервал, в течении которого доставка абоненту возможна? Но так же есть ХЕР-0160, т.н. Best Practices for Handling Offline Messages, который Вам так же стоило бы почитать на досуге.

Т.е., я правильно понимаю что причиной написать свой чатиг с игрищами и блудницами послужило то, что кое-кто не осилил найти и прочесть RFC и XEP? Задно и то, что кое-кто пытается смешивать проблемы прикладного уровня и транспортного уровня? L4 и L3 модели TCP/IP?

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

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

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

Что «всё»?

без регистрации в сети невозможен

Регистрация происходит один раз и ненадолго. Можно даже для этого специально выехать в другое место, если паранойя чешется ;) И Вы преувеличиваете точность сотовой триангуляции, особенно в негустонаселённых районах с низкой плотностью сот, ни о каком конкретном адресе тут и речи быть не может (иначе завозить в мобильники GPS нафиг не нужно было бы).

Люди слабое звено. И технические ухищрения тут не работают

Тогда зачем Вы о технических ухищрениях так паритесь?

собирало данные о WiFi точках доступа в округе

Это и не на мобильниках можно делать. И это, опять же, ничего не даст в глухомани, где вокруг одни бабы Сраки без интырьнетов ;)

но тут своя очередь есть, наверное…

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

Ну вот мы и добрались до этой самой privacy

Только вот тут важно понимать соотношение человека и окружающего его социального графа (тех людей, которым этот человек потенциально интересен). У людей известных размер такого социального графа стремится ко всему населению, но людей таких немного. Даже высокомнящим себя влогерам с миллионнами просмотров до этой верхушки далеко ;) У подавляющей же массы населения этот граф слишком мал, поскольку активный нетворкинг весьма повышает конкурентоспособность и вообще шансы чего-то добиться. Выходит, что обычным неуловимым Джо приватность не нужна и даже вредна. А те, кто сознательно ущемляют себя в контактах с окружающим миром во имя приватности™ — вовсе ССЗБ. Не те сейчас времена, чтобы ножками куда-то топать для этого, как Вы предлагаете.

По подсчётам

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

mertvoprog ()
Ответ на: Эммм... от Moisha_Liberman

Вопрос только в ёмкостях винчестеров и скорости доступа.

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

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

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

Вут? Вы путате чатики с какими-то комбайнами.

простым и убогим

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

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

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

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

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

Куда получена? Качать только текстовые логи и выкачивать всё содержимое по ссылкам — принципиально разные по ресурсоёмкости задачи, и второе зачастую неприемлемо.

или лишним кликом в браузер

Чего сразу в браузер? Куча вьюверов умеют HTTP.

А какие минусы?

Ресурсные, опять же.

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

Не видали, увы. Демонстрация есть?

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

А для этого не нужно какого-то особого слова. Вас в общем случае никто не заставляет качать весь файл сразу, за редкими случаями, когда формат держит метаданные в конце и сервер при этом не поддерживает оффсеты («докачку»). Факт в том, что скачивание как таковое требуется всегда, независимо от того, прозрачно оно для пользователя или нет ;) И тенденции таковы, что лучше уж делать прозрачно, GDPR и запросы прав доступа в браузерах, ведроиде, винде — наглядное тому подтверждение. А то пользователи жаловаться начнут — куда трафик ушёл, ничего же не качали, только смотрели!

это эксперименты комьюнити

А в экосистемах IRC/XMPP нет такой дискриминации сторонних клиентов. Посему нечего удивляться шквалу критики. Ведь проприетарные мессенджеры критикуют за то же: есть один официальный™ клиент, а остальное в лучшем случае работает на добром слове, в худшем же вовсе подвергается гонениям как в случае с WhatsApp, LINE и ICQ при AOL. И выходит, что Matrix равняется на последних, то есть не является в полной мере свободным.

для обычных юзеров не годится

А что годится для обычных юзеров? Зачастую как бы и выбора нет: официальное не работает, посему либо стороннее, либо никакое.

Он просто был для них неудобен.

Но нужны ли были им при этом REST+JSON — вот в чём вопрос. Особенно в свете надвигающихся (уже в 2014-м!) вебсокетов, по которым можно гонять что угодно, хоть тот же XMPP.

В MAM

Эка взяли и с ирки спрыгнули ;)

а отправлять тыщу пустых строк можно хоть каждую секунду

Slow mode тоже не завезли? ;)

многострочные сообщения сильно усложняют защиту от спама

И при этом кардинально ухудшают UX. Мы Выше упоминали уже о кусках кода. В сабже это вообще мастхэв.

а в XMPP не решили до сих пор

Да можно и однострочными сообщениями повайпать, @Darth_Revan не дадут соврать ;)

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

Ну это прекрасно.

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

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

Можно хотя бы три клиента, которые хотя бы дотягивают до Element?

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

спамят станзами входа и выхода с причиной «Replaced by new connection»

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

когда аналогичный по функционалу мост

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

И выбор почему-то отдаёт реализации, которая течёт

Вы сравниваете жопу с пальцем. Какой решение для связывания Matrix и Telegram поможет привнести Telegram на платформы, для которых нет ни клиентов Telegram, ни клиентов Matrix, но есть клиенты XMPP? Устраивать тройной мост XMPP⋄Matrix⋄Telegram, лишь бы на сервере не текло?

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

215 МБ, только что запустили.

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

Вут? Вы путате чатики с какими-то комбайнами.

Или вы путаете чатик с командой echo.

Поймите, есть разница между инструментом, и продуктом. Между паяльником и телевизором. Между двигателем и автомобилем. Между командой echo и мессенжером.

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

Комбайн ли это? Возможно. Но других мессенжеров не существует. Даже IRC — это комбайн, обвешанный скриптами и плагинами. И передающий файлы без внешних хостингов.

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

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

Качать только текстовые логи и выкачивать всё содержимое по ссылкам — принципиально разные по ресурсоёмкости задачи, и второе зачастую неприемлемо.

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

Не видали, увы. Демонстрация есть?

В смысле? Официальный андроидный hangouts может отправить видео, фото, или снять камерой. Там кнопка внизу есть.

Вас в общем случае никто не заставляет качать весь файл сразу

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

А в экосистемах IRC/XMPP нет такой дискриминации сторонних клиентов.

Это не дискриминация, это разница между инструментом и продуктом. В экосистемах IRC/XMPP нет продуктов, подобных матриксу.

(хотя тут вспоминали Cisco Jabber, но к нему сторонние клиенты коннектятся с трудом)

А что годится для обычных юзеров? Зачастую как бы и выбора нет: официальное не работает, посему либо стороннее, либо никакое.

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

Но нужны ли были им при этом REST+JSON — вот в чём вопрос. Особенно в свете надвигающихся (уже в 2014-м!) вебсокетов

Да, нужны. Так они создали протокол, не требующий постоянного соединения (актуально для мобилок даже в 2020). И сделали это обычными HTTP-запросами.

Как им это делать на базе xmpp? Поднимем http, апгрейднем до вебсокета, по нему передадим xml, в котором будет xmpp, с повторной авторизацией и восстановлением сессии?

Эка взяли и с ирки спрыгнули ;)

Так в ирке этой проблемы и нет, ведь там нет многострочных сообщений. Она есть в XMPP.

Slow mode тоже не завезли? ;)

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

И при этом кардинально ухудшают UX. Мы Выше упоминали уже о кусках кода. В сабже это вообще мастхэв.

Для UX одно многострочное сообщение и несколько однострочных даже выглядят одинаково. Вы видели современные чаты? Отправленные подряд сообщения склеиваются в общий бабл.

Да можно и однострочными сообщениями повайпать

А вот от этого защитит аналог throttling / slow mode.

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

Но вот Электрон в системе - это ни в какие ворота.

Никто пока лучше не сделал.

В смысле, фреймворка с возможностью быстрой реализации MVP и низким time-to-market. Да ещё и работающего на всевозможных платформах (как минимум - общие библиотеки).

А то просто хейтить все горазды.

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

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

Не совсем. У XMPP мало пользователей, потому что это — не продукт, а инструмент. Вот, какой нибудь Cisco Jabber — это продукт.

Матрикс — это продукт, у него есть официальный клиент, сервер и инфраструктура.

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

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

Полно адекватных технологий

Что у нас помимо XMPP и Matrix есть, извините пожалуйста?

«У нас» — это у кого? У опенсорца? Да и в какой области?

Например в области голосового общения есть VoIP — устоявшийся международный стандарт.

В сетевых коммуникациях есть Tor, GnuNet, FreeNet, I2P...

Есть и кучи средств обмена сообщениями. Из интересной экзотики — Tox, RetroShare и BitMessage, например (хотя последнее — тупиковая идея, имхо).

Уточните, какие именно технологии интересуют? А то я ещё много умных слов знаю... 😉

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

Лучше никак, чем так.

Это называется максимализм.

Полно адекватных технологий. Как то жили всё это время. А теперь вдруг - не можем?

Сейчас не социализм. Добро пожаловать в рыночек. Выживает самый приспособленный.

А точнее тот, кто сможет быстрее продать/завоевать интерес. А Electron в этом плане очень выгодно смотрится. Пока 1.5 землекопа будут на нативном тулките одну формочку пилить, один Васян сделает 2. Криво, медленно, но 2. А потом, когда взлетит, можно и оптимизацией заняться. Это называется MVP.

Если хочешь примеров на практике, посмотри на все те клиенты Matrix, которые с самого начала разработки протокола пытались создать. Ни один из них не взлетел.

Другое дело, что электронописатели не знают, как оптимизировать или не хотят. А ведь можно. В том числе и сам электрон можно оптимизировать, но не очень хотят. Вот в этом ИМХО и есть проблема.

И альтернатив Electron очень мало. В плане доступности и лёгкости разработки на высоком уровне (когда не надо трахаться с указателями и выделением памяти). Из ближайших только .Net или Java. Java не взлетела. .Net так и остался питомцем Microsoft без кроссплатформенного гуя (до поры до времени), кроме того же веба. И потому его не победить.

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

Или вы путаете чатик с командой echo

Вы чат на Nokia 3310 видали? Сильно от echo отличается? ;)

Современный мессенжер

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

Но других мессенжеров не существует

Да полно, мессенджеры нынче любой школьник пишет; взять хоть пиаримый топикстартером же Delta.Chat, в котором ни фига нет, причём мобильный клиент люто жрёт батарею, а десктопный на электроне ;)

для передачи файлов без внешних хостингов

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

От видео можно только превью показать

С генерацией превью сторонние хосты очень хорошо справляются, через твиттеровский де-факто стандарт — meta-тег og:image. Причём моднявые мессенджеры их очень охотно тянут и тыкают под нос ;)

или снять камерой

Ну так принимающая сторона до завершения съёмки начать смотреть сможет, или нет? ;)

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

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

это разница между инструментом и продуктом

А нафиг тогда нужны ваши «продукты», раз они создают неудобства?

сторонние клиенты коннектятся с трудом

Ну даже к васянским серверам с принудительным шифрованием не любой клиент подключится. А проблема с реализацией замороченных стратегий авторизации типа этих ваших LDAP’ов весьма распространена в опенсорсе: мало кому нужно и сложно тестировать в домашних условиях ;)

И оно обычно работает лучше неофициальных

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

не требующий постоянного соединения

Ващет BOSH изобрели давным-давно, как раз для этого. Вот почему он не особо взлетел — это вопрос.

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

Ирка в этом плане чуть ли не уникум. В чём вина XMPP-то? он ничем не выделяется среди прочих IM, это ирка выделяется отсутствием многострочности.

А в XMPP, это и будет всего одно сообщение

Зато хулиган не успеет отправить много таких портянок, эскалировав тем самым бедствием до колоссальных масштабов ;)

Отправленные подряд сообщения склеиваются в общий бабл.

Шо, и блоки с кодом склеиваются?

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

От XMPP, равно как и от какой-либо переносимости между мессенджерами, отказываются ради вендорлока. Потому что некому пока прижучить за этот вендорлок. С аппаратным вендорлоком типа стапицта форматов карт памяти и разъёмов для зарядки обосновать проще было: загрязнение окружающей среды, все дела, а как обосновать зоопарк мессенджеров на мобильнике — пока не придумали; тем более, они все работают через одни и те же гугловские и эппловские пуши по факту.

Но ничего, скоро SJW посчитают, сколько CO² выделяется от избыточных вычислений (до приветов в e-mail уже добрались) — и от визгов говнокодеров и свидетелей закона Мура, нещадно варимых в котлах зелёного движения, всколыхнёт весь Интернет, даже до ЛОРа дойдёт… если он к этому моменту ещё будет существовать, ведь написан на неправославной жабке, а местами даже на шкалке! — а не на ассемблере.

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

Если хочешь примеров на практике, посмотри на все те клиенты Matrix, которые с самого начала разработки протокола пытались создать. Ни один из них не взлетел.

Это заслуга не электрона, а того, что все такие клиенты пилят энтузиасты, в то время как Element пилят офффициально за зряплату.

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

.Net так и остался питомцем Microsoft без кроссплатформенного гуя (до поры до времени)

В Mono кроссплатформенный гуй давным-давно есть. Правда, вне винды выглядит как уродец с винды ;)

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

В том числе и сам электрон можно оптимизировать, но не очень хотят

Да ни фига, над вылизыванием хромого движка трудятся одни из лучших байтодрочеров мира. Там уже давно перформанс выкручен до предела. Проблема в том, что сам нынешний веб настолько всеобъемлющ и преисполнен легаси-костылей. Посему тенденция последних лет 5, а то и больше — менять и совершенствовать сами web-стандарты, чтобы на них проще и бескостыльнее можно было реализовывать приложения. Но процесс этот небыстрый, и необходимость поддерживать легаси-технологии никуда не девается. Вон посчитайте, сколько уже в CSS способов отцентрировать текст по вертикали… Спасти web от разбухания в таком виде уже нельзя, лишь пересоздать с нуля, но это уже будет не web, а что-то совсем иное, и вряд ли оно будет настолько же открытым.

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

ведь написан на неправославной жабке, а местами даже на шкалке! — а не на ассемблере.

Лучшие пограмисты лора за ночь перепишут его на ассемблере если понадобится. Да одна Iron_Bug справится, чивоужтам.

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

Вы чат на Nokia 3310 видали? Сильно от echo отличается? ;)

Это не целевая аудитория. Ни для чего. Дешевле каждому владельцу Nokia 3310 новый телефон купить, чем вести разработку с расчётом на эту аудиторию. 🙂

Нонешни мессенджеры сильно подвержены влиянию соцсетей

Далеко не все. Многие — это всё ещё средства доставки сообщений.

Просто «сообщения» уже не только текстовые. И доставляют их более чем одному человеку.

Ну тащемта, это не такая уж и сложная задача; ещё в ФИДОнете гоняли файлы ююком поверх текста

Видимо, и не такая простая. Потому что есть уже, наверное, с десяток XEP-ов про отправку фотки по XMPP.

взять хоть пиаримый топикстартером же Delta.Chat, в котором ни фига нет

Но даже в нём есть отправка картинок без внешних хостингов.

Ну так принимающая сторона до завершения съёмки начать смотреть сможет, или нет? ;)

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

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

Вы аплоад экономите, что-ли? 😉

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

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

Просто это никому не нужно. Нужна возможность скопировать/вставить фотку/скриншот максимально просто и безопасно. Это то, что нужно большинству юзеров. Без всяких ссылок.

А нафиг тогда нужны ваши «продукты», раз они создают неудобства?

А где создание неудобств? Наоборот же! Лучше когда есть один клиент, поддерживающий все фичи, чем когда таких клиентов ноль.

(Странно, что никто не вспоминает несколько известных продуктов, основанных на XMPP... Неужели даже фанаты XMPP их не знают? Лор уже не торт?)

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

Вообще-то сабж открытый. Или под «открытыми» имеются ввиду не опенсорцные, а те в которых нет ведущего продукта?

Тогда, в «открытых экосистемах» страдают все. Ну или приводите пример экосистемы, где никто не страдает.

Ващет BOSH изобрели давным-давно, как раз для этого. Вот почему он не особо взлетел — это вопрос.

Потому что BOSH — это не REST+JSON, а HTTP+XML+XMPP. То есть всё равно надо сделать весь XMPP, но через костыль в виде BOSH.

Он взлетел там, где был нужен XMPP — в веб-клиентах.

А разработчикам сабжа для их продукта XMPP был просто не нужен.

Ирка в этом плане чуть ли не уникум. В чём вина XMPP-то?

Ни в чём. Вы сказали, что в ирке «даже мультистрочных сообщений до сих пор нет». Я просто отметил, что это не так и плохо, например, при защите от спама.

Шо, и блоки с кодом склеиваются?

Если это просто текст, то почему бы и нет? Он остаётся многострочным, просто отображается так, словно был отправлен одним сообщением.

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

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

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

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

Дешевле каждому владельцу Nokia 3310 новый телефон купить

  1. А пользователи ретро-телефонов-то согласны, чтобы им какое-то новомодное говно втюхивали?

  2. Речь вообще не об этом, а о том, что Ваше понятие чатика искажено. Чат — это тупо переписка, внезапно.

Просто «сообщения» уже не только текстовые

Ну всё та же нокия умеет чёрно-белые картиночки передавать ;) В 3315 (эксклюзив для Японии) их даже редактировать можно было!

И доставляют их более чем одному человеку.

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

Видимо, и не такая простая. Потому что есть уже, наверное, с десяток XEP-ов про отправку фотки по XMPP.

Именно поэтому и простая. Не была бы простая — столько способов не наплодили бы ;)

Но даже в нём есть отправка картинок без внешних хостингов.

Ну да, взятая из e-mail со всеми его недостатками. Пересылка вложений в e-mail — это вообще лютый кошмар, особенно на медленном и нестабильном соединении. Выгрузить письмо в один присест по SMTP, потом повторно выгрузить по IMAP, чтобы копия в своём ящике сохранилась… Добавьте сюда ограничения на размер письма, 22 МБ (а где и меньше) нынче вообще ни о чём. И посему к письмам ссылки на внешние хосты сейчас как раз активно прикладывают; и это не только GMail, а уже и Thunderbird для больших вложений рекомендует залить их на внешний хост из некоторого перечня.

Вы аплоад экономите, что-ли? 😉

Мы сейчас нет, но многие экономят. И проблема даже не столько в трафике, сколько в том, что придётся ждать, или у вас там уже 6G в каждой дерёвне?

через 2 дня, когда ссылка больше не открывается

Это где так быстро ссылки тухнут?

Это то, что нужно большинству юзеров. Без всяких ссылок

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

Лучше когда есть один клиент, поддерживающий все фичи

Так этот клиент неюзабельный, то есть клиентов по факту нет.

Странно, что никто не вспоминает несколько известных продуктов, основанных на XMPP…

А толку их вспоминать, мы же о 2#20-м говорим? Лично Мы пользовались Я.Онлайн и HipChat, но оба уже мертвы. Google Talk даже не застали, сразу Hangouts, для которого есть неплохой libpurple-плагин (кстати, умеющий вставлять ссылки без редиректа на гугл, в отличие от официальных клиентов). WhatsApp толком не видели и не в курсе, что там; вроде ещё какие-то ошмётки XMPP остались, скрещённые с Signal.

Или под «открытыми» имеются ввиду не опенсорцные, а те в которых нет ведущего продукта?

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

это не REST+JSON

А зачем делать именно REST+JSON?

А разработчикам сабжа для их продукта XMPP был просто не нужен.

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

это не так и плохо, например, при защите от спама

То говорили про флуд, то уже про спам, определитесь уже.

Если это просто текст, то почему бы и нет?

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

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

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

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

Ничего не стало, живёт и здравствует.

Ну, оно ещё шевелится. Но аудитория ушла, в тот же Телеграм, Вайбер, etc.

Slack и Discord вон тоже на Электроне

Держатся за счёт того, что могут работать через браузер, без установки убогих клиентов на электроне.

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

аудитория ушла, в тот же Телеграм, Вайбер, etc

Она не из-за этого ушла, а из-за привязки к номеру телефона, которая привлекает новую аудиторию, который ранее все эти логины/пароли были слишкамсложна. Причём в Skype недавно добавили поиск контактов по номеру телефона, но было уже поздно.

Кстати, у ваццапа десктопный клиент на электроне, сильно аудитория разбегается? ;) Кроме полутора стран, где ещё до этого победили другие мессенджеры. В РФ вон даже намечена тенденция перетекания аудитории из Viber в WhatsApp.

что могут работать через браузер, без установки убогих клиентов на электроне

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

Ну и у Skype так-то тоже та же морда в браузерах работает ;)

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

Ну, про мотивацию переписывания Skype ничего не скажу. Для меня он умер сразу как Microsoft его купила. Может им надоело трахаться с Qt (в то время это было тем ещё приключением) и перекашлякать на жабакрипоте было проще, в том числе и для кроссплатформенности. К тому же, отказались от децентрализации.

А сейчас Microsoft самой не дают покоя лавры Google и она движется в сторону PWA.

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

Это кривой клон WinForms то, который на Linux работал через пень-колоду? И по количеству доступных фич языка/API был далеко позади? Это как сравнить Windows с ReactOS, лол.

.NET 5+ - вот новый Mono. Релиз уже в ноябре-декабре. Но учитывая, что это Microsoft - портировать WinForms и WPF никто не спешит. Но никто не мешает юзать биндинги или Avalonia.

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

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

Отвечая на ваш вопрос: https://github.com/tulir/mautrix-telegram/wiki/Management-commands#creating-portals, тут есть команда pm, с помощью которой можно связать аккаунт из телеграмма и matrix. То есть, опять вы слились. Будем выдумывать очередную отговорку? ;)

Или может быть, покажете мост в whatsapp или viber из xmpp?

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

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

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

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

Нет, как раз-таки это именно так работает «базовый протокол», а не вина мобильного интернета. И проблема не в реконнектах, они мало того, что могут быть, но и случаются. Базовый протокол и XEP-0045 так «хорошо» (сарказм) описан, что пока у него идёт спам переподключений, в matrix, telegram, viber, signal и прочих протоколах такого нет.

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

Аналогичный, мост matrix-telegram работает и как транспорт, и как мост.

Вы сравниваете жопу с пальцем. Какой решение для связывания Matrix и Telegram поможет привнести Telegram на платформы, для которых нет ни клиентов Telegram, ни клиентов Matrix, но есть клиенты XMPP? Устраивать тройной мост XMPP⋄Matrix⋄Telegram, лишь бы на сервере не текло?

Задача одна, чтобы пользователи разных протоколов могли общаться между собой. У xmpp - это жабограм, у matrix - это mautrix-telegram.

только что запустили.

Почитайте, что такое утечка памяти, и тогда вы поймёте, что ваш скриншот - это не пруф.

ma1uta ★★ ()
Последнее исправление: ma1uta (всего исправлений: 1)
Ответ на: Не, Вы это серьёзно? =) от Moisha_Liberman

Сервер Б и делать ничего не должен.

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

Сервер А отправил сообщение на сервер Б через s2s, а дальше пусть сервер Б разбирается.

Сначала пишете, что Б должен разбираться, а теперь пишите, что Б ничего и не должен делать. ВЫ уж определитесь.

Сервер А просто должен переподать сообщения на сервер Б по восстановлении связи.

Вы упомянули https://tools.ietf.org/html/rfc6120, где там сказано, как А должен это определять?

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

Речь не про маршрутизацию, речь про то, что s2s может разорваться в любой момент. И у сервера нет механизма для проверки, что данное сообщение дошло. Если не так, покажите, пожалуйста, в каком пункте RFC 6120/6121 про это написано?

Вы это серьёзно или троллите так? =))) Это RFC 6120/6121. Прочтите, сделайте милость? Непонятные места я готов объяснить. И XEP-0198 заодно, там… про resumption тоже было.

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

Если вы читали XEP-0198, то знали бы, что он относится только к c2s, а тут речь про s2s. Или вы сможете показать в реализации XEP-0198 в еже https://github.com/processone/ejabberd/blob/master/src/mod_stream_mgmt.erl где там s2s?

Потому что Вы не читали ХЕР-{0082, 0091, 0203} я теперь вынужден объяснять Вам что сообщения могут иметь временной штамп и иметь интервал, в течении которого доставка абоненту возможна? Но так же есть ХЕР-0160, т.н. Best Practices for Handling Offline Messages, который Вам так же стоило бы почитать на досуге.

Речь про то, что все участники online, поэтому сообщение не отправляет в offline storage, а уходит на сервер адресата, и не доходит до него. Сколько сервер-отправить должен ждать, чтобы понять, что сообщение не дошло, как он определит, что это сообщение дошло, а другое нет? Почему когда речь идёт про s2s ты приводите в пример c2s? Вы их сами читали-то?

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

в то время это было тем ещё приключением

Но цель оправдывает средства. Если постараться, выходит конфетка с низким (относительно Электрона) ресурсопотреблением, при этом настолько же кроссплатформенная. Telegram на Qt вполне современно выглядит. А QML вообще пушка; на нём, например, Tribler работает, или откопанный в соседнем треде Mirage (оба, что характерно, на питоне); можно ещё iStodo вспомнить, пилившийся кем-то из ЛОРчан.

К тому же, отказались от децентрализации.

Ага, как раз к тому моменту, когда в вебню WebRTC подъехал, позволяющий устанавливать P2P-соединения ;) Может, ещё одумаются, качество связи объективно ухудшилось же (что тоже распугало пользователей), в 2011-м голосовые звонки даже на EDGE сносно работали, сейчас такое нереально. P2P вполне имеет смысл, например, в США: там у всех опсосов уже IPv6 поддерживается.

и она движется в сторону PWA

И каковы результаты?

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

На том уровне, с которого они начинали, клиентов хоть высирачем жуй.

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

Для сравнения, в полуоткрытой телеге базовый публичный API с релиза не менялся; все расширения к нему выпускают «слоями», как в Android, благодаря чему в старых клиентах даже спустя лет 5 всё работает — кроме малозначительных недавно запиленных свистелок типа опросов или анимированных стикеров ;) Про IRC/XMPP и говорить нечего, стабильность железобатонная.

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

Это как сравнить Windows с ReactOS, лол

ReactOS падает на каждый чих, а этот клон вроде нет ;) Так что поосторожней с такими сравнениями.

// Ваша аватарка, кстати, чем-то напоминает Лену — в том смысле, что самая мякотка отрезана ;) И кажется, на ЛОРе были прецеденты сноса подобных «завуалированных» аватарок.

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

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

Мы просто сходу не заметили, что Вы рассказываете вообще о другой вещи ;)

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

тут есть команда pm, с помощью которой можно связать аккаунт из телеграмма и matrix

А входящие сообщения от юзера, с которым чат явно не создан, оно покажет? Жабограм да: прилетает апдейт из неизвестного доселе чата ⇒ создаётся JID для него ⇒ Jabber-клиенту прилетает сообщение от этого JID’а.

покажете мост в whatsapp

Вы для начала определитесь, о чём мы всё-таки говорим: о транспортах или мостах, потому как это разные вещи для разных задач. Для транспортов есть libpurple-обёртка к WhatsApp Web, функциональность на уровне прочих подобных обёрток, в том числе и маутрикса этого вашего; подключается к Spectrum2, как и любой другой libpurple-плагин. Для мостов народ пользует matterbridge, который умеет -надцать разных мессенджеров и гонять между ними спаренные чатики в любые стороны; в том числе и ирку, и жаббер, и кацап, и телегу, и шматрицу.

Была, к слову, даже libpurple-реализация первичного клиента WhatsApp, но эдак с 2014-го года такие поделки нещадно преследуются, а их пользователи пермабанятся. Обёртки к WhatsApp Web вроде не трогают пока, но тут тоже будущее туманно.

или viber

А к этому анально огороженному поделию каких-либо сторонних реализаций ровно 0. Максимум, что Мы встречали — это готовый конфиг для докера, чтобы разворачивать GNU/Linux’овый клиент и подключаться к нему по VNC. Ну и какие-то потуги по реверсингу протокола времён ещё версии 2.x, общий посыл которых таков, что там всё дофига обфусцировано и по большей части понятно ;) — а с тех пор ещё и шифрование появилось, что усугубляет задачу.

mertvoprog ()