This doesn't obfuscate metadata like room membership or profile data however; but fixing this is Hard. For now it's just a fact of life that Matrix servers have visibility on communication metadata - i.e. the identities of who talks to who, and when, and with what kind of event. In future we may support better privacy preserving semantics by evolving the federation architecture: eg running homeservers on clients and using Pond-style hidden Tor services for message transport, or layering on GNUnet as a transport. We've tried to design Matrix to support this sort of evolution, but right now today Matrix provides the same level of metadata privacy ss (say) an IMAP or SMTP server.

The thing that sucks is that as end users we end up having all our chats and identity fragmented over all these different silos - be they selfhosted ones or proprietary SaaS. There's no way I'll rely on MatterMost or any of the above unless I can access my existing communities (be they on IRC, XMPP, Slack, HipChat or whatever); adding yet more fragmentation into the mix helps nobody.

This is why it's vital to have an open standard for decentralising the conversations between all these different islands that kills fragmentation whenever a new one pops up. And it's actually beneficial to new contenders like MatterMost as it could help them onboard users into their UX and app without having to start new conversations and contacts.

[Disclaimer: Matrix.org is such a standard, providing an open HTTP API for decentralised chatrooms, and I work on it.]

The server-server API is currently just targetting https+json just for expedience in getting started, but nothing to stop us negotiating more efficient transports in future - capn proto has come up a lot in conversation as a possible option. Handling signing is a bit more fun as we currently rely on signing canonical json, but surmountable.

As for binary transfers... well, random blobs are just handled as pure HTTP with a mimetype currently :)

You don't need an email address to sign up currently - the way it works is that it's up to the homeserver to decide how to validate new users (if at all). So Matrix.org uses a CAPTCHA to check you're human, but otherwise just sends a username & password. We also let you optionally specify a mail address, mainly just to prove that we do support validating 3rd party IDs like email (and in future MSISDNs and other IDs).

For gatewaying, the main thing we've been missing is an Application Service (AS) API on Matrix which lets your gateway masquerade multiple users & rooms/channels from the remote protocol. Currently you can write a back-to-back bot which creates, per user, an IRC user on the IRC network and a Matrix user on the Matrix network and bridges them together - this is how the current Matrix<->IRC bridge works. This sucks if you want to easily project hundreds of users & channels from IRC into Matrix and vice versa, though - you need better server support, a bit like IRC Services' architecture.

The good news is that this is very nearly implemented - we got our first AS up and running a few hours ago (it currently just logs traffic rather than bridging it anywhere). It's all happening on the application-services branch of https://github.com/matrix-org/synapse and the doc is at https://github.com/matrix-org/matrix-doc/blob/application-se... and https://github.com/matrix-org/matrix-doc/blob/as-http-api/dr... if you're interested.

Twisted is probably overkill for many ASes, but it could be a great way to do the XMPP & IRC bridging in future.

I've never played with Friendica/Red/RedMatrix/Zot, but from what I can see, it's more about federated blogging/social networking than messaging or pure JSON synchronisation like Matrix. Architecturally I'm not sure how they compare - I only just found https://github.com/friendica/red/wiki/zot; we'll have a read and see what the difference is.

Something we're very keen to do with Matrix.org is to build as many gateways and bridges through to other comms ecosystems as possible - so the fact that both Matrix.org & RedMatrix (& Diaspora & Identi.ca & all the others) are operating in a similar space isn't at all a problem - so long as they all talk to each other. It'd be a bit embarrassing if we were building federated communication systems which couldn't gateway to each other!

1. Matrix's baseline featureset is much more comprehensive than XMPP and doesn't yet support API extensions; only datatype extensions. So for a Google to become the defacto implementation and then start lobotomising the featureset they really would not be speaking Matrix at all any more.

2. Federation is completely fundamental to Matrix. All rooms are distributed over all participating servers with no single points of control or failure. So rooms and the network will always live on in other servers, even if a big player becomes a default provider.

So: if you want decentralised message history as a first class citizen, use Matrix. It's not just for group chat; it's for any data.

If you want lower-latency message passing with history as an optional extra, use XMPP.

In terms of how to make XMPP cool again - projects like XMPP-FTW and Buddycloud and FMUC are pretty cool :)

curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roo...

...and we'd like to keep it that way. But you can always insist on only ever communicating with folks who are on E2E crypto clients if you so desire.

We're trying to fix this with Matrix.org - folks frustrated with yet another communication silo might want to check it out and help us tear down the walls between these gardens. (obvious disclaimer: i help run matrix.org)

The biggest difference we have over XMPP is probably that messages in Matrix get synchronised over all the participants of a conversation... so you get distributed chat history for free, and no single points of failure on group chat (as you do with XMPP MUCs). And obviously Matrix is plain HTTP+JSON rather than messing around with XML.

One of the reasons we built Matrix is because, in practice, pretty much all the current big players started off using XMPP for developing their chat solutions: Google Talk was originally XMPP; I believe Facebook Messenger was built out at first on ejabberd; WhatsApp was originally XMPP etc; even APNS was originally XMPP!

But ALL of them have ended up mutating it to a proprietary closed standard - and nobody has even tried open federation other than Google's misadventure with Talk. So, unfortunately, it seems XMPP hasn't ended up being the interoperable web-for-IM that we all hoped.

Now, I have absolutely no idea if Matrix will be more successful in solving the problem; the hope is that by keeping it simple and using HTTP APIs there's more of a chance that players of all sizes will start exposing Matrix APIs for federation. Only time will tell. It's also worth noting that end-to-end encryption is a relatively recent potential obstacle: given iMessage and Telegram etc are all end-to-end encrypted, for them to ever federate with Matrix we'll need to support the same semantics and crypto. Hopefully we're going about this the right way (although end-to-end crypto isn't formally specified or implemented yet), but will be an interesting challenge. And one that XMPP hasn't tried to solve at all, as far as I know.

(disclaimer: Matrix is my fault)

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)