well my story with webrtc is too long!
actually i didn’t knew anything about webrtc.
i was not even a html5 fan.
as i remember i was a flash game developer and a flash lover who profit from making small flash games for mochimedia for years…

since android and ios pushed flash player to the corner and finally cause mochimedia shutdown, small indie flash game developers like has been homeless. 🙁

i started learn html5 around 2 month ago!. ( after flash i wasted 1 month on learning “unity3d”, but unity3d was not what i looking for…)…..

For the first game and first try with html5 i decided to make a realtime multiplayer ball game for iranian players. [ yet did not knew anything about webrtc] .
my first option was write a TCP/UDP Socket server to handle the game physics and send the physic states to players at high frequency. okay good! but wait!
here is a BIG problem!
iran have the lowest internet speed between other countries, i tried to test the game and the results was very bad. high latency, bad ping and… (as my server located at USA and my users are from IRAN).
soon i found iranian players , include myself, CAN NOT play a realtime game when the server located at another country and players are at another country far away with low speed internet connections.
i had going down and i had do something before i lost more users.
after many researches i found there is something new in html5 which lets me create p2p connection between browsers.
in this case (p2p) the iranian users could easy join the game with low latency without any data transmit to a server which is far away and at another country and can play the game in realtime with no lag.
so i did dive to WebRTC and learned it quickly and for first try, i developed that riskygear soccer.
i developed this WebRTC soccer for b30d.ir not for RiskyGear.com.
the funny thing is iranian players couldn’t play this game well, because of many strict firewalls…
when i seen iranian players can not play this game, i decided to register a “.com” domain and put the game on it, maybe players at other countries could play it.

i heard the WebRTC word less then 30 days ago. yet don’t know much about it. i don’t know what i can do with it exactly yet!.

one of the most interesting parts of webrtc is media stream. but i can not play with it much, while my maximum internet connection speed is 256kpbs which is not real 256kps. how ever i can play with local apps.
for example first i wanted to implemenet a VOICE CALL in this soccer to let Soccer players Talk to each other realtime, but i realized when iranian users most have 1258kpbs and 256kpbs internet connection with limited bandwidth, they can’t broadcast the such a big data even with p2p. so i resigned to use voice call in game.

in additional all WEBRTC resources blocked in my country! i hardly can change my ip addresses to get access to them, but most of the times i fail.
because of political reasons google decided to block IRAN.
iranian users can not access code.google.com or webrtc resources…
i wrote about it more here: http://riskygear.com/wp/riskygear-first-post-and-introduce-myself/

anyway if i developed something new with WEBRTC. i will tell you.

Ali,

Thanks for the link! What do you plan on doing next, either with this or elsewhere with WebRTC?

Jesse,

These questions aren’t simple. I am no expert in these areas, but I’d say that the projects you need to look at closer are uProxy, Blippex and Grimwire. Somewhere in-between the way they use the data channel in WebRTC is probably the architecture and the means to implement what you are looking for. Main issue with WebRTC in this case? Forcing Chrome/Firefox on the end users and having enough people using the service to begin with. Other than that, it will be in implementation details – something that is more critical with privacy related services than any other domain.

For a little background on what I’m talking about: Recently there has been a lot of focus on the importance of developing more secure alternatives to email, instant messaging, browsing, etc. … but I’ve seen very little focus on the need for development of alternatives to corporate/centralized search engines. For obvious reasons, developing alternatives to corporate search is every bit as crucial for protecting privacy and free speech as encrypting our emails/chats, and anonymizing our browsing, but the few existing solutions for decentralized/P2P search (e.g. YaCy) all seem overly complex (and thus unusable to most users) and require downloading a standalone application to use. These standalone P2P search applications don’t really make sense from a usability perspective. It’s unrealistic to expect hundreds of millions of users to download a standalone Java app, and configure a P2P index node (especially when configuration is as complex as it is for Yacy).

It seems to me that it would make more sense to use WebRTC to facilitate P2P connectivity in the web browser, so that the searching and indexing can be done via a simple browser plugin that can be installed by anyone with one-click. This would simplify indexing (e.g. just use the bookmarks/recent sites visited by default, rather than forcing users manually configure it), and would allow people to just use the browser search bar as usual.

There would still likely need to be some sort of standalone signaling/tracker servers set up to bootstrap search/index nodes into the P2P network, but most of the work — i.e. all of the indexing, searching, routing, etc. — would be done by the nodes using the browser extension. And almost all of the complexity would be hidden from the average user. If P2P search could be simplified in this manner, I feel that the adoption would be much more rapid than if it’s based on complex standalone apps.

What are your thoughts on this? Do you see this being useful? What are some of the problems/limitations you see arising with WebRTC based P2P search?

Thanks!

Hi Michael that’s a cool thing we have running in our native application for a while now (We are using the signaling connection BTW). But you will need a plugin to control the USB HID Interface to do that in the browser.

I do think that this use case was among Adobes reasons for acquiring amicima in 2006. They had it product ready in 2009, i.e. built at a time when flash video was ubiquitous.

Expect a codified response on the “video tag” topic soon… 🙂

Yap. That should do the trick