Implement realtime chat, possibly using XMPP

@paulgreindl the problem is if features are developed before federation has been resolved (and stripped into its own code layer) and before an API has been finalised, those features might suddenly become broken when the code base changes at a later date. This has already happened with a chat feature and many other Diaspora features about a year ago, which put development back a long way when many developers became disillusioned at this happening. I think it's important to make sure this doesn't happen again, and so to focus on making the underlying code base stable enough so that features then added won't get broken when other parts of the code base change.

@Tom Scott:

"Just don't use Heroku"? There are a lot
of pods already on Heroku. This is an
unsustainable suggestion

It means don't use Heroku for XMPP server. If you need one - find another hosting to dedicate to IM part of your pod. If you can't - don't use XMPP server. Heroku should not limit Diaspora design - no one forces anyone to use it and Diaspora should not mandate any limitations based on Heroku preference.

that indicates that WebRTC does not require
a server. Perhaps it isn't necessarily a protocol for chat

Exactly, it's not a protocol for chat, nether it is a signaling protocol which is needed for sensible P2P media communications (most commonly used signalling protocols are SIP and Jingle). It's up to developers do decide what to route through WebRTC. See http://www.webrtc.org/faq#TOC-Why-should-I-use-WebRTC-
As I said, it makes sense not to reinvent the wheel, and to use existing protocols. Otherwise you'll end up with another walled service which won't be interoperable with anything outside itself.

Again, this discussion has nothing to do with Diaspora federation. It's about chat (IM/media) functionality. Federating the IM part should not be restricted to federating D*. I.e. if you use XMPP for IM part, it's automatically federated to the whole XMPP network. It doesn't relate to where D* itself is federated (as a social network).

Shmerl, if that's a response to what I said, my mentioning federation is because that is one of the biggest things to be solved, and until the federation code has been put into its own layer, any future changes to the federation code (of which there will by necessity by many, possibly almost totally changing the federation code) risk breaking features such as chat, which has already happened once before. Therefore it makes sense to either fix and make stable the fundamental stuff such as federation and the API, or to put them in their own layers so that future changes to them don't affect other things, before spending too much time creating 'window-dressing' features.

I think Diaspora would struggle to survive another catasrophe in which loads of features, carefully created by developers over much time, suddenly broke because of a necessary change in the fundamental network code. We'd do well to avoid this happening again.

@Goob: Sure, fixing D* federation should be a priority I think. But I was answering to @Tom Scott, who for some reason tried to tie together D* federation and the choice of XMPP for IM component. I was saying that these are separate subjects, and should not be put together in this thread (except as you said, putting D* federation as a first priority).

@goob This is absolutely valid for federation dependent features but not for a XMPP based chat...

My opinion is that an xmpp-chat for diaspora-federation is only a matter of a user-flag that says "this user has the following xmpp-chat-account". The rest (having a web-client for the chat, having a jabberd-server on the pod or an external server/account, or using WebRTC) is not affecting the diaspora-federation in any way. So using XMPP seems quite nice to me and should be able to be done even today, when federation is not put into it's own layer yet.

Okay so this debate is more or less a choice between XMPP and WebRTC. As a Mozilla contributor, I'll contact some WebRTC guys asking if they can come here because I think we do not have enough knowledge to take a decision.

Anyway, here are the arguments for the moment:

Maturity:
XMPP is far more mature and supported than WebRTC, no doubt. WebRTC works on only few browsers for the moment, and this is a problem. Moreover, specifications can change because the techno was not released in stable for the moment.

Interoperability
XMPP is used by a lot of network (Jabber, GTalk, Facebook...). Unfortunately, Facebook is completely closed and Google started to close gtalk too (you cannot add a gtalk contact from another xmpp account for few weeks now). Anyway, there are a lot a websites / services (jabber, movim, libertree, etc) which used XMPP, far more than WebRTC and there are desktop clients for XMPP too. So for the moment, XMPP wins. In the other hand, it's possible that WebRTC becomes the replacement of XMPP in the future...

Complexity
About development, we do not know enough WebRTC to compare to XMPP implementation.
About pod administration, has said, XMPP is more complex than WebRTC. It needs another server, more sysadmin stuff, more server bandwidth / power, special configuration (ports other than 80)... and is not completely decentralized as it needs to use a server.
Remember, in a perfect Diaspora world, everybody has his own pod under his bed, in a raspberry. I see the server part becomes more and more complex with the time, and I don't like that. WebRTC totally solves this problem by processing between browsers directly.

Features
Here is the killer point in favor of WebRTC. Chatting, audio, video, file sharing, conf call... (remember, this is "the" killer feature of g+, officially...). This is AWESOME.

Moreover, we are in a moment where companies are trying to put social in them. If we add such features, Diaspora can be interesting for them. And companies can put money / developers in the projects which interested them. This is a really important point, we can maybe find a business model here (and we need one!!).

A big huge +1 for XMPP chat support.

In addition to an actual chat UI, we only need to add a field in the user settings about the users XMPP handle. If the pod provides one, the user can opt to use that one. If the user does not like it or has an existing one, they will probably use that one.

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

We have a gazillion of things to do - let's not start building a platform for chatting as we can leverage on XMPP for that and just offer a simple client in the UI AND the possibility for podmins to run a server tied to their pod. If they want, Heroku podmins don't need to do if they don't want. Or they can run one on their VPS.

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.