Now that’s what I call using WebRTC creatively – someone that focuses only on the data channel.
Ever since the Data Channel in WebRTC got implemented by browsers, I wanted an interview with someone using it. That said, I was also on the lookout to interview web people and not VoIP people who happen to use WebRTC.
To that end, there’s no one better than Hadar Weiss, CTO and Founder of Peer5. Someone who guest posted here about the data channel already. To me, it was fascinating to hear about WebRTC from a perspective of a web guy.
What is Peer5 all about?
Peer5 is all about bringing powerful peer-to-peer capabilities into the browser. We deliver content more efficiently and give better experience for users.
When did you start using WebRTC?
We started early experimentation in late 2011. It was the wild west back then, and WebRTC was far from being standardized. Chrome and Firefox haven’t even integrated PeerConnection yet. We played with an implementation from Ericsson which customized Epiphany browser and included a proprietary API for data transfer. I remember it was quite bumpy at that time but we somehow managed to pull a POC that proved to us what can be built on top of WebRTC.
What excites you about working in WebRTC?
That it breaks everything we know about the web. The most fundamental rule in web development to me is “the client side can talk only with the server”. WebRTC changes it so you can connect browsers and make them communicate P2P. Removing this Client/Server barrier is HUGE and is changing and will continue changing how we all think about web development.
You decided to focus on the data channel and in the domain of content delivery. Why is that?
WebRTC has become really popular due to its “main” API which enables video (or audio) streaming via P2P. This API is very useful in scenarios where you want to build a 1-to-1 video conference app. But WebRTC has a fantastic core which can actually transfer any kind of data very efficiently. To fully leverage this core, RTCDataChannel API was added. It is a more generic API which lets us send raw data, encoded in our preference. This API is perfect for content delivery and we use it to deliver files, images, audio, video and also dynamic real time application data.
What signaling have you decided to integrate on top of WebRTC?
We use a proprietary signaling protocol. It’s a simple protocol we’ve developed in-house and is fairly easy to work with. Our requirements are quite different from most WebRTC apps, so although we are against inventing the wheel – in this case I think it makes sense.
Backend. What technologies and architecture are you using there?
We are 100% Javascript on the both client and server. We run on node.js and use WebSockets extensively for all the C/S signaling. Our “coordinator” server makes the decisions about how to connect between the peers. Once the coordinator decides to match two peers, there’s a standard handshake process which involves an ICE server, another piece in our backend.
Given the opportunity, what would you change in WebRTC?
I’m not sure about WebRTC, I think it’s too soon to tell, and the specs are still evolving, certainly the implementations. I do know that I wish IPv4 would have been written with 128 bit addresses. NAT is a pain that isn’t going away anytime soon – if ever.
What’s next for Peer5?
Recently, we have published our file sharing application that uses Peer5 platform – Sharefest.me. We aim to make it better, faster and more intuitive. We have rolled out registration to its bigger sibling “Sharefest for websites” which brings Sharefest capabilities into any website that wish to empower its downloads. Our API is also about to be upgraded into a clean, easy to use interface for web P2P. There is even more up our sleeves and we’re taking it one step at a time towards the vision of making the web decentralized, faster and better. This is just the beginning.
–
The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.