LINUX.ORG.RU
ФорумTalks

nheko — всё.

 , ,


1

4

Здесь локальная драма случилась, с упоминанием прошлой драмы.

Ъ: https://matrix.to/#/!BPvgRcBVHzyFSlYkrg:matrix.org/$15393573631112821NLHkW:matrix.org
Ъ: https://matrix.to/#/!FPUfgzXYWTKgIrwKxW:matrix.org/$15393680731168331QUlwA:matrix.org

В общем, автор nheko, единственного сейчас кроссплатформенного клиента Matrix с шифрованием, свернул разработку:

mujx: I've lost interested in matrix & decided to not maintain it any further
mujx: it wasn't sudden really, I've been thinking about it for the last few months
mujx: matrix as is, is broken; you can find a few examples around rooms
mujx: check #dendrite-dev how you could circumvent bans for example
mujx: also poor community engangement, especially in the server side of things where it matters most and the fact that matrix is led by a for profit company with a clear conflict of interest, made me think that there is no future in it

Можно заметить упоминание, что протокол «танцует» профитная компания, коей является недавно испечённая «New Vector». По этой причине некто Max Dor героически сделал хардфорк спецификации в одно лицо, придумав нескучное название «The Grid» с нескучным логотипом, и предложил перевести разработку в нонпрофитную организацию, названную в честь него самого — «Kamax»:

