4 ms·

I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Surely an "eventually consisten

by zaik 6y ago

I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Surely an "eventually consistent database" can be built on top of XMPP? It's just message passing. When evaluating WhatsApp alternatives, this somewhat made me choose XMPP over Matrix. I recently uninstalled WhatsApp, Telegram and LINE (felt pretty good) and now use Conversations with most of my friends and family who were kind enough to try it out. Apparently Quicksy is free in the Google Play Store which is good news because nobody was willing to pay 2.50 EUR for Conversations and installing F-Droid just to install another app was quite a hurdle.

rcxdude 6y ago
It's a fundamentally different approach. You could in theory build it on top of XMPP, but it wouldn't actually interoperate sensibly, so what's the point?
- lapinot 6y ago
  > It's a fundamentally different approach. Is it? (genuinely curious) Can't one see the matrix server-server state synchronization protocol as a transport layer for MAM archives? And pubsub nodes in XMPP are very matrix-room-like. This could be an XMPP extension allowing to multi-home pubsub nodes. Also, there are recent matrix proposals [*] for representing several things (groups and user profiles) as rooms. Given the analogy room=pubsub, the user-profile-as-room seems to be the same thing as XMPP's PEP (used to share personal data, like public keys or avatar). And the group-as-room would be the MIX proposal. [*] https://github.com/matrix-org/matrix-doc/blob/matthew/msc1772/proposals/1772-groups-as-rooms.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc177... [*] https://github.com/matrix-org/matrix-doc/pull/1769 https://github.com/matrix-org/matrix-doc/pull/1769*
lapinot 6y ago
> I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Indeed. For sure XMPP has ugly corners (disclaimer I never implemented anything, mostly read some XEPs). I believe parts which are quite clean are the pub/sub part and the message archive (MAM). Afaik the current group chat extension (MUC) isn't so great (once you try to add history multi-device) and some people are trying to refactor it on top of pubsub (MIX) but it's not very active. The matrix team clearly had precise ideas about the right way to do federated group chat and in fact (again afaik, my matrix knowledge is dated) their "rooms" seem to be quite flexible by not being completely tied to a particular server (several servers participate in hosting a room). Imho matrix has an edge in designing this from scratch and already knowing what the hard parts are from the beginning and i hope the good ideas will come over to XMPP. Perhaps some day an XMPP server will support matrix, making more clients available to the network (well integrated clients on every plateform is the real hard part for every distributed network).

by zaik 6y ago

rcxdude 6y ago

It's a fundamentally different approach. You could in theory build it on top of XMPP, but it wouldn't actually interoperate sensibly, so what's the point?

lapinot 6y ago
> It's a fundamentally different approach. Is it? (genuinely curious) Can't one see the matrix server-server state synchronization protocol as a transport layer for MAM archives? And pubsub nodes in XMPP are very matrix-room-like. This could be an XMPP extension allowing to multi-home pubsub nodes. Also, there are recent matrix proposals [*] for representing several things (groups and user profiles) as rooms. Given the analogy room=pubsub, the user-profile-as-room seems to be the same thing as XMPP's PEP (used to share personal data, like public keys or avatar). And the group-as-room would be the MIX proposal. [*] https://github.com/matrix-org/matrix-doc/blob/matthew/msc1772/proposals/1772-groups-as-rooms.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc177... [*] https://github.com/matrix-org/matrix-doc/pull/1769 https://github.com/matrix-org/matrix-doc/pull/1769*

lapinot 6y ago

> I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Indeed. For sure XMPP has ugly corners (disclaimer I never implemented anything, mostly read some XEPs). I believe parts which are quite clean are the pub/sub part and the message archive (MAM). Afaik the current group chat extension (MUC) isn't so great (once you try to add history multi-device) and some people are trying to refactor it on top of pubsub (MIX) but it's not very active. The matrix team clearly had precise ideas about the right way to do federated group chat and in fact (again afaik, my matrix knowledge is dated) their "rooms" seem to be quite flexible by not being completely tied to a particular server (several servers participate in hosting a room). Imho matrix has an edge in designing this from scratch and already knowing what the hard parts are from the beginning and i hope the good ideas will come over to XMPP. Perhaps some day an XMPP server will support matrix, making more clients available to the network (well integrated clients on every plateform is the real hard part for every distributed network).