нет клиентов нормальных
риот только в этом году допилили из абсолютно блевотного состояния в немного мерзкое
говорят ещё есть fractal на gtk, но я его не смог установить.
с серверами вроде та же проблема.
@l29ah * Matrix's main data primitive is synchronising conversation history within a room - not message passing. In fact, there is no way to just 'send a user a message' in Matrix: instead, you can only synchronise your copy of a room's state and history with someone else's copy of it.
Matrix rooms are replicated equally over all participating servers - there is no focal point as there is in a XMPP MUC.
Matrix provides a single monolithic (beta) spec, which compliant clients have to implement (for a given class of clients). There are no optional features or competing extension proposals for a given feature for a given class of client (e.g. 'desktop messenger'), to try to avoid fragmentation.
Matrix's baseline transport and encoding is super-simple-stupid HTTP+JSON, but with room for folks to propose superior transports & encodings as we see fit. So far there's been WS+JSON (which nobody seems to use, as it's not that massive an improvement over HTTP+JSON), and this year there's a GSoC project to look at MQTT-and-similar as an alternative.
he thing is... with XMPP, it's things that are really, utterly critical like the concept of messages having IDs that are left in the "extensions".
You can't build a sane protocol when something like "IDs" are a complete fend-for-yourself wilderness.
Long story short, if you ever try to implement something in XMPP/XEPs, you'll learn the hard way why it never seems to gain any traction. Very, very quickly. There are real technical reasons.
Extensibility is good. I believe the Matrix developers when they say it's extensible. (I've been a user for several years now. Features regularly get added in backwards-compatible and smooth ways.) Extensibility in the way XMPP tried to go about it -- for patching over core inadequacies of the basic protocol -- is not the same beast.
@ninesigns * Похуй мне.
* Реализуется небольшим XEP прозрачно для клиентов, если бы это было реально кому-то нужно. Для этого не нужно переделывать с нуля весь код клиентов и серверов, а также переподнимать всю инфраструктуру и разворачивать пиар-кампании.
* Анти-фича, в реальности ворох клиентов не умеющих многие фичи, и нет способа узнать кто что умеет, в отличие от XMPP'шных discover.
* Same shit.
> https://news.ycombinator.com/item?id=12908619
Поток сознания какой-то. Да, если ты зачем-то хуяришь в свои посты айдишники, да ещё и дублирующиеся, то будут проблемы, но можно этого просто не делать, сервер всё сделает за тебя.
> https://news.ycombinator.com/item?id=17064616
чо там
@l29ah - unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...).
multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages.
there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering.
Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture".
Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features.
@ninesigns Если твой клиент генерирует дублирующиеся айдишники, это проблема кривых рук его авторов, а не протокола. Если для кого-то уникальные строки это rocket science, то я даже не знаю, как он научился программированию.
Ложь.
Ложь.
Чё блядь?
Overall, заебал копипастить хуйню; впредь отказываюсь комментировать копипасты, не подтверждённые цитатами из стандартов.
@komar В задротском говне можно пообщаться с кучей прыщардов, в твоей моче можно пообщаться только с ляхом, комаром и вокером, что тоже неплохо, но хочется больше.
*?
@telegram а что не так с серверами? synology сложно поднять?
@l29ah * Matrix's main data primitive is synchronising conversation history within a room - not message passing. In fact, there is no way to just 'send a user a message' in Matrix: instead, you can only synchronise your copy of a room's state and history with someone else's copy of it.
Matrix rooms are replicated equally over all participating servers - there is no focal point as there is in a XMPP MUC.
Matrix provides a single monolithic (beta) spec, which compliant clients have to implement (for a given class of clients). There are no optional features or competing extension proposals for a given feature for a given class of client (e.g. 'desktop messenger'), to try to avoid fragmentation.
Matrix's baseline transport and encoding is super-simple-stupid HTTP+JSON, but with room for folks to propose superior transports & encodings as we see fit. So far there's been WS+JSON (which nobody seems to use, as it's not that massive an improvement over HTTP+JSON), and this year there's a GSoC project to look at MQTT-and-similar as an alternative.
he thing is... with XMPP, it's things that are really, utterly critical like the concept of messages having IDs that are left in the "extensions".
You can't build a sane protocol when something like "IDs" are a complete fend-for-yourself wilderness.
I've written about this previously: https://news.ycombinator.com/item?id=12908619
Long story short, if you ever try to implement something in XMPP/XEPs, you'll learn the hard way why it never seems to gain any traction. Very, very quickly. There are real technical reasons.
Extensibility is good. I believe the Matrix developers when they say it's extensible. (I've been a user for several years now. Features regularly get added in backwards-compatible and smooth ways.) Extensibility in the way XMPP tried to go about it -- for patching over core inadequacies of the basic protocol -- is not the same beast.
https://news.ycombinator.com/item?id=17064616
@l29ah айдишники повторяются в пределах чатрума?
@l29ah > Да, если ты зачем-то хуяришь в свои посты айдишники, да ещё и дублирующиеся
@l29ah где там у тебя айдишники дублируются, але?
@l29ah Хочу нормальные реплаи и форварды в чатах, синкание хистори между устройствами без костылей, а так же шифрование работающее всегда
@l29ah - unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...).
multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages.
there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering.
Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture".
Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features.
@komar В задротском говне можно пообщаться с кучей прыщардов, в твоей моче можно пообщаться только с ляхом, комаром и вокером, что тоже неплохо, но хочется больше.