dagingaa
Joined 14 years ago
Karma
249
Submissions
42
Member since
Mar 16
Recent submissions
Comment · 11 years ago
You might want to consider a different CDN in that case.
Comment · 11 years ago
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)
Check out: - https://appear.in/ - https://talky.io/ - https://screenhero.com/ - https://github.com/feross/webtorrent - https://peercdn.com/ - https://sharefest.me/ - ...and lots, lots more. Sorry to the ones I forgot to mention/don't know about.
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.
Comment · 11 years ago
Opera and the newly released Vivaldi also works, but they are based on chromium/blink engines so.
Comment · 12 years ago
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.
Comment · 12 years ago
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!
Comment · 12 years ago
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.
Comment · 12 years ago
We will investigate further. Thank you for reporting this! We definitely want graceful degradation for iOS clients.
Comment · 12 years ago
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.