Comments 31
Status.im :-) приватнее, девентрализованнее некуда.
В моей голове блокчейн и приватность далековато друг от друга находятся. Или там что-то особенное кроме просто e2e для этого завезли?
Одно «Субъективно эвальюировав по юзабельности» чего стоит.
Взяли моду, уже не могут нормальными русскими словами тексты писать.
Дискасс, блин!
Да тут дело не англицизмах, а в
...Mattermost — про давайте клонируем Slack…
… Вконтакте и прочие давали автоматически при регистрации аккаунт на своём сервере и имели его интегрированным в свой интерфейс…
… И будем растить культуру делания мира лучше и патчинга своих проблем и общения с людьми на другой стороне земного шара. Засеем юные умы свободой!...
Текст больше похож на машинный перевод, однозначно минус.
На минуту закройте глаза и представьте интеллектуально-социальные последствия.
Ещё любопытен Keybase, интересно, как он по сравнению с Matrix.
tl;dr как мессенджер не очень, а как identity provider у меня даже есть прототип :)
Причём в оригинальном проекте есть некоторые связанные с этим проблемы:
- проблема интеграци с AD (я говорю про корпоративную среду) — логины на сервере synapse регистрозависимы
- проблема шифрации коммуникаций между пользователями (мы же не хотим той же участи, что и заблокированный мессенджер) — для enterprise это может стать некотроллируемым каналом утечки корпоративной информаци
- проблема того, что на публичный сервер идентификаци «улетают» все контакты пользователей (email и номера телефонов) — шикарнейшая база для спамеров
- проблема контроля корпоративных коммуникаций, в том числе и антивирусной защиты (решается, кстати, проше всего т.к. протокол построен на основе web)
- проблема доставки push уведомлений (часть уведомлений иногда теряется по пути к шлюзу вендора клиента — они об этом знают, но процент маленький...)
- проблема масштабируемости/отказоустойчивости основного сервиса (есть возможность выделения рабочих процессов, но основной сервис всё равно всегда один).
но эти и многие другие проблемы вполне решаемы. Информации на целый цикл статей…
Спасибо за комментарий!
Я не уверен, что для "стандартного" enterprise Matrix интереснее Mattermost, например. Не последней причиной для нас (меня) в выборе было "делать мир лучше", к чему Matrix ближе, на мой взгляд.
Перечисленные проблемы действительно актуальны, для нас — почти через одну: первая, третья, и последняя. Писать вообще про допиливание и опыт эксплуатации будем, но именно эти не видятся очень нетривиальными: с первым в моём опыте с GitLab проблем не было (да и у нас будет не AD, а другой LDAP / CAS, вероятно), с третей достаточно поднять свой (соглашусь, что это неочевидно), с последним — отказоустойчивость — действительно проблема (сейчас план — ждать, и, возможно, патчить dendrite).
Третья самая сложная. Нет нормальной реализации сервиса идентификации. Просто развернуть свой sygnal — не будет работать поиск по 3pid пользователей с чужих серверов. Если использовать проксирующий сервер — контакты всё равно улетят на vector.im
По шестой. На практике размещение в виртуализации и выделение рабочих процессов вполне решает задачу.
Да. Для меня ранее это не было проблемой — на практике пользователи обычно выбирали "каноническую" форму написания и использовали её всегда. Кроме того, пока наши логины — ~ASCII, кажется, можно без потерь нормализовать (просто lowercase?).
А mxisd нельзя настроить на федерацию на вход, но не выход?
Ок, но отсутствие hot standby немного коробит.
Это отличная идея. У нас с коллегами тоже была (кажется, первым я её слышал от intelfx). (И мы всё ещё её не реализовали.)
У меня нет готовых тезисов "почему [остальные делают] так", но, ковыряв Android-клиент, могу сказать, что он довольно сложный внутри с точки зрения именно реализации внутренней логики типа кеширования и т.д. Т.е. возможно, в телеграм-клиентах достаточно много такого телеграм-специфичного, чтобы действительно проще переписать.
Ещё, если говорить про похожесть по интерфейсу на Телеграм, есть nheko и Fractal.
С <заблокированного мессенджера> — в Matrix