pthatcherg

FYI,

Years ago I worked at a startup which made a distributed, p2p automatic file synchronization system. The startup didn't work out, but the system (mostly) worked. We spent a lot of time trying to solve things that are not largely solved, so if I were to start over today, a lot of the hard work would be done.

To be more specific, if I were you, I would start by using the p2p connectivity and data channel code built into WebRTC (at webrtc.org) or libjingle (at https://code.google.com/p/libjingle/). This is what AeroFS (at https://aerofs.com/) is doing.

By the way, writing a distributed file sync system is not that simple, even though it might seem simple at first. Things get complicated really fast. I think that ones reason one of these hasn't taken off is because it's really hard to get right. But, I still hope it will happen one day.

Oh, and there is http://camlistore.org/, which is an open source project run by a really smart Googler. It's not specific to file syncing, but it has a powerful foundation. A combination of the p2p bits from WebRTC and the distributed data bits from camlistore would be pretty powerful. It makes me wish I could find some more 20% time :).

(Full disclosure: I work at Google, often on the WebRTC code base, and am the maintainer of libjingle)

Why do you think WebRTC puts too much power in the hands of a few companies? It's completely open source and can do everything you want. You can take all the source code from either webrtc.org or chromium.org and use it to build your own end-to-end full encrypted communication system that no one can hack (as far as we know, and assuming you have secure device and OS).

The implementation at webrtc.org gives you cross-platform, cross-device source code in C++. You can build any API on top of that, in any language you want. It's already really easy to use if you an to use the HTML5 WebRTC API built into Chrome (and the same API in Firefox).

It seems to me that you have everything you want, or at least all the pieces of the puzzle. Someone just needs to do the work of assembling them the way you want them, and then of convincing the people with whom you want to talk (your friends, family, or business associates) to use your securely built communication system. Technology-wise it's possible, even fairly easy if you know what you want. But the social aspect (convincing others to use it) is more difficult.

(Full Disclosure: I work at Google, and I have worked both on Hangouts and WebRTC)

Actually, the respective Mozilla and Google WebRTC teams get along quite well. I work at Google on WebRTC, and from what I've observed the joint work as been close, and always positive.

I think Google+ Hangouts are pretty good :).

It's true that the audio, video, and data are all encrypted. But it's not the case that you can send audio and video over the data channel. Well, you could send audio and video data, but there's no way to pipe audio and video data into the data channel. That's an interesting idea, but it would probably take a long time to figure out and become part of the standard, if it ever happened at all. We'd probably need a worthwhile use case to justify it.

It's not quite that simple. We (I work with the Chrome team) have an RTP-based data channel (sort of what you call "tunnel through the video" already in Chrome), but it provides no congestion control or reliability. To provide those, the IETF has proposed as the standard to use SCTP. Firefox has already integrated SCTP into their implementation, and we're working to get it into Chrome. So, you can start using the API now, but it'll get much better soon.

Firefox has as full DataChannel implementation (SCTP-based), while Chrome has a partial one (RTP-based). They don't interoperate yet. I implemented most of the partial implementation and am working on the full implementation now.

I'm glad that you're excited about them. I am too. I hope to have it ready for you soon :).

Google+ Hangouts have screensharing as well.

That's funny. I implemented almost the exact same thing a few years ago, although mine is arguably more complete :)

https://github.com/pthatcher/pyrec

Here's my original post about it:

http://www.valuedlessons.com/2009/10/introducing-pyrec-cure-...

And here's my analysis of how much less memory it uses:

http://www.valuedlessons.com/2008/10/blog-post.html

Article didn't mention it, but Justin's blog post did:

"Standards-based: XMPP, Jingle, RTP"...

We're working on publishing the spec, which should be available soon. In fact, it's already implemented in libjingle:

http://code.google.com/p/libjingle

Don't Yahoo and DDG use Bing for their search results? If so, Bing is the only alternative on your list.

Yes, complimentary. You could use WebRTC to implement a Jingle client.

We care about gmail on all browsers :).

I don't know how Obihai works, but if it uses SIP to talk to Google Voice, this will not effect them.

My original email had more details:

We are pleased to announce that we have launched support for Jingle XEP-166 and XEP-167 for Google Talk calls to and from Gmail, iGoogle, and Orkut. We have also added the same level of support to libjingle (http://code.google.com/p/libjingle), which is used by many native clients. From this point on, it will be our primary signalling protocol, and the old protocol will only remain for backwards compatibility. We also plan to soon update Google Talk on Android to speak Jingle, but we do not plan on updating the Google Talk Windows application.

We suggest all clients that interop with Google Talk to switch to using Jingle rather than the old protocol. We will remain backwards compatible with legacy clients by continuing to speak the old protocol as well. If you wish to continue working with legacy clients, such as the Google Talk application for Windows, you may also wish to continue speaking the old protocol. But the future is Jingle, and the old protocol will eventually go away.

Finally, we are still working on implementing XEP-176 (ICE-UDP). In the meantime, you'll need to use our draft-06 version of ICE, which is implemented both in libjingle and in libnice, two open source libraries.

I hope that this will be a support to the Jingle community and futher our efforts to have open standards for voice and video communication.

In relation to #2 and #3, I think you underestimate how hard it is to get a p2p connection. It's very hard, and sometimes impossible, which is why a TURN server will often fallback to simply relaying data, in which case someone running the server has to pay for the bandwidth. Thus, you need to pay for a TURN server if you want to run a p2p service (or make users relay the data, like Skype does).

In relation to #4, you want the encryption to be done by the browser. Encryption is very hard to do right. You're crazy if you think you'll implement it correctly by yourself in JS.

The jingle portion of WebRTC comes form libjingle, and is usable right now with Google Talk. There is also a second open source implementation that works with Google Talk called "telepathy".

http://code.google.com/p/libjingle http://telepathy.freedesktop.org/wiki/

Gmail's voice and video chat now supports the main Jingle standards, XEP-166 and XEP-167.

And there are two open source implementations that it works with:

http://code.google.com/p/libjingle http://telepathy.freedesktop.org/wiki/

Actually, the standard deviated from the original implementation, as Google Talk pre-dated the standard. Either way, we're working on it.

Also, the mobile version uses the same protocol as all of the other products (such as gmail). You can take our Open Source library (http://code.google.com/p/libjingle) and use it to make an app that calls the mobile version, just like you can for the other products.

That is correct. We are working hard on it.

By the way, libjingle, the Open Source library for writing jingle applications, already mostly speaks XEP-166 and XEP-167. We're still working on XEP-176, though. http://code.google.com/p/libjingle

Google Talk on Android uses the same XMPP-based signaling as all the other Google Talk products (gmail, the win32 app, etc).

Google also uses ICE-UDP and STUN, although the implementation was done before ICE-UDP was standardized, so it doesn't quite follow the standard yet.

Also, Google speaks many audio codecs, including speex. ISAC (the codec from GIPS) is just the default.