Working for a major player in the WebRTC space certainly gives me a bias, but "noone cares" is pretty far from the truth. There are millions of WebRTC users already, hell, we might even be approaching the billion now if you count Snapchat and Hangouts as WebRTC services. (Yes, Snapchat uses WebRTC for their video chat features)
For some pure WebRTC experiences. http://simplewebrtc.com/ if you want to build something yourself.
The thing is, you don't know that the service you're using uses WebRTC, quite frankly because the technology doesn't matter, the user experience does. Also, the sheer fact that we seem to have standardised a very good (and very secure) way of doing peer to peer transfers, and that's getting implemented in browsers, with client libraries for iOS and Android is HUGE.
No, not exactly. WebRTC has no concept of interoperability between services, only between clients. You need a signalling server to communicate the initial call between clients, and if you wish to connect clients across services, then those two services would need to connect to each other in some way, which is not detailed in the spec.
There are efforts to use SIP and XMPP for this, but that only solves the WebRTC-part. If you want SIP-clients to interconnect, you need expensive hardware/software to transcode the streams, and you loose the P2P-part. WebRTC is not a golden cow of interoperability between services.
Developer @ appear.in here. I've been following this thread today, answering some questions and reporting bugs back to the team. I would just like to say a big and sincere thank you for this comment. I just posted it to our internal mailing list. In all honesty, feedback like yours truly make our day, motivates us, and makes us work even harder to create a kickass service. So again, thank you!
At this point in time, all chat messages are relayed through our server. These messages are sent over an encrypted socket to our server, then relayed. This means that we do have the ability to read the messages (they're not encrypted), but we do not store them, read them, or in any way allow your privacy to be compromised knowingly.
We have strict access controls to the server, but the messages are sent via Amazon. We realise that this is not ideal, and we want to, when the DataChannels API has matured a bit, move message sending to a strict P2P model as well. There are some issues with that (total ordering of messages for one) which need to be solved first, but we're positive that those challenges can be solved.
I just talked to the FxOS guys, and they hope the support will be out around 1.4 or 1.5, but no promises. I don't know much more than that unfortunately.
Which browser and OS are you on? Depending on that, it should be somewhere near the top. Firefox has a tendency to close the accept dialogue if you change tabs, and you can retrieve it by clicking the camera icon in the address bar. Unfortunately there is no way for us to improve this UX from our end, but we are working on more informative "waiting" pages.
We have some guys working on FirefoxOS at our office actually (Telenor Digital does many things). We tested appear.in on a recent build of master, and it worked! Hopefully it will make it out to consumers soon. You can track support through this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=750011
Developer @ appear.in here. For lack of better ways of communicating, at which page did you experience this? We tested it on our own devices but couldn't replicate.
Developer on appear.in here: Everything between peers is encrypted using SRTP end-to-end by default. From our FAQ:
"All communication between your browser and appear.in is transmitted over an encrypted connection (SSL). Video and audio transmitted in the service is sent directly between the participants in a room and is encrypted (SRTP) with client generated encryption keys. In some cases, due to NAT/firewall restrictions, the encrypted data content will be relayed through our server."
Appear.in itself is all WebRTC, built with AngularJS and Node. As far as I understand it, the red cross solution is built with MeteorJS, and they have built a custom queueing system into that application. The Red Cross page has nothing to do with WebRTC, but the video solution (appear.in) is.
It all comes down to the model being fairly obvious for WebRTC based video chat systems I guess. Copy, paste and appear without login and registration is the core strength of WebRTC, and there are a lot of services similar to this. I think the service that wins going forward is going to be the one that can differentiate, not in the core user model in itself, but create real user retention for the product, without breaking that core model. Monetization is also a huge issue which needs to be solved.
In many cases the people in these positions don't even need to be able to program, they need to be able to see the solutions that programming can give them. I think this is the number one issue right now. Not everybody needs to be a programmer, but everyone needs to be educated about some of the ways programming can help you.
With that said, we mostly come up with these ideas because we are able to program, so yeah.
I can confirm this. We built the little bits ourselves without using something like http://jekyllbootstrap.com/. I kind of regret that now as JekyllBootstrap is more mature.
All in all we are very happy with Jekyll (and looking forward to development picking up on it now).