WebRTC is but a technology. Its adoption happens at the edges.
It is interesting to see what people do with WebRTC – what use cases do they tackle and what kind of solutions do they come up with.
Here are a few opposite trends that are shaping up to be mainstream approaches to wielding WebRTC.
1. Aggregation
In many cases, WebRTC is used to aggregate. The most common example is expert marketplaces.
Popexpert and 24sessions are good examples of such aggregators. You open up your own page on these services, state what services you offer and your asking price. People can search for you and schedule a video session with you. Interesting to see in this space LiveNinja who recently shutdown their aggregation service, shifting towards and embedability alternative.
2. Embedablity
The opposite of aggregating everyone into a single domain is to enable embedding the service onto the expert’s own website.
The company will offer a piece of JavaScript code or a widget that can be placed on any website, providing the necessary functionality.
Aggregation of Embedability?
Which one would be preferred, and to whom?
The Vendor in our case, has more power as an aggregator. He is in charge of all the interaction, offering the gateway into his domain. Succeeding here, places him in a position of power, usually way above the people and companies he serves.
The Expert may enjoy an aggregator when he is unknown. Having an easy way to manage his online presentation and being reachable is an advantage. For someone who is already known, or that have spent the time to make a brand of himself online, being aggregated on someone else’s site may dilute his value or position him too close to his competitors – not something you’d want doing.
The Customer on one hand, can easily find his way through an aggregator. But on the other hand, it places the expert or service he is reaching out to at a distance. One which may or may not be desired, depending on the specific industry and level of trust in it.
Ben Thompson has a good read about aggregation theory which I warmly suggest reading.
3. Silo
Most WebRTC services live in their own silo world. You envision a service, you build the use case with WebRTC, and that’s it. If someone needs to connect through your service – he must use your service – he can’t get connected from anywhere elsewhere. Unless you add gateways into the system, but that is done for specific needs and monetization.
I’ve talked about WebRTC islands two years ago. Here’s a presentation about it:
WebRTC makes it too easy to build your own island, so many end up doing so. Others are hung up to the idea of federations:
4. Federation
Why not allow me to use whatever service I want to call to you, and you use whatever service you prefer to receive that call?
Think calling from Skype to WeChat. Or ooVoo to Hangouts. What a wonderful world that would be.
Apparently, it doesn’t happen because the business need of these vendors isn’t there – they rather be their own silos.
Who is federating then?
- Some connect to the PSTN in order to “federate” – or to enjoy the network effect of the legacy phone system
- Those who have a network already (federated or not), end up using WebRTC as an access point. That’s what Polycom did recently with their RealPresence Web Suite.
- Solutions such as Matrix, looking to offer a framework that enables federated signaling that is suitable for WebRTC as well
Why is this important?
At the end of the day, WebRTC is a building block. A piece of technology. Different people and companies end up doing different things with it.
Need to understand WebRTC and how to design and architect real world solutions with it? A first step is to understand the servers used to connect WebRTC.
It is indeed surprising that Embeddabiity is not opted by all WebRTC applications. After all it comes for free, given that URL is the natural way to access any WebRTC service and URLs can be embedded in any number of places. There is no need to develop any special Javascript code or a widget. I can see why “market creators” would not adopt embeddability, since they want to confine conversation within their platform. But not others. After all why would they write off a major benefit of WebRTC.
Regarding your Silo/Islands and Federation, I am afraid I have to repeat my comments that I have made before. Typically, in the context of communications, terms “Silo” and “Islands” are used in negative light. I am not sure you mean to insinuate that connotation here. Personally I prefer the term “Moat”. Whereas Silo and Island suggest that communication is allowed only between people who are already in that Silo or Island, Moat suggests that outsiders may be permitted on a case by case basis. Silo and Island suggest rigidity, while Moat is flexible and dynamic.
The concept of Federation is gotten hold of WebRTC world even though it is not needed at all. I am not sure why it is so, except for my suspicion that advocates of Federation feel an aura of sophistication and enlightenment. Hitherto, federation between different communication services is critical because the clients were service specific. But WebRTC has done away with all the reasons that require federation:
1. the clients are general purpose browsers,
2. the signaling protocol is dynamically downloaded
3. identity can be separated out by using authentication schemes like OpenID Connect or other single sign on schemes.
So an app that that is using WebRTC does not have to federate with a third party app/service to let their users to contact its users.
You being an evangelist of WebRTC, are undercutting the main advantage of WebRTC by perpetuating the dichotomy. Every WebRTC app should embrace embeddability and it is simple to realize the benefits of federation without relying on third parties.