Implement realtime chat, possibly using XMPP

I would probably use my Facebook XMPP handle since that is where I do most of my chatting with my friends.

But by doing that, you will not be able to talk to me who have a Jabber account, aren't you?

Btw, integrate in Diaspora an existing account could be a good idea, but how do you add contacts? When you start sharing with someone, it automatically send a request to his xmpp account? And how the other user answer? The asymmetric relationship of Diaspora is really different of the symmetric relationship in xmpp..

OK maybe Facebook XMPP based chat engine was a bad example. But anyway, something existent which is widely used, like @shmerl has been saying

@Flaburgan:

Okay so this debate is more or less a choice between
XMPP and WebRTC.

I think you are missing a point. XMPP and WebRTC are incomparable - they are different level frameworks. XMPP is a complete IM protocol, with signalling extensions like Jingle, which use P2P RTC for media chat (video/audio).

WebRTC is not a protocol, it's a low level JavaScript API which allows using RTC from the browser. I.e. it doesn't dictate any protocol whatsoever.

Therefore it's not a question of XMPP vs WebRTC. It's a question of what protocol do you want to use for chat? And if you use WebRTC for conferencing part of that chat (which makes sense for browser based client), what protocol do you want to implement through it? Remember again,WebRTC is not a protocol. See it as a tool, through which you implement your media protocol in JavaScript.

The way I see it - full blown and feature rich chat should look like this:

1. IM component should use XMPP protocol (for example using strophe.js preferably with WebSockets, instead of BOSH).
2. Conferencing component (video/audio chat) should use XMPP/Jingle signalling protocol, utilizing WebRTC framework to route it from the browser.

I hope this clarifies things a bit.

Anyway, my advice to anyone who proposes to use WebRTC in any way - read first about what it is, and what it isn't.

@Jason Robinson:

I would probably use my Facebook XMPP
handle since that is where I do most of my chatting
with my friends.

I agree that users should be able to set their XMPP handle, which can be from another server, not necessarily from the server shipped with the pod. However it has to be a federated server naturally. Facebook XMPP server is not federated, so we can forget about it right away. The fact that it's XMPP becomes irrelevant, since it's cut off from the XMPP network.

Google Talk is federated. Their invite blocking problems were temporary and they already resolved that issue.

I'm running a XMPP server and a Diaspora pod side by side at wk3.org, so the users already have matching handles.

Since nobody came up with SIP yet, I'd like to suggest that. There's already a HTML5 client: sipML5 And we totally need to consider CU-RTC-WEB too.

SIP is fine for media, except that it doesn't integrate with XMPP, instead it integrates with its own IM protocol - SIMPLE. However Jingle is a natural extension of XMPP, and if you are already using XMPP for IM/chat, it makes sense to use Jingle rather than SIP.

Like Shmerl said, WebRTC is just a channel that can be used for any kind of content. Yet it will be easiest to implement video-chat and phone-calls since it has the best developed libraries.
My question would be (and I'm not sure what the answer is): is it possible to fully mimic an XMPP with webRTC? There are some asynchronous components in XMPP that would need to be done by the Diaspora-server like "does the user exists", "give me metadata of the user" and "send a friendship request", probably more. I am quite sure that this can't be done entirely just by using WebRTC.

But it would be definitely a good architecture, if the user can opt if he/she wants to use a) an existing XMPP-account, b) a provided XMPP-account by the pod (like Christophe's solution) c) a WebRTC-client for XMPP or d) no XMPP account at all.

If we want to focus not only on chatting, but also on video-calls and this stuff, we should consider this probably now, because this can be hardly be done by XMPP only. I have no idea what would be the way for that.

I see this discussion finally moving in a good direction :)

@Rasmus Fuhse: For text messages you don't need WebRTC. It's a clear overkill. JavaScript offers you WebSockets already. WebRTC is targeted for media streams (i.e. audio/video), that's why it's dealing with codecs and the like. WebSocktes is a generic API for duplex communication through JavaScript. It fits perfectly for text part of XMPP. Some support for that is required on the backed (before WebSockets, the only method from the browser was BOSH). Now servers like ejabberd are catching up with WebSockets support. For media, WebRTC is an obvious API, but as I said - the protocol still needs to be defined, and it makes sense to use Jingle there:

#1. Text XMPP can work like this:
JS client (browser 1) <-> XMPP over WebSockets <-> XMPP Server <-> XMPP over WebSockets <-> JS client (browser 2)
#2. Media XMPP (Jingle) can work like this:
JS client (browser 1) <-> Jingle over WebRTC <-> JS client (browser 2).

Except that in #2 you still need some support of such routing from the servers, since there are security limitations. See some discussion in the comments here:

https://hacks.mozilla.org/2012/09/full-webrtc-support-is-soon-coming-to-a-web-browser-near-you/