Tue 30 Apr 2013 11:42AM

Implement realtime chat, possibly using XMPP

D diasp_eu Public Seen by 331

follow up

I've searched all issues for "chat" and all which suggest implementing chat are closed.
There seems to be no explanation of why they are closed, so I am opening a new one.

This issue shall be about basic chat functionality:

seeing who is online
chat between two users
For multiuser chat, a separate issue is suitable.

I think it is critical for the success of Diaspora to have chat, so I am requesting that you add this to a milestone.Thank you.


Flaburgan Tue 30 Apr 2013 11:51AM

I think WebRTC is THE solution because really powerful (look at this demonstration).

As @dennisschubert said, the technology is not mature yet, but will be available for every Firefox and Chrome users this summer. I think that 80% of our users use one of these two browsers, as we do not currently support IE and Safari+Opera have small % of users on desktop, for me, a release with WebRTC during the summer is something acceptable. But we are here for debate :)


goob Tue 30 Apr 2013 1:09PM

I think that chat is one of the features which has been put on hold until the Diaspora API has been finalised and made stable, but one of our more technical members will be able to confirm whether or not that is the case.

But it may well be a good idea to discuss now what will be the best way to implement chat, and which protocol(s) will be most appropriate, now so that those decisions have already been made once it's time to start coding the chat facility.


Shmerl Tue 30 Apr 2013 2:36PM

WebRTC is an JavaScript API. It doesn't mandate any protocol which you can implement through it. For chat there is no need to build server functionality into Diaspora itself - it would be crude engineering and would be too restrictive. It's better to take ready and robust solutions (for example ejabberd), and to run the XMPP server alongside Diaspora pod (let's say on the same host). Diaspora just needs a UI to communicate through it. And if user wants to use standalone client - it will work as well, since XMPP is a standard protocol.

For media, just use XMPP/Jingle as usual. If you want to work on Jingle over WebRTC - be my guest, but I don't think there are any ready solutions, and this will require a lot of work potentially. Also WebRTC will require support from XMPP servers, since you can't simply route Jingle over WebRTC relying on clients alone.


mathis Tue 30 Apr 2013 7:05PM

ther was an old work of a diaspora video-chat made by vittorio cuculo: https://github.com/vcuculo/diaspora/wiki/Setup-chat-and-videochat i can contact him if he want to contibute again , it's an italian user.


Ruxton Wed 1 May 2013 2:26AM

while i'd love to see this i think it's something that should be focused on at a later date when other things like federation are all sorted. The back end to things like federation are likely to provide a better interface for something like this.


Paul Greindl Wed 1 May 2013 7:02PM

@ruxton Yes of course, we can always delay everything to a later point of time, but then we'll never come anywhere...?


Tom Scott Wed 1 May 2013 7:53PM

@shmerl first of all, you're wrong about your assumptions on WebRTC. it is in fact a peer-to-peer chat API, which is why it's so interesting to this project because it's decentralized, e.g., your chat messages never touch the actual web app server. in fact, the diaspora app is just to facilitate logging in and using the WebRTC service, if that's how you're instant messaging.

I like the idea of XMPP. I feel like it may be a neat experiment to see what other kind of data we can federate. The problem with XMPP is that it requires another server to be set up and maintained. It requires people who are already having trouble getting a Rails app installed to have to install/configure ejabberd or an equivalent server. Additionally, podmins hosting on Heroku are out of luck, because you can't run processes on any port other than :80, which is the one we need for the web app. So Heroku users would have to pay for another VPS just to house their XMPP server, or find space on an existing VPS for such a task. While I agree with you here that XMPP might be a more feature-rich and "trusted" solution to our problem, there's no question that using XMPP would increase the complexity and reduce understandability for many new developers. Which is why we've been so nervous about implementing it. The last thing Diaspora needs is its podmins feeling alienated.

I personally think that if our goal is chat, we should focus on some sort of decentralized solution, which is looking every day more like WebRTC. If our focus is on changing the way we federate data and getting chat "for free" along with it, then XMPP seems to be the way to go.

I would also wager that since we aren't responsible for any IM traffic over the Diaspora server(s), that WebRTC is "cheaper" solution than XMPP, simply because we don't need a central server to facilitate communication between two people.


Shmerl Wed 1 May 2013 8:12PM

@Tom Scott: No, I'm not wrong about WebRTC. It's not a chat API. It's a JavaScript framework for RTC media streams. See https://en.wikipedia.org/wiki/WebRTC
It doesn't dictate the signalling protocol (which can be Jingle or SIP for example). If you use XMPP, Jingle is the natural path for signaling protocol (which should be routed through WebRTC if you want a JavaScript browser solution).

Using XMPP should be a solid must, otherwise you'll be proliferating non interoperable IM networks. No thanks - there are tons of these out there which can't talk to each other. We don't need another one, just to put it into Diaspora. Better even, if someone is so desperate to have an IM, then take a normal standalone client, connect to any of many existing XMPP servers - and that's it. No reinventing the wheel needed.

I understand the issues of running an extra server. But it only makes sense to do so, since it clearly separates Diaspora from IM service. Yes, Heroku is not an option. But Heroku limitations and idiosyncrasies should not dictate Diaspora design and limit your choices. Just don't use Heroku of you need an accompanying IM service.


Tom Scott Wed 1 May 2013 8:58PM

@shmerl "Just don't use Heroku"? There are a lot of pods already on Heroku (disclaimer: mine included). This is an unsustainable suggestion, and it's kind of a big "fuck you" to all of the podmins who are hosting free/personal pods on Heroku. I'm not going to put others through that just because I want to use Diaspora as my IM provider.

"WebRTC (Web Real-Time Communication) is an API definition being drafted by the World Wide Web Consortium (W3C) to enable browser to browser applications for voice calling, video chat and P2P file sharing without plugins."

To me, that indicates that WebRTC does not require a server. Perhaps it isn't necessarily a protocol for chat, but I'm pretty sure that WebRTC is a peer-to-peer technology which means its data is not routed through a central server. This is a big win for us, because we are always looking for better solutions to the centralization problem. It ensures that the only 2 people who see the data are the 2 people having the conversation.

I like that a lot for personal chat communications, as long as this discussion is focused on that particular problem. What I don't think we have in this discussion is a grip on what the problem is that we're trying to solve. Are we just trying to give our users a basic chat service? Or do we want to use the XMPP protocol for something a bit beyond chat services, like perhaps as a means to re-invent the Federation Protocol?


Tom Scott Wed 1 May 2013 8:59PM

Another disclaimer: I can easily run an ejabberd on the VPS that I already own, so that particular problem isn't something I have to solve for my own use case, but I can see how it would be an issue for others...

Load More