mujx: maybe if the-grid becomes something I'll continue
cos: what is the grid?
Maximus: cos: #thegrid:kamax.io - A hard fork of the Matrix protocol that will focus on actually creating and maintaining a protocol specification backed by a non-profit
cos: Can`t find any info on grid on google. why was it forked and whats wrong with matrix? i find it already superior to irc.
Maximus: cos: https://kamax.io/thegrid-sunrise_overview.pdf
aaron: Isn’t the matrix foundation a non-profit?
Maximus: there is no such thing as a Matrix foundation. matrix.org and any related resources are backed by New Vector ltd, a UK for-profit
Maximus: Riot, synapse, Scalar and the likes are also backed by New Vector (NV for short)

В конце концов, пришёл Matthew, глава всея Matrix, прочитал всё это и бомбанул в TWIM:

Matthew: as i said in #nheko, i take it as a personal challenge to demonstrate to mujx that his concerns are illfounded
Matthew: (and perhaps are more reflect general fear, uncertainty & doubt being pushed by a few loudmouthed disgruntled members of the community rather than a balanced viewpoint.)
Matthew: in terms of the complaints: yes; there are still s2s API bugs out there which can allow things like ban circumvention; yes; we're working on them (of course) - it's what's blocking a stable release of the s2s API; no, i don't think we have poor community engagement, except for interactions with a handful of bad actors who have their own agenda.
Matthew: and the conflict of interest thing is absolute bullshit. we are trying to build matrix for the whole community, even if most of the core team work at the same company atm. matrix is only useful as a global network and ecosystem, and the priority is to support it for everyone
Matthew: hence doing things like TWIM, and hiring folks like ben to work to support the whole community
Matthew: and paying for frankly every person to work on matrix.org rather than any commercial stuff (with the exception of rick on modular, and a handful of consulting work, almost all of which gets released as FOSS for the benefit of the wider community anyway).
Matthew: honestly, speaking frankly, there is an alternative narrative here: that a few disgruntled folk (not mujx) have perhaps understandably developed a grudge against the matrix core team because their suggestions/contributions have been rejected, or because the spec isn't evolving as fast as they'd like, or because their agendas aren't being prioritised, or because they don't feel they have enough authority over the spec as they'd like, or because they've been banned due to abusive behaviour. And so they push the «conflict of interest» story, claiming that the team who created matrix is clearly incapable of developing matrix, just because we set up a consulting business to fund our work on it.
Matthew: It's true that there is potential for conflict of interest here, and we could all go evil and do a Microsoft and try to evolve matrix to somehow privilege New Vector or disadvantage other people in the community, but WE ARE NOT. it would be *!@£ing STUPID to sabotage Matrix like that, and the only reason I at least am trying to build Matrix is to build a global open ecosystem that everyone can benefit from, like the Web. There is WAY more potential in building exciting useful things on top of an open ecosystem like the Web or the Internet than some shitty closed fiefdom, and if I ever see New Vector prioritising itself over Matrix I will happily resign from it and work exclusively on the upcoming Matrix.org Foundation. I don't know how I can put that more clearly.

Такие дела. Пятница-понятница идёт просто замечательно.

★★★★★

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

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

А че их бояться? Занервничает только MUC, да и для того уже сверху кидали ссылку на успокоительный XEP.

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

Но вот где у JSON схемы? XPath? XLink?

Во-первых, нахрена тебе «схемы, XPath, XLink»? Во-вторых, в любом случае для этого есть эквиваленты в JSON (1, 2, 3 соответственно). Что у JSON, что у XML абсолютно одинаковая выразительность. Всё, что ты назвал выше — это семантика поверх формата сериализации.

Ткни уже меня носом в эту киллер-фичу, не реализуемую поверх архитектуры XMPP, пожалуйста. Каюсь, матчасть читал всего минут 15 и походу какую-то не ту.

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

А че их бояться? Занервничает только MUC, да и для того уже сверху кидали ссылку на успокоительный XEP.

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

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

Что у JSON, что у XML абсолютно одинаковая выразительность

Да, я тебя услышал, у любого протокола, позволяющего передавать произвольный payload, эквивалентная выразительность по Шаповалову.

Во-первых, нахрена тебе «схемы, XPath, XLink»?

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

Во-вторых, в любом случае для этого есть эквиваленты в JSON (1, 2, 3 соответственно).

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

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

XMPP Delayed Delivery на этой неделе стукнуло 15 лет. Что за FUD из тебя попер?

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

Про выразительность: вспомнил, где я это читал: http://xahlee.info/python/what_is_expresiveness.html

$myText =~ s/myPattern/replStr/ выразительнее синтаксически, re.sub( myPattern, replStr, myText , myCount) выразительнее семантически. При этом и Python, и Perl полны по Тьюрингу, но это не значит, что у них одинаковая выразительность.

t184256 ★★★★★
()

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

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

Вут?

You are viewing an unstable version of this specification. Unstable specifications may change at any time without notice. To view the current specification, please click here.

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

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

Так оно в стабильной спецификации есть, ещё со времён царя Гороха. Riot прекрасно получает пуши.

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

это не те пуши. это пуши для интеграции серверов (которая в 99% случаев не нужна). а нужны пуши для клиентов. проблему создаёт куча запросов от каждого васяна «а чо там на сервере нового появилось». да и для клиента это геморно - постоянно дёргать сервер.

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

Как ты себе представляешь пуши? В современном интернете есть только client-initiated пуши, и они там есть (HTTP long-polling).

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

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

На хрена они тебе сдались, если ты не пишешь спеку и не делаешь сервер?

нетсплиты

<...>

XMPP Delayed Delivery на этой неделе стукнуло 15 лет. Что за FUD из тебя попер?

А давай ты всё-таки почитаешь сраную спеку и не будешь писать чушь? XEP-0203 — это про c2s, когда клиент в оффлайне был. А я совсем не про это.

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

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

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

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

ну вот клиент-инициированные пуши и рушат всю систему

А нужно-то как? IPv6 ещё не завезли. Единственное, что можно сделать — это инициировать соединение с сервером и ждать, пока он чего-нибудь пришлёт.

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

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

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

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

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

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

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

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

вот он как раз не так устроен. в этом и проблема.

Synchronise the client's state with the latest state on the server. Clients use this API when they first log in to get an initial snapshot of the state on the server, and then continue to call this API to get incremental deltas to the state, and to receive new messages.

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

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

короче, сначала попробуй написать тот клиент

Представь себе, я писал экспериментальный CLI клиент для Matrix...

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

Нет. Это long polling. Ты открываешь соединение, указываешь таймаут и ждёшь. Там «пары десятков запросов в секунду» никогда не будет.

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

Это long polling. Ты открываешь соединение, указываешь таймаут и ждёшь. Там «пары десятков запросов в секунду» никогда не будет.

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

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

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

Для твоего заявленного уровня квалификации задавать такие вопросы достаточно странно. Что значит «запросы не нужны»? А как, по-твоему, клиент должен коммуницировать с сервером? Через libastral? В современных сетях ответов без запроса не бывает. Ты открываешь соединение, отправляешь запрос и ждёшь ответа. Можешь ждать долго.

Повторюсь,

и почему бы не сделать соединение и не ждать?

Происходит ровно это.

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

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

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

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

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

А это что такое, по-твоему? Создаёшь фильтр, ставишь таймаут, отправляешь запрос, ждёшь. Алё, иди спеку читай.

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

На хрена они тебе сдались, если ты не пишешь спеку и не делаешь сервер?

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

А давай ты всё-таки почитаешь сраную спеку

Прочитал.

Избранные места:

Pragmatic Web-friendly APIs (i.e. JSON over REST)

Fully decentralised - no single points of control over conversations or the network as a whole

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

PKI

So much for the previous point, че.

Matrix optimises for the Availability and Partitioned properties of CAP theorem at the expense of Consistency.

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

The end goal of Matrix is to be a ubiquitous messaging layer for synchronising arbitrary data between sets of people, devices and services - be that for instant messages, VoIP call setups, or any other objects that need to be reliably and persistently pushed from A to B in an interoperable and federated manner.

Паттерн проектирования «задница» налицо, штука может и элегантно универсальная, но маркетинговой задаче (one IM to rule them all) неадекватная.

HTTP

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

Events exchanged in the context of a room are stored in a directed acyclic graph (DAG) called an «event graph».

Да ладно, сейчас будет Pijul, только внутри чата! Умереть не встать! А я думал блокчейн - подорожник современного IT, прикладываемый к чему попало, а у него, оказывается, конкурент зреет.

To order and ease chronological comparison between the events within the graph, homeservers maintain a depth metadata field on each event.

и туда же

Where events describe the same state, a merge conflict algorithm is applied. The state resolution algorithm is transitive and does not depend on server state, as it must consistently select the same event irrespective of the server or the order the events were received in.

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

Резюмирую: На publish-subscribe можно сделать групчат. Моча ударила в голову и вместо того, чтобы сделать это поверх XEP-0060, был сделал свой никому не нужный протокол (что саботирует цель сделать это популярным). Если бы не моча, был бы еще один XEP.

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

и не будешь писать чушь?

С этим будет сложно. Ты на эмоциях, я на эмоциях, ты сказал глупость (если вне контекста), как не подколоть?

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

И тут я опять проигрываю с бессмысленности.

Смени проигрыватель на выигрыватель.

В этом смысле никакие нижележащие протоколы не нужны независящим от них вышележащим.

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

Fully decentralised - no single points of control over conversations or the network as a whole

<...> важность для конечного пользователя <...> равна нулю.

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

PKI

So much for the previous point, че.

Ты, наверное, хотел что-то сказать по существу, но забыл.

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

Ну вот мой личный сервер иногда лежит по полдня, пока я его препарирую. И всё в порядке. С банами, кстати, тоже всё в порядке (in vivo не приходилось быть забаненным, а in vitro экспериментировал, разумеется).

А с XMPP я бы уже давно лососнул тунца в high-volume конференциях, что с банами, что без банов.

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

Здесь плюс. Но так уж сложилось, что HTTP-клиент есть в каждой микроволновке. К слову, придумай мне протокол, схожий по универсальности и сравнимый по эффективности с HTTP/2?

Да ладно, сейчас будет Pijul, только внутри чата! Умереть не встать! А я думал блокчейн - подорожник современного IT, прикладываемый к чему попало, а у него, оказывается, конкурент зреет.

Эмоций — тебе только в театре работать. А по существу?

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

ditto

Резюмирую: На publish-subscribe можно сделать групчат. Моча ударила в голову и вместо того, чтобы сделать это поверх XEP-0060, был сделал свой никому не нужный протокол (что саботирует цель сделать это популярным). Если бы не моча, был бы еще один XEP.

Расскажи мне, как ты сделаешь «поверх XEP-0060» всё процитированное тобой же, сохраняя осмысленную совместимость с baseline XMPP.

С этим будет сложно. Ты на эмоциях, я на эмоциях, ты сказал глупость (если вне контекста), как не подколоть?

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

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

независящим от них вышележащим.

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

Ты сегодня какой-то не такой. Я же оговорился - «независящим».

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

У моего XMPP-сервера и OMEMO есть отсутствующее у телеги и (слабо, но все-таки) ценное любому пользователю IM свойство несливания содержания моей переписки не-адресату. Децентрализованность MUC пользователям нужна разве что поохать как оно бывает.

So much for the previous point, че.

Ты, наверное, хотел что-то сказать по существу, но забыл.

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

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

А с XMPP MUC было бы не в порядке? В чем фундаментально проблема добавить в XMPP s2s delayed messaging, если его еще нет? Где у тебя в XMPP сообщения терялись, я так и не понял.

С банами, кстати, тоже всё в порядке (in vivo не приходилось быть забаненным, а in vitro экспериментировал, разумеется).

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

А с XMPP я бы уже давно лососнул тунца в high-volume конференциях, что с банами, что без банов.

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

Расскажи мне, как ты сделаешь «поверх XEP-0060» всё процитированное тобой же, сохраняя осмысленную совместимость с baseline XMPP.

Ну тут три варианта развития событий на выбор:

1) повторю путь Matrix и заверну MUC-станзы в обертки, организующие из них в орграф. Определю протокол создания и присоединения к децентрализованной конфе. Буду рассылать эти обернутые станзы всем подписанным, для отправки внезапно нарисовавшимся продумаю политику отложенной доставки, для отложенного получения продумаю политику реплея истории. делов как раз на один-два маленьких XEP-а

2) то же самое, но заворачивать в орграф не буду, а буду мерджить чисто по дате.

3) сразу признаю, что это не решает абсолютно никаких новых user-facing проблем, закладываться на нетсплиты в этом веке будут не больше, чем на сайты без поддержки JS, а на федерацию конф XEP уже написали, и пойду с этими тезисами обратно к заказчику

Естественно, третий вариант честнее первых двух, и любой, бросающийся делать 1-2, уподобится несчастному из Прокачка скиллов критического мышления

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

В контексте-то да, но если культурно себя вести, то срача не выйдет =)

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

мы ходим по кругу. я тебя спрашиваю: КОГДА нужно делать этот запрос? сколько раз? а можно опрашивать сто раз в секунду? ну, вдруг там быстро данные будут меняться. я же не знаю заранее. вот в этом и проблема.

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

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

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

КОГДА нужно делать этот запрос?

Когда предыдущий завершился по таймауту.

сколько раз?

До тех пор, пока нужны новые события.

а можно опрашивать сто раз в секунду?

Можно, но не нужно.

ну, вдруг там быстро данные будут меняться

Если там быстро данные будут меняться — события будут поступать по мере появления на сервере.

Я ещё раз повторяю, это очень странные вопросы для твоего уровня компетенции. Ты понимаешь концепцию HTTP long polling? Ты создаёшь запрос с большим таймаутом и ждёшь. Сервер присылает данные, когда они появляются. Какие у тебя есть предложения?

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

Децентрализованность MUC пользователям нужна разве что поохать как оно бывает.

«640 КиБ хватит всем»

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

А кто строит децентрализованную сеть на основе PKI? Вообще где ты там нашёл упоминание PKI?

А с XMPP MUC было бы не в порядке?

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

В чем фундаментально проблема добавить в XMPP s2s delayed messaging, если его еще нет?

В том, что ты переизобретёшь Matrix, только хуже.

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

Где ты собрался его хранить и как выдавать? «Гладко было на бумаге», ну дальше понятно.

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

Ну да. Ты переизобрёл Matrix. А теперь расскажи мне, как ты в рамках этой сногсшибательной идеи сделаешь интероп с baseline XMPP, т. е. с серверами, которые не умеют в вышеописанное?

то же самое, но заворачивать в орграф не буду, а буду мерджить чисто по дате.

Получишь конфликтом по лицу с первым же эквивалентом state event (хз как это в XMPP называется).

сразу признаю, что это не решает абсолютно никаких новых user-facing проблем

См. начало моего ответа. Ещё можно вспомнить, что Matrix через какое-то время собирается отвязать аккаунты от серверов и полностью децентрализоваться, что придаст значения проблеме нетсплитов (и заодно переведёт его в совершенно другую весовую категорию относительно XMPP).

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

Кек, да это же копирастическая многоходовочка: создали ООО «Вектор+», чтобы подомнуть и развалить свободный проект :D Чуется почерк мелкомягких.

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

А кто строит децентрализованную сеть на основе PKI? Вообще где ты там нашёл упоминание PKI?

https://matrix.org/docs/spec/

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

Да.

В том, что ты переизобретёшь Matrix, только хуже.

Если не рожу нового, то я в плюсе.

Где ты собрался его хранить и как выдавать? «Гладко было на бумаге», ну дальше понятно.

На сервере конфы. Непонятно.

Ну да. Ты переизобрёл Matrix.

Не переизобрел Matrix, а натянул их идейку на все готовое.

А теперь расскажи мне, как ты в рамках этой сногсшибательной идеи сделаешь интероп с baseline XMPP, т. е. с серверами, которые не умеют в вышеописанное?

Оставлю тот же механизм доставки MUC-станз, что и сейчас, в любую из конф-алиасов. В итоге присоединение к этой конфе и участие в ней будет возможно по любому алиасу. Ни на клиентах, ни на серверах, в распределенности не участвующих, ничего править не придется.

Получишь конфликтом по лицу с первым же эквивалентом state event (хз как это в XMPP называется).

И разрешу его как попало. У нас тут все равно чат без consistency, by design.

См. начало моего ответа. Ещё можно вспомнить, что Matrix через какое-то время собирается отвязать аккаунты от серверов и полностью децентрализоваться, что придаст значения проблеме нетсплитов (и заодно переведёт его в совершенно другую весовую категорию относительно XMPP).

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

Юзерам насрать. Децентрализованность чата сама по себе - не полезное свойство для юзера. Censorship-resistance - полезное. Subpoena-resistance - полезное. Еще какое-нибудь - полезное. В который раз спрошу - каково это призрачное суперценное свойство, ради которого оправдано было пилить новый протокол, временно (надеюсь) предавать цель о популярности и собирать userbase с нуля?

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

Какие у тебя есть предложения?

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

хотя в целом я считаю матрикс вполне рабочим вариантом. если всё тихо-мирно и защищено снаружи.

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

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

Да ты прям романтический герой, а не технарь.

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

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

DCCP

Зачем тебе congestion control в сраном чатике?

Короче. Я не пытаюсь сказать, что HTTP там оптимален, но с HTTP/2 и его мультиплексированием всё получается as good as it gets. Твои претензии по поводу долбёжки сервера — необоснованны. Правильно написанный клиент никуда долбиться не будет, а заддосить можно всё что угодно, это не проблема протокола.

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

На сервере конфы. Непонятно.

На каком сервере? На единственном? Или на всех? Кому выдавать и как? Где хранить курсор? Если ты аккуратно ответишь на эти вопросы, получишь s2s cпеку матрикса.

Не переизобрел Matrix, а натянул их идейку на все готовое.

«Эта сова начинает рваться ещё в самом начале процесса» (c) кто-то с ЛОРа.

Оставлю тот же механизм доставки MUC-станз, что и сейчас, в любую из конф-алиасов. В итоге присоединение к этой конфе и участие в ней будет возможно по любому алиасу. Ни на клиентах, ни на серверах, в распределенности не участвующих, ничего править не придется.

Отлично. Не забываем, что тебе как минимум потребуется линеаризовывать DAG и наоборот. Т. е. по сути моё требование не соблюдено, потому что ты придумал инкапсуляцию и интероп представляет собой нетривиальное преобразование из одного протокола в другой.

Итак, что мы получили:

  • эквивалент s2s матрикса, натянутый на откровенно херовый wire protocol (спасибо, но лучше JSON over HTTP, чем бесконечный XML over TCP. если это утверждение вызывает сомнения, пожалуйста, не подходи к проектированию сетевых приложений ближе, чем на километр.)
  • встроенный в каждый полноценный сервер адаптер в baseline XMPP, сложность реализации которого сопоставима со сложностью реализации моста между двумя разными протоколами
  • абсолютно никаких преимуществ перед матриксом

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

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

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

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

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

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

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

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

man GNUnet

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

Зачем тебе congestion control в сраном чатике?

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

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

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

man GNUnet

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

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

На каком сервере? На единственном?

Да, этот вопрос был из ветки о недостатках MUC как он есть в XMPP.

«Эта сова начинает рваться ещё в самом начале процесса» (c) кто-то с ЛОРа.

Ну вот мне не очевидно.

лучше JSON over HTTP, чем бесконечный XML over TCP

В вакууме да. Но вот для задачи охвата рынка велосипед over JSON over HTTP хуже, чем industry standard over XML over TCP.

встроенный в каждый полноценный сервер адаптер в baseline XMPP, сложность реализации которого сопоставима со сложностью реализации моста между двумя разными протоколами

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

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

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

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

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

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

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

Ээээ... создателей HTTP?

https://www.w3.org/Protocols/HTTP/Methods.html , если что.

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