Hello Firefox, this is Chrome calling • Hacker News Board

Re: Hello Firefox, this is Chrome calling

#101

Post by pbhjpbhj » Mon, Feb 04, 2013, 11:01 PM UTC

josh2600 wrote: post #96

icambron wrote: post #90

Earlier quoted context omitted.

It would seem to greatly lower the cost of building a Skype-killer, though, and that's a pretty big deal.

Sort of. Now you don't need to build client software, but that was never the real prowess or power of Skype, it was always the infrastructure. Think of it this way. Skype has 2 things that WebRTC doesn't: Signaling and a Directory. Without those two components, you just have a phone without a phone number :/. Lower barrier, yes. Easy? No, there are still significant costs.

Seems like Facebook is pretty close to solving signalling and a directory - in effect it already has them for their messaging service. If you enable chat on Facebook then people can already find you for chat and know if you're [reporting that you're] available.

FB is already in bed with Skype though I think so not sure how that would pan out in practice.

Re: Hello Firefox, this is Chrome calling

#102

Post by benaiah » Mon, Feb 04, 2013, 11:08 PM UTC

tocomment wrote: post #43

I'm not following what this is. Can someone explain it like I'm five?

The first guy is talking to the second guy, even though they're very far apart. We used to have to use a special part of the computer for this, but now we can use the regular part that we use for most of our other stuff.

We also used to have to ask another person every time we wanted to talk to each other this way. Now, some of the time, we can talk to each other without asking him first.

Explaining it like you're ten might be more useful:

