So, for context: we ended up writing Matrix after literally 10 years of building SIP infrastructure, so we have some experience in SIP (and XMPP's) shortcomings :) The short answer to "why not extend SIP" is that SIP stacks are fairly fiddly to write and get right; and SIP/SIMPLE/MSRP is typically a lot more verbose and convoluted than HTTP (and hugely more verbose than SPDY and HTTP/2.0). There's no support in SIP for distributed storage of state, and there's no support for paginating and storing conversation history at all. In fact, some of the SIP community has even ended up bolting on IMAP(!) for storing conversation and call history :S Meanwhile, given HTTP is pretty simple and completely ubiquitous, so why bother with an alternative stack at all?

In terms of "jesus, not another protocol I have to support" - I completely sympathise, hence quoting http://xkcd.com/927/ in my blog post... We didn't do this lightly :)

One way of thinking of this is that right now you have LOADS of HTTP APIs out there for messaging - Twitter, FB, http://api.ihackernews.com, Reddit... they're sufficiently easy to implement that every new site goes and builds a new one, and developers have to go and learn each new one every time. Meanwhile, none of them will ever federate or interoperate - the whole thing's totally fragmented.

So whilst Matrix is indeed yet another API to support - hopefully it's one that might actually help solve this problem... so that the next time that someone wants to add a messaging HTTP API to their site, they can follow an interoperable pattern rather than reinvent the wheel again. Perhaps a better way of describing Matrix is "two-way RSS for arbitrary data, with distributed history"

Does this help justify things at all? (Disclaimer: Matrix is all my fault)