[ara4n]

SIP+SIMPLE/MRSP's overheads are just as bad as HTTP/1.x, if not worse. We decided to build Matrix after 10 years of fun doing commercial SIP and XMPP work; we have some experience. For instance, the worst scenario we've seen in a real-life SIP/MSRP user-agent in the wild was 50KB of SIP/MSRP nego to send the word "Heh" between two contacts (with a delivery report) :) Meanwhile SPDY and HTTP/2.x improve the overhead situation and pipelining situation enormously - although frankly we haven't seen any real-life problems using HTTP/1.1 yet at all...

The "simplicity" of HTTP I mentioned in the Matrix blurb refers to the fact that RFC2616 is relatively compact and self-contained, whereas SIP/SIMPLE/MSRP involves a huge number of RFCs, different protocols (SIP,SDP,MSRP...) and really is a lot more complicated to implement than just doing GETs and PUTs.

Now, the irony is that rather than being "designed by someone who doesn't know much more than how to build web apps" - it's more the other way round. Our experience is mainly with SIP/RTP/STUN/ICE/TURN etc; genuinely RESTful APIs are relatively new territory for us.

I would genuinely love to know what aspects of the Matrix client-server (or server-server) API is 'not anything like RESTful' - it's not too late for us to change the APIs (they've already been rewritten several times, oscillating between more or less RESTful purity), and half the point of releasing Matrix in its current early proto-form is to get detailed feedback from folks on whether we've Got It All Wrong :)

(disclaimer: Matrix is all my fault)

[zAy0LfpBZLC8mAC]

Oh, I certainly didn't mean to imply that SIP was somehow particularly efficient - I was just surprised that anyone would think HTTP was an improvement over SIP, in particular given that you just swap the SIP stack for an HTTP stack and the torture testing of SIP parsers for torture testing of HTTP parsers, especially so if you consider the history of SIP where people originally intended SIP to be parsable using HTTP parsers.

As for the huge number of RFCs: Well, those do cover a whole lot more than passing blobs around? That aspect is fully covered by the SIP RFC, and only a relatively small part of it, the rest is concerned with session establishment and teardown, which HTTP obviously isn't concerned with at all.

Which is why I am wondering: What is the point of using HTTP? What is the functionality that it provides you with that would justify requiring an HTTP stack in every endpoint, including the security risk from all that complexity?

As for RESTfulness: REST is in conflict with a fixed URI scheme, REST allows only for a fixed entry point, beyond that, all other relevant URIs should be discoverable from the returned representations. And no, I am not saying, your stuff should be RESTful, I'm just saying that it's not.