You know Skype? Well, now we can do that on the Internet [Ed: I know, but you're ten, so bear with me]. Also, we can send the video straight from one computer to another. We used to have to send it far away, to another computer, and then he would send it to the person we were talking to. We can also hide what we are saying from other people.

Pretend you're mailing a letter to Grandma. Before, we had to mail a postcard to our mean aunt, who would send it to Grandma. Now, we can put it in an envelope and send it straight to Grandma's house.

Re: Hello Firefox, this is Chrome calling

#103

Post by taeric » Mon, Feb 04, 2013, 11:10 PM UTC

STRML wrote: post #80

taeric wrote: post #58

Earlier quoted context omitted.

I think this is ultimately my confusion. I'm at the point now where I'm actually usually advising family members on devices that rely less on browsers. Why not show a chat from gmail/whatever in a browser to a regular app on an android/ipad device? Even better, include another app in there. Just to really drive home how "open" this is. Also, why is this stuff better than SIP related technology from a while back?

I believe gchat would do that, google hangouts might integrate with the ios/android app as well (I have not tried this). The excitement here is that this is a non-flash solution, so technically it will work on any device that can run Chrome, regardless of whether or not it can / wants to run Flash. So in the near future this may make it into Chrome for Android and iOS. WebRTC is a very necessary step in removing Flas…

I guess I'm just confused by two points. First, the odd belief that non-flash automatically equals good. Second, that non-flash for some reason necessitated "in browser." Why?

Neither of these automatically grants any additional security. If anything, it is just tying us to fewer vendors that can do this. I guess it doesn't matter, but I can recall a time when I was able to choose which application handled certain content type. We seem to be saying we do not want that for video now.

Re: Hello Firefox, this is Chrome calling

#104

Post by jallmann » Mon, Feb 04, 2013, 11:27 PM UTC

nextparadigms wrote: post #92

mnutt wrote: post #85

Earlier quoted context omitted.

You're correct that you'll depend on another service for all the niceties, but I for one am super excited about decoupling all of those services from the connection itself. Hopefully it'll lead to a lot more competition and innovation in the space.

At the very least I hope it forces IM apps like Skype and Facetime to support WebRTC (that is possible for native apps, too, right?) so that in the future we get interoperability between them. Wouldn't it be nice if WebRTC pushed video-calling into becoming like e-mail, and you could take to anyone, regardless of what "video-calling app/service" they are using?

> Wouldn't it be nice if WebRTC pushed video-calling into becoming like e-mail

WebRTC doesn't define a signaling protocol. There are already protocols for that. SIP, XMPP/Jingle, etc. It would be nice if people started using them more. WebRTC only defines an offer/answer API (which is actually a big difference!)

So having two different services use WebRTC doesn't mean they'll be interoperable. (Unless the services intentionally make an effort to federate.) Any third-party attempt at interop between incompatible services is going to involve spoofing a connection to each service. While that's not impossible, WebRTC really isn't the interoperability panacea that people seem to think.

Re: Hello Firefox, this is Chrome calling

#105

Post by pjscott » Mon, Feb 04, 2013, 11:28 PM UTC

TranceMan wrote: post #95

aeflash wrote: post #88

Earlier quoted context omitted.

Unless the NSA/FBI/whatever is decades ahead in mathematical research from what is common in academia, or has computers that are many orders of magnitude faster than what we have today, well encrypted data is basically random data to anyone who lacks the keys. That's a pretty tough locked box.

And who packages that box?

You're veering awfully metaphorical, but it might be relevant to point out that the crypto implementations in wide use today are typically open source, and the algorithms themselves are public, and widely reviewed by independent cryptographers who have no incentive to do anything sinister.

Re: Hello Firefox, this is Chrome calling

#106

Post by navpatel » Mon, Feb 04, 2013, 11:28 PM UTC

TylerE wrote: post #25

dbaupp wrote: post #12

I feel like DataChannels are the best part of the WebRTC standard (or would be, if they were usable): a true p2p connection allowing transfer of arbitrary data without plugins or anything. This gives multiplayer games, file transfers, realtime chat and collaborative editors (let your imagination run wild...) and the only thing a server is required for is establishing the connection (and saving state). This functional…

What sort of security is in place - e.g. what's stopping a pop-up ad from logging keystrokes and sending them to a remote endpoint?

I don't think this is an issue. The popup would only capture whatever keystrokes are typed into the popup (as dbaupp illustrated). DataChannels doesn't change the boundaries within which a webpage/Javascript runs

Re: Hello Firefox, this is Chrome calling

#107

Post by shmerl » Mon, Feb 04, 2013, 11:29 PM UTC

jallmann wrote: post #89

shmerl wrote: post #8

It's good to see this moving forward. A few questions need to be addressed in order for this to become really useful. How is XMPP/Jingle supposed to work over WebRTC? I.e. in order for the browser to connect to a standalone VoIP client for example (think of implementing Google Talk plugin in pure JavaScript). From what it looks like, this can require some support for this scenario in XMPP servers (not unlike they nee…

Interoperability with V/VoIP protocols will still require a translation layer somewhere. That can be on the browser, or on the server, but you will still need some server-side component to relay the signaling information through (eg, websocket proxy), or a browser-interoperability mechanism (for xmpp, BOSH). If the remote endpoint doesn't support WebRTC's flavor of SRTP, then you're going to have to relay media throu…

That's what I meant - most probably some server support will be required. I hope ejabberd and others will address this. Until that WebRTC won't be useful for building web based XMPP/Jingle clients.

Regarding codecs - most XMPP/Jingle clients support VP8 and Opus is catching up too. It's not like there are many of them around anyway. Farstream supports both if corresponding gstreamer components are present.

Re: Hello Firefox, this is Chrome calling

#108

Post by jbester » Mon, Feb 04, 2013, 11:33 PM UTC

josh2600 wrote: post #72

kyro wrote: post #66

Yes, please, please, please kill Skype. Kill it mercilessly. Using it has been the worst experience I've ever had with an application. I've been in a long distance relationship for a few years now and Skype has sadly been our main mode of video communication. The app crashes when I search chat history, can take upwards of 90+% of my CPU, literally forcing me to shut down every other application I have running. The fo…

The one key element of a Skype Killer, which isn't present in WebRTC, is a prescribed infrastructure to support these communications. Skype is made up of users who actually are, usually, unaware that they are also routing calls for other users. Even more precarious (and absent from WebRTC) are the skype SuperNodes, which no one is going to redo for WebRTC. The things which we love about skype, most notably the direct…

The user supernodes were mostly retired after microsoft bought Skype. See: http://arstechnica.com/business/2012/05/skype-replaces-p2p-s...

Re: Hello Firefox, this is Chrome calling

#109

Post by pjscott » Mon, Feb 04, 2013, 11:33 PM UTC

TazeTSchnitzel wrote: post #61

dbaupp wrote: post #12

I feel like DataChannels are the best part of the WebRTC standard (or would be, if they were usable): a true p2p connection allowing transfer of arbitrary data without plugins or anything. This gives multiplayer games, file transfers, realtime chat and collaborative editors (let your imagination run wild...) and the only thing a server is required for is establishing the connection (and saving state). This functional…

This is what really excites me. I want to build a P2P DHT in the browser, basically see if I can implement something like Freenet entirely in JS.

Re: Hello Firefox, this is Chrome calling

#110

Post by joshred » Mon, Feb 04, 2013, 11:37 PM UTC

Jabbles wrote: post #18

Note that Chrome (or the application) chooses to reverse the self-view so that it acts like a mirror, whereas Firefox (or its application) chooses to display what the other person sees . It's a hard choice to make.

Why would you make it a mirror image? If they have anything written out it would be backwards.