Solving the WebRTC Interoperability Problem

Ancient Chinese curse: May you live in interesting times.

Let's face it, that's exactly what life in communications has been these past several years. As soon as we get used to one "next big thing," another one comes along to take its place. In my lifetime, I've seen us go from analog to digital to proprietary IP to SIP. Where once we called, we now text and chat. It used to be enough to hear someone's voice. Now, we want to see them move at 30 frames per second (with some not satisfied with anything less than 60).

If you've been paying attention, you should know that the current "next big thing" is WebRTC. As someone who spends 75% of his work day staring at a Web browser, I am a big fan of moving my communications into the same form factor that gives me Google, YouTube, Facebook, and, of course, No Jitter. Putting communications into Firefox or Chrome means one less application to download and fewer keystrokes to invoke it.

However, as I learned a long time ago, there is a serpent in every paradise. As promising as WebRTC is, it comes with a set of concerns that cannot be ignored.

For me, the biggest concern is that WebRTC purposely does not define a signaling protocol. While the designers of WebRTC are proud of the flexibility that this brings, pragmatic people like me are confused and frustrated. No standard signaling protocol means that there is no guarantee that anyone's WebRTC application can talk to anyone else's WebRTC application. This makes it difficult to create a generic application that truly replaces the telephone. It's like having an AT&T cell phone that can't call folks on Sprint, Verizon, or any other non-AT&T subscriber. How long would we stand for that?

Introducing Matrix
The people at Matrix recognized this problem (yes, they call it a problem) and decided to do something about it. Through a series of Web services APIs (Application Programming Interfaces), they've created an open standard for interoperable instant messaging and VoIP. This allows users the flexibility to choose the interface they are most comfortable with and communicate with users that choose completely different user interfaces. Using my previous analogy, those AT&T users on their iPhones can now call Sprint users on Samsung devices.

Established as a non-profit, Matrix software is entirely open and readily available to anyone who wants to create federated solutions. You programmer types are probably familiar with Matrix's delivery mechanism – GitHub. GitHub is a central repository for open source software that can be downloaded, enhanced (if desired), and used by developers to create their own solutions. I personally used GitHub when I was writing my first WebRTC application.

Although I have been using the term interoperate, Matrix is really about federation. With federation, applications exchange data in a compatible manner. Think of it this way: I use Gmail for my personal email and Microsoft Exchange at work. However, there is nothing that prevents me from freely sending emails between accounts. I never have to consider who the recipient is. I simply compose and send.

Matrix allows the same sort of federation between instant message and VoIP. While there have been other attempts to accomplish this (SIP, XMPP, and RCS), technological, usability, and economic factors have limited their success in providing true federation.

The Matrix Value Set
I recently had the pleasure of speaking with a number of the developers at Matrix and walked away from our conversation with these highlights:

Matrix functionality is implemented with RESTful HTTP APIs. The geeks in the audience know this is the best way to create an open interface between disparate systems.
Matrix provides reference implementations for servers and clients. This makes new development much simpler.
Matrix is building security in from the ground up with cryptographically signed conversation histories. End-to-end encryption is coming soon.
Matrix is identity agnostic and aggregates existing IDs such as email, MSISDN, and Facebook.
While not built on approaches such as XMPP and IRC, Matrix solves the challenges those technologies failed to conquer. The goal was to create an architecture that tackles the interoperability problems that were not addressed by previous approaches.
Matrix chose to bypass standards bodies such as the IETF, W3C, and 3GPP. The plan is to get quality code out as quickly as possible and pursue the standards route in the future.
Matrix supports conversation persistence. A participant can leave and rejoin a conversation and then have that conversation resynched. This allows users to see what they missed while they were away.

Simply put, a WebRTC developer is able to create the solution he or she wants to create and let Matrix worry about how it will federate with other developer's solutions. This preserves WebRTC's flexibility in regards to signaling while making its applications more accessible and therefore, universal.

Planting the Seed
Matrix is still quite new. Development began on the software in July 2014 and a beta version was released in December. Clearly, things are just getting started, but the folks at Matrix are dedicated to solidifying the specification and enhancing the APIs. A reference server is up and running and it's easy to create an account and begin playing with it. Additionally, Matrix.org contains a communal chatroom that allows users access to federated IM and VoIP calling via WebRTC. Despite the newness of Matrix, there is a lot to see and work with today.

If you are a curious nerd like me, I invite you to take a look at what they've done and have a go at the APIs. If you are less inclined to write software, consider the challenges you are facing today and imagine how technology like this can make your communications less complicated -- or dare I say it, less interesting.

If you found this subject interesting, please attend Andrew's session at Enterprise Connect 2015: Interoperability: Has Anything Actually Worked? Register with code NJSPEAKER to save $300 off current price of a full event or Tues-Thurs pass.

Matrix provides reference implementations for servers and clients. This makes new development much simpler.

Matrix is building security in from the ground up with cryptographically signed conversation histories. End-to-end encryption is coming soon.

Matrix is identity agnostic and aggregates existing IDs such as email, MSISDN, and Facebook.

While not built on approaches such as XMPP and IRC, Matrix solves the challenges those technologies failed to conquer. The goal was to create an architecture that tackles the interoperability problems that were not addressed by previous approaches.

Matrix chose to bypass standards bodies such as the IETF, W3C, and 3GPP. The plan is to get quality code out as quickly as possible and pursue the standards route in the future.

Matrix supports conversation persistence. A participant can leave and rejoin a conversation and then have that conversation resynched. This allows users to see what they missed while they were away. Simply put, a WebRTC developer is able to create the solution he or she wants to create and let Matrix worry about how it will federate with other developer's solutions. This preserves WebRTC's flexibility in regards to signaling while making its applications more accessible and therefore, universal.

Matrix is building security in from the ground up with cryptographically signed conversation histories. End-to-end encryption is coming soon.

Matrix is identity agnostic and aggregates existing IDs such as email, MSISDN, and Facebook.

Matrix chose to bypass standards bodies such as the IETF, W3C, and 3GPP. The plan is to get quality code out as quickly as possible and pursue the standards route in the future.

Matrix is identity agnostic and aggregates existing IDs such as email, MSISDN, and Facebook.

Matrix chose to bypass standards bodies such as the IETF, W3C, and 3GPP. The plan is to get quality code out as quickly as possible and pursue the standards route in the future.