Now, Matrix allows arbitrary transports to actually put that over the wire - but mandates only the most comically simple (and inefficient) as a mandatory baseline. This is a plain HTTP PUT request of the above data encoded as JSON and a few URI parts. The reason for this is that HTTP is insanely ubiquitous and well understood; any random device or language these days can trivially send and receive messages.
However, there is nothing stopping you from using a more efficient transport for the data between your client and your server - we've been experimenting with everything from boring old JSON over WebSockets to COAP or MQTT and even capnproto. We haven't specced any of these yet, but we'll probably add them as optional profiles to the spec in future. Meanwhile plain old REST actually works pretty well in practice :)
The fun stuff in Matrix is all about the eventually consistent decentralised conversation history between servers rather than obsessing about the most efficient way to shove some key value pairs between a client and a server.
If this comment is serious (and I have my doubts), I'm left speechless... Don't even know where to start. I'll just leave it here http://www.theverge.com/2015/10/28/9625062/facebook-2g-tuesd...
Without even knowing much about the protocol, I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range.
> "I am almost positive that it's bandwidth requirements are well below even a relatively light modern webpage and likely well within 2G range."
I'm pretty sure this this is almost certainly the least, or at least within range of, quite likely the least definitive statement I might have ever read (or at least one of the lesser definitive of statements I've read within the past year, or at least the last few months, or so).