Personally I don’t need an additional chat handle - allowing Diaspora* users to contact me easily via my existing XMPP handles would be cool though.
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
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:
- IM component should use XMPP protocol (for example using strophe.js preferably with WebSockets, instead of BOSH).
- 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/
The benefit of using XMPP and Jingle is that instead of JS client you can put any client (Pidgin, Jitsi etc.), and it would still work, since it will talk a standard protocol.
@shmerl If we are speaking of adding XMPP as an IM service only, then we may have a reasoning behind this. We can use XMPP for a lot more than just IM, if we were so inclined. I believe both Facebook and Twitter are/were using XMPP for realtime communication between their client side and server side code.
If we do this, I’d like to give the user the freedom to run XMPP or not. If they don’t want it, they can disable its use. If they do want it, it is their responsibility to provide a server and XMPP protocol support on the backend. Diaspora is essentially just providing a nice web-based client to use with an XMPP server.
For a first version, I feel like it’d be easier to just focus on text chat, and then move on to voice/video implementation later. Are there free software implementations of this on the client side I can take a look at? Also, what is everyone’s consensus on using a Flash component to handle video chat for regression into older browser clients?
@Tom Scott: Yes, we can use XMPP for Diaspora’s own protocol, but as I said, this is out of scope for this particular discussion.
Back to IM: XMPP surely can be optional. Podmin can simply not associate the pod with XMPP server (and not install that server). There is no need to make it mandatory.
Regarding clients - Text/IM libraries are already around. Example:
http://strophe.im/strophejs/
Audio/video conferencing and Jignle support through JavaScript is still catching up and you’ll have to do the research. But that can be put to phase 2, with text IM being the first phase.
Who is the person requested to implement this feature?
@christophe - chat has been one of the most wanted features since the beginning, requested by many people
Are there free software implementations of this on the client side I can take a look at?
Look at Jappix Mini 
what is everyone’s consensus on using a Flash component to handle video chat for regression into older browser clients?
I’ll block anything using Flash. This technology does not exist anymore 
@flaburgan uhh, i think you misunderstood my question. but it was a stupid question anyway, because i’m pretty sure we can get websockets to work all the way down to IE 6 without using flash.
@shmerl i do know about Strophe. should be a decent choice for communicating with the XMPP server. let’s focus on text chat right now. would Jappix Mini or the Facebook IM design work for our purposes?
and by “Jappix Mini” i mean the way it looks, not the product itself. we can’t really use Jappix as a product because we don’t control its code.
How would you link Diaspora accounts with XMPP accounts?
Do you intend to allow users to provide an existing XMPP account or should they register a new account (on the connected XMPP server) through Diaspora? (see XEP 0077)