Implement realtime chat, possibly using XMPP

Features and Ideas
1

follow up
https://github.com/diaspora/diaspora/issues/4076

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.

Note: This discussion was imported from Loomio. Click here to view the original discussion.

2

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 :slight_smile:

3

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.

4

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.

5

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.

6

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.

7

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

8

@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.

9

@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.

10

@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?

11

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…

12

@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.

13

@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.

14

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).

15

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.

16

@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).

17

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

18

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.

19

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!!).

20

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.