Bringing teams closer with WebRTC.
When I first heard about Sqwiggle I added it to the list of WebRTC companies I track and moved on. A couple of weeks ago, not sure how or why exactly, it dawned on me that one of the Co-founders was also the Co-founder of Buffer – an app I use a lot to schedule tweets and push multiple status messages on social networks when all I have is a smartphone. This immediately meant that there must be an interesting story behind it – an entrepreneur in the web domain going for something that does VoIP. So it was obvious that I’d approach Tom Moor, Co-founder of Sqwiggle and ask a few questions – the usual drill. Here are his answers.
What is Sqwiggle all about?
So Sqwiggle is an application for distributed teams to work more effectively together, essentially we are bundling ‘presence’, instant video/audio communication and a slick sharing experience into an app that runs on the web and on the desktop. Everyone on your team has a spot in the app where it shows an up-to-date image of them (taken from their webcam) – this way you can easily tell if people are about to chat, or busy. You simply click on any user to start an instant video/audio connection and click on multiple people to start a conference call in seconds. We’re also tackling sharing and really building our chat/share stream around the idea of sharing rich media like files, articles, videos, tweets etc instead of a plain old chat. The aim behind all of this is to make communication when you’re remote quicker, more efficient and perhaps a little more fun!
You were the co-founder of Buffer prior to Sqwiggle, which has nothing to do with VoIP. What made you start Sqwiggle?
Well, Buffer is a distributed team and we spent a fair amount of time travelling over the first two years that the company existed. While we were travelling we were also hiring, both in the US and the UK. Of course with a new company and this kind of setup one of the biggest challenges is communication, keeping the culture intact and everyone on the same page. I could see this was a problem that wasn’t being solved by the tools that we were using, such as traditional chat and video conferencing. During my time in San Francisco I met up with Eric (@ericbieller) and Matt (@mattboyd) who had actually begun tackling the same problem completely separately – it became clear quickly that it made sense to team up and form a company around solving the problem. We don’t really think of Sqwiggle as a VoIP company, although video and audio are core to the product it’s simply because they are the best way to achieve the company goal of connecting distributed teams.
In Sqwiggle, are conversations always 2-way or are there larger conferences?
At the moment we are limiting conversations to a maximum of four participants, and this happens over peer-to-peer. As we move forward we do have plans to introduce a central server topology to handle larger conferences if the demand is there. We’re tracking the size of conversations that happen on the system and we’ve found it’s actually quite rare that larger meetings are needed – at the moment – most conversations are short and between 2-3 people.
What do you do in your backend?
Our backend manages user presence, the state of conversations happening in the system, notifications and the sharing stream. We’ve purposefully kept the backend as thin as possible with most of the functionality exposed through an API layer and as much logic as possible moved to the clients.
What about the front end? What do you use for that?
Both the web and desktop apps are currently developed in Javascript, we use the excellent Backbone.js javascript framework to add some structure to proceedings but other than that the code is mostly in-house including the WebRTC and signalling layers.
Signalling. Did you opt for SIP, XMPP or a proprietary mechanism?
We’re using a proprietary signaling system based on websockets, this was due to speed of implementation more than any other factor as it was important to build our minimal viable product very quickly and prove the need for a tool like Sqwiggle. I’m sure that we’ll reevaluate this as the company grows.
How would you describe your experience of working with WebRTC?
A bit of a rollercoaster perhaps?! When everything works it really is magical, but there are a lot of moving parts and debugging can still be a bit of a nightmare – particularly as Chrome still returns very general errors and DOM exceptions in a lot of cases. It’s exciting working on cutting edge API’s though and we’re really looking forward to datachannels becoming more stable so we can start working with them later this year.
Given the opportunity, what would you change in WebRTC?
Good question, personally I wish that they hadn’t gone with the offer/answer model and instead had adopted something more flexible for establishing the connection between peers. I think most of the features I’d like are already in the pipeline though – it should be a very exciting year ahead in this space…
What’s next for Sqwiggle?
Apart from constantly improving the video and audio side of things we have tons of ideas in the pipeline, right now we’re working on bringing Dropbox integration and drag and drop file sharing to the app. I have some crazy ideas for how an iPad version of Sqwiggle could work that I would love to make a reality soon!