It's quite good at realtime, and especially reliable realtime. Compared with protocols like XMPP, Matrix scores way higher on reliability because it has message IDs and message ordering baked into the protocol, so it can actually converge on a correct state after network flakes. (I consider this a pretty big deal because silent message drops were a pretty regular issue for me in XMPP, and we all know about netsplits in IRC. I've simply never had silent message loss in Matrix because the protocol is simply better.)
I'm not trying to compare xmpp (which I know a bit) and matrix (which I don't know about, really), but losing messages with xmpp is probably a thing of the past. There were a good number of issues (the protocol originally didn't expect mobile devices that change addresses/connectivity all the time), but with a somewhat recent set of client and server you should be good.
It's true that it's a big hunk of JSON. And I'll readily concede that when efficiency matters, I'm more partial to binary formats like CBOR. But XMPP is XML, which... isn't exactly lighter.
There's another HN thread where I've talked more about XMPP vs Matrix here: https://news.ycombinator.com/item?id=9772968 -- long story short, I tried to write an XMPP client, and I got grey hairs, fast. The story for consistent delivery is pretty much bananas. (And huh, based on that date, I guess I've been a Matrix convert for almost TWO years now! Time flies.)
I'm not entirely sure what the comment about battery is about either. If anyone has a networking technology that can work without turning on the phone radio, I'm sure we'd all love to hear it...?
Practically speaking, I leave the Matrix Vector app open on my phone constantly. As of this morning, I have half a charge, and three more days of charge to go. I don't have any other apps to provide a good comparison here, but I'll leave this screenshot here for what it's worth: https://matrix.org/_matrix/media/v1/download/matrix.org/IgkU... Looks like my phone has spent about the same order of magnitude of battery on just plain paging the cell towers as I moved around the city. As other comments on this thread cover, if you use proprietary Google stuff, you can wake the phone up slightly more efficiently. But whatever this app is doing works pretty fine for me.
XMPP only has to turn the radio on full power mode when it gets a new message or creates a new connection (the tower sends the LTE radio a paging message telling it to wake up, then the long-lived TCP connection can receive data). Matrix has to turn the radio on every single time it wants to check for data, regardless of whether there is data to receive or not. This is the problem with HTTP based protocols; you might have a persistent TCP connection, but it doesn't help you when you have to send a request just to check if there are new messages.
It's not a case of radio off vs on, it's a case of the radio being able to stay in RRC_IDLE mode (which I've probably called "off" more than once, which is where the confusion came from I'm sure, apologies for that) for more of the time, where as with Matrix it almost always has to remain RRC_CONNECTED mode.
I don't believe this is true. The long-polling that Matrix does in the baseline impl is just a long-lived HTTP request which blocks until the server has something to send it. Radio-wise this is conceptually the same as an XMPP TCP connection.
The only difference is that (in the baseline impl) you start a new HTTP request after receiving each response - which chews some additional data relative to XMPP. The radio will already be spun up from receiving the previous data, though, so it shouldn't impact significantly on battery consumption.
Also, we put a timeout on the long-lived request (typically 30-60s), to aid recovery in case of the request or connectivity breaking - which could theoretically increase bandwidth and radio battery consumption, but in practice almost all Matrix use cases involve receiving events more frequently than the timeout, so the timeout doesn't actually have much impact on battery.
That said, there is (deliberately) huge scope for improvement with alternative transports - using strict push rather than long-polling; using transports with less overhead; using more efficient encodings, etc.
It has to make an HTTP request every single time it wants to check if there are new messages… I wouldn't call that a good realtime protocol (though in fairness, I'm sure it's good for many other things).
Matrix isn't tied to HTTP - it's just the baseline protocol. The idea is for people to propose whatever custom efficient transports they like, maintaining HTTP as the lowest common denominator. For instance https://github.com/matrix-org/matrix-websockets-proxy is such a WebSocket proposal.
Sure, and that's better, I agree, but XMPP also works the same way, but it's base protocol is much lower layer (a TCP connection instead of a higher layer protocol like HTTP). The point is that the default (which is always what most people will stick with), is too cumbersome and inefficient for realtime applications.
Agreed that XMPP is much lighter in terms of server processing than Matrix (they are doing entirely different things, after all). In terms of transport, yes: Matrix's default HTTP/1+JSON transport is heavier than baseline XMPP.
I haven't checked but my hunch would be that HTTP/2+JSON would be very similar to typical XMPP in terms of bandwidth, if not better, and obviously requires no spec changes; just an HTTP/2 capable client & server/LB.
In terms of what transport people use: well, I assume end-users will use whatever the best performing clients implement. Riot is the flagship client and will obviously do better than HTTP+JSON; meanwhile we've had a lot of pressure from Weechat to start using a better transport (e.g. websockets) for them (https://riot.im/app/#/room/#matrix:matrix.org/$1477998960439... meanwhile Ralith (the author of the NaChat Qt matrix client) has been working himself on a capnproto transport due to wanting something faster & better than the baseline.
So we're not particularly worried that most people will stick with the baseline for daily usage. Instead, it'll act as a really nice and easy on-ramp for new developers, debugging/deving on the API, etc. Anyone serious will end up using a better transport.
Finally: it's worth noting that adding E2E by default into Matrix increases the complexity of clients enormously - so we expect the plain `curl -XPUT /_matrix/client/r0/rooms/.../m.room.message --data { "body": "hello world" }` style APIs to increasingly be just for experimentation, initial dev and prototyping. As soon as you want to start talking E2E folks will reach for a full client SDK, at which point they will get access to both E2E and whatever weird & wonderful transports that SDK happens to provide. So, again, the majority of users won't be on plain ol' HTTP.
