> Because Matrix is inherently decentralized, no single server "owns" the conversations; all traffic is replicated across all of the involved servers. [...] Matrix is more like Git than XMPP, SIP, IRC, or many other traditional communication protocols.
The Matrix protocol is well worth the read. JSON-LD is a bit of a nightmare to work with, but the gist of it is a solid concept; it has drastically changed my approach to software design.
The very high-level view is that Matrix is a set of protocols for syncing messages and state between servers. Matrix is to XMPP what NNTP is to SMTP. This makes multi-device and disconnections much easier to handle, because all you need to do is to wait for the messages to eventually arrive; this is in contrast to XMPP which favors direct routing of a message and synchronization is second.
In my own view it's a much more robust way of architecting communication: the server(s) should assume that remote parties will be off, and remote parties will come and get what they want at their own pace and time. Maybe they won't receive a few messages immediately but can immediately retrieve multiple when needed. With a stretch you could see a parallel with Kafka: instead of trying to send stuff to consumers as soon as it is produced, just store it, and when clients are up they'll process stuff.
I agree. One could use the Matrix specs to build some sort of message queue (using rooms) where human (text, markdown) and machine (json-ld) could communicate and interact..
It federates itself like SMTP does, I guess? If you translate and rotate their solution (abstractly speaking) you arrive at some very interesting ways to create a federated website/app/thing. Inspiration is always a really hard thing to nail down.
From a technical standpoint, there are six specifications (Matrix, Mastodon, XMPP, SIP, SMTP, Microdata) that have gotten the "future of the internet" partially right, in my opinion. Some union of the them, excluding the unfortunate bits, is likely the email/Twitter/Facebook/what-have-you killer. Putting that in consumers' hands and getting them to use it is another story, but we do have the starts of a technical/back-end answer.
For example, you could embed text document edits inside of Matrix messages as Microdata (ignorantly spamming someone aside with thousands of character edits aside). Is your spouse doing their taxes? Send them a chat message with Microdata explaining to the form where the attached document goes.
As a general goalpost, WeChat (having circumvented federation problems) in China is a really great example. You can pay for food at a hotdog stand on the street with chat. Uber merely facilitates communication between taxis and commuters. Whatever the project(s) you are referring to, software usually ends up solving communication problems. Recursively simplify your problem, ultimately realize how communication fits into it, then work your way back up to your initial idea. Federated IM is ludicrously powerful and, especially with graceful degradation, can lead to some sales leads.
One problem with upvoting comments instead of saying “+1” is the parent can’t see your upvote. But I’d like to explicitly say: I am also very interested in the answer to this question, if you have the time.
well, perhaps someone unaffiliated with Matrix or XMPP should update the wikipedia page to explain. https://news.ycombinator.com/item?id=19223963 is a very good summary, for instance.
From our perspective, the room replication is absolutely critical - it means that the network can partition and the servers can come up and down without the room being disrupted at all. It's the opposite of a MUC, where if the server hosting a MUC is inaccessible or goes down, you're screwed.
It can even be bad for security: e2e encrypted messages are still replicated and stored on the servers. 30 years from now they might be decrypted by faster CPUs.
Encrypted 1:1 messages should not be stored on servers!
They should be sent between clients p2p stile or at least forwarded by servers without storing them.
If you recall that the NSA is already storing large amounts of internet traffic for later decryption, whether or not some server stores it is mostly irrelevant. Maybe you're worried about other lower-tech attackers, but I don't think that Matrix servers are going to keep 30 years of chat history (I imagine most Matrix servers are going to eventually use default retention policies). Not to mention you can run your own homeserver if you don't trust the operators of public homeservers.
Storing 1:1 messages (noting that Matrix doesn't differentiate between group chats and 1:1 chats) on a server is beneficial because you might not want to lose your entire private chat history with your family and friends whenever you lose a device (source: this happened to me multiple times with Signal -- which has an awful backup system that I didn't use because it simply doesn't work properly).
Now, there is obviously cases where you don't want the server to keep your messages forever -- and then you might want to have retention policies and so on. But I don't really agree with the security argument, since the most obvious attackers already likely have your messages, and it sacrifices a lot of convenience that most people expect (my partner didn't expect to lose all her Signal messages when her phone died unexpectedly).
the reasons you need encrypted messages stored on the server are:
* to synchronise them between multiple devices
* if you lose your device, to have a hope of recovering your history
* to be able to search them (either homomorphically or via a search bot you run)
The Matrix protocol is well worth the read. JSON-LD is a bit of a nightmare to work with, but the gist of it is a solid concept; it has drastically changed my approach to software design.