Sunday, February 22, 2015

The WebRTC Data Channel - finally i get it

*The WebRTC Data Channel*.  i was just about to "repurpose" this community to plain old "Social CRM" when I came across this article.  I would still be intensely interested in building such an application, but not being a developer - and not having identified an "angle of approach" I had to move on - but have been gaining a great deal of understanding of what commercial CRM's do.   

When we were collaborating on this project - or trying to, I noted we hadn't answered that most basic of questions "where is it?".    Team collaborators kept falling back on client service models and we only vaguely decided that it "would be in the app store" - which left unanswered the question, "where is the data channel?" - and how would peers even know another peer exists?    n 

Perhaps the other team members really did understand this - I didn't.   Even with my hippy notion of "peer to peer" something seemed amiss - the tech giants would never allow what I was proposing- not without getting their fingers in it at least, and a number of other things "just didn't add up".   

Then I read this article and suddenly I get it - or at least see a path forward, and I recommend any members of this community who are still interested in this project read it and also do the demo - it is short and quick.  The author correctly notes that the standard has been changing - causing lots of confusion, and also what we had noticed here - that the audio and video channels seem to get all the attention - no doubt because they are more "sexy" but I continue to believe there are huge opportunities in that boring data channel.   Here is a statement the author made that suddenly caused me to "get it":

"While WebRTC is direct peer-to-peer communication, it requires a centralized server to handle the initial delegation of the two peers. There needs to be a 3rd party that helps the two peer-to-peer clients preform the WebRTC handshake. In this case, we have used Firebase. You can use WebSockets, HTTP calls, or anything else that you'd like. Firebase works nicely for this so we've used it here". 
Now, if you have tried their demo the first thing you might have noticed is that they connect you with another peer computer through what they call a "shared identifier" or code word - but in functional terms that is identical to our "interests" keyword.   In this case, two matching "identifiers" will launch a chat client, but shouldn't be conceptually all that different from our intentions to push "interests' like "stamp collecting" through that channel, which would bring up a list of other stamp collectors.   

So who is this mysterious entity building the intermediary for RSS peers?    Go ahead, click the https://www.firebase.com/ link - I dare you, and read their first announcement to learn who is behind it.   In a way, I am almost relieved - when something looks to good to be true, it usually is. 

Still, after all this time, i am convinced an opportunity remains - and there is a silver lining - few people understand the data channel and the attention remains on video and audio - and since those are bandwidth hogs the pricing is set up for those applications, but data is a miniscule fraction of that - we could probably operate a large network fairly cheaply.   If you are really ambitious start a firebase account and go through their tutorial - they have a 5 minute quick start and while is really is for developers, I can at least see that is it possible now. 

I still don't see "the way" but I can sure see further down the path. 


Note: This post was written for a private forum where we are discussing the possibility of a "Social CRM" over WebRTC.  Contact me if you want more info