Smuxi

I've been thinking a lot lately about WebRTC.

It's a good thing because it's P2P-based, it let's us go one step farther in avoiding dependance over servers.

However, WebRTC normally still requires three elements to work properly, 100% of the time:
a) A STUN server.
b) A signaling server, also called TURN.
c) A browser.

More info: http://blog.vline.com/post/63765098884/webrtc-if-its-p2p-why-do-i-need-a-server

Nowadays, (a) is not really a problem. There are already lots of free STUN servers out there. It's a service that is easy to provide because it's cheap, as it's just a reply to a message, no more bandwidth involved.

The problems are (b) and (c).

(b) is basically a server which acts as a proxy. The bad thing about depending on this is not middle-man surveillance or anything (as that can easily be solved by using encryption), but about the fact that server-bandwidth costs money. However, there's a possible solution to this problem: http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ (serverless WebRTC: https://github.com/cjb/serverless-webrtc )

The catch about Chris Ball's solution above is twofold:
1) You still need a browser.
2) You still need to have some pre-communication between the parties (he says this can be done "via IM").

IMHO, it's kind of bullshit that to take advantage of the awesomeness of WebRTC, you need a browser. WebRTC is mainly about bi-directional communication! Its main target should be actually be IM apps! The only "web" related bit about WebRTC should be the fact that it should always be transported via HTTP, to avoid arrogant firewall policies. But nothing impedes us from implementing WebRTC in smuxi, which would make (c) and (1) issues go away.

Then, (2) problem explained above becomes a chicken&egg problem because smuxi is an IM app ;)

However, I think the pre-communication that should be done here is simply e-mail.

Let's assume both parties have smuxi installed in their computers. X wants to send a file to Y, or start a chat. Then X starts smuxi and clicks a button that says "Invite to chat/filetransfer via email". When clicking that button, a dialog pops up that lets you insert an email address, and ComboBox where you can choose two options:
- [Relay directly via STMP] (and you would need to provide SMTP details)
- [Generate a mailto: link that your email client can understand]

The result could be an email with a smuxi-webrtc:// link, for example.

Then, when Y receives and opens the email, she would click it, and smuxi would understand what to do, in the same way that ChrisBall's demo works.

If this strategy is implemented, and smuxi's approach begins to be "liked" a lot, one could even turn this into an RFC, where smuxi-webrtc:// would become something more official.

And then, we would have a browserless-and-even-more-serverless WebRTC.