Using Converse.js as an alternative XMPP chat client

[jcbrand]

Hi everyone

I'm the creator of converse.js an Javascript XMPP client, very similar to JSXC which is the xmpp client used in Diaspora.

Yesterday I received an email from someone asking me whether I could help integrate it into his Diaspora pod. I've also had similar requests in the past.

I wondered whether it would be possible to piggyback on the work that's already been done to integrate XMPP (Prosody) into Diaspora.

I took a look at the JSXC-related code in Diaspora and from what I can tell, it should be quite easy to do. Specifically I noticed the file app/assets/javascript/jsxc.js in which a JID and token is retrieved and then passed on to JSXC to log the user in to the XMPP server.

With Converse.js one can take the same approach, and the code would look very similar:

//= require jquery
//= require converse

// initialize converse xmpp client
$(document).ready(function() {
  if (app.currentUser.authenticated()) {
    $.post("/user/auth_token", null, function(data) {
      if (converse && data.token) {
        converse.initialize({
            bosh_service_url: $('script#jsxc').data('endpoint'),
            auto_login: true,
            jid: app.currentUser.get('diaspora_id'),
            password: data.token,
            keepalive: true
        });
      } else {
        console.error('No token found! Authenticated!?');
      }
    }, 'json');
  }
});

Besides the above code snippet, we would need to register the Converse.js Javascript and CSS files with the Rails resource manager (I have no clue as to the jargon here) and then ideally this should be installable by pod owners (as an alternative to using JSXC).

I however know very little Ruby and no Rails, so I'm hoping someone can help us out here.
Is there anyone with the necessary skills and experience who could do the above for us?

The person who emailed me indicated he'd be willing to pay, so this doesn't necessarily have to be volunteer work.

Thanks
JC

[jcbrand]

I forgot to mention, there is a Rails integration package which already registers the Converse.js resources. So even that part is already done.

https://github.com/mikemarsian/conversejs-rails

[goobertron]

Paging @zauberstuhl, who created the chat feature.

[zauberstuhl]

@jcbrand hey I would love to see this one as a PR

I am currently a little frustrated with jsxc and to be honest I am not the front-end guy.
So if there is an alternative or even a good replacement for jsxc I am all ears.

You can contact me directly via lukas@zauberstuhl.de. The swap from jsxc to converse shouldn't be hard as you already indicated.

Cheers,
Lukas

[Flaburgan]

HI @jcbrand and thanks for your suggestion! If you want to play with conversejs and diaspora* please do! It's always interesting to try different things. However if you want to see it included in the core code you will have to become the maintainer of it, == to fix bugs and update the lib when new version is released.

From a features point of view, I'm interested about the "group chat" thing, not sure JSXC support that and I'm wondering if it can be integrated with aspects. On the other side, conversejs doesn't integrate with WebRTC, I don't know if that's a feature we want to keep... Also, I find the current design less beautiful than JSXC but that's easily modifiable I guess. Oh and last point, we don't want the user to have to manually connect, nor be able to disconnect or change his XMPP server. I don't know how the conversejs code handles that.

So to sum up: if you want to maintain the front-end part of the chat of diaspora*, you're welcome, we need help there, and you can do that with conversejs. However if it's just a "please use my lib" we don't put any effort on the chat actually so we will not do it.

[jcbrand]

Thanks for the feedback guys.

@zauberstuhl, I'll contact you this week.

@Flaburgan I was hoping that diaspora would have some kind of plugin system so that converse.js could be added as an alternative and not necessarily as a replacement of JSXC. That way pod owners would have a choice what to use. If there were some pods using JSXC and some using converse.js they would still be interoperable because it's all XMPP based.

Some points:

• "group chat and aspects" can you give me more info on how aspects work? There might be a way to map groupchat rooms to them.
• WebRTC: support for that won't be coming to converse.js any time soon, at least not from me. So you and the diaspora folks will have to decide whether this is a blocker.
• Design: that can be changed, it's just CSS and HTML.
• "Manual connection": That won't be necessary.

Concerning maintenance, yes I'll be willing to maintain the front-end part of diaspora's chat.

[denschub]

Oh and last point, we don't want the user to have to manually connect, nor be able to disconnect or change his XMPP server. I don't know how the conversejs code handle that.

The initial example includes auto login.

We have no idea yet on how to make group chats happen. That's not an issue for the chat library, that's just a question on how we map aspects to MUCs.

Thanks for the hint and thanks for your willingness to maintain it, @jcbrand. Also, thanks for working on strophe. :)

[Flaburgan]

I was hoping that diaspora would have some kind of plugin system so that converse.js could be added as an alternative and not necessarily as a replacement of JSXC.

Hm, we don't have a plugin system but I guess a setting could do the trick. Anyway, JSXC is not stable yet and I'd like a default which works well, there is a room for Converse.js here.

If you want to play around and open a PR I will happily have a look.

[tursiops33]

Hello everyone I see this hasn't moved in a while, would it be possible to open a bounty for this request? I would be willing to fund it.

[svbergerem]

@tursiops33 https://www.bountysource.com/issues/42164049-using-converse-js-as-an-alternative-xmpp-chat-client

[tursiops33]

In case the two main people don't see my email, I put it here too, I've added a 250$ to the bounty so that we can keep this moving and implemented in the end.

[cmrd-senya]

Looks like this issue and the corresponding PR has stuck.

@jhass wrote at #7432

Why should we maintain both integrations if we think that one is better for whatever reasons.

We haven't decide if one is better for whatever reason. Since this discussion was initiated there and initiators are there, I guess it is better to keep it there and not at the PR page. Should we label this issue as "undecided" also?

When I look at the feature lists of JSXC and ConverseJS and compare I feel that JSXC mostly beats ConverseJS in that respect: more major features are available at JSXC and I can't see anything major which is available at ConverseJS and unavailable at JSXC. Also @Flaburgan wrote that JSXC has more beatiful design (do you mean UI or source code design?). What ConverseJS feature list mentions is "Plugin Architecture" which can be useful for us and this is something that not on the list of JSXC. However it doesn't mean it's not extensible.

On the other hand, there are people who strongly dislike JSXC, like @zauberstuhl and @tursiops33. @zauberstuhl says that he is frustrated with JSXC. @tursiops33 even sponsors this issue and has ConverseJS PR merged at his pod. I also feel that ConverseJS has better looking UI and in terms of UI as a user I would prefer ConverseJS.

So looks like there is no strong winner between JSXC and ConverseJS and therefore we can't confidently prefer one over another. I think that it's okay to support both integrations at our present state.

XMPP is meant to be client-independent, so it is kinda a feature of XMPP that people may select among different alternatives, so that is something people would appreciate in XMPP integration.

What is bad about having two integrations at the same time is that if someone will try to improve the integration it is possible that they will have to double some parts of the job. Our integration is not in too good state and we want enhancements. But nobody works on that at the moment. If there is someone who will want to work on chat improvements then we'll decide which XMPP frontend is better to work on (e.g. easier to integrate with diaspora, easier to extend) and to drop another one. While there are both groups of people who prefer ConverseJS or JSXC we can at least make everyone happy before someone starts to work on improvements (and that can be a long time). Also this way the future possible contributor to the chat integration development could pick the integration which is easier to enhance.

Maybe eventually it won't be a problem at all to support both integrations or maybe we'll notice some strong advantages of one XMPP client or some strong disadvantages of another one after we merge the support and compare them as a community at whole.

[Flaburgan]

Also @Flaburgan wrote that JSXC has more beatiful design (do you mean UI or source code design?)

I meant the UI, but maybe that changed since I tested it.

I think that it's okay to support both integrations at our present state.

We don't even have one working implementation. Looking at our few resources, supporting two seems not a good idea.

In my opinion, the chat is currently in an unusable state. The installation guide is a mess (I didn't even succeed to re-enable it in a clean d-fr install), the UI and UX have a lot of problems (chat not being present on every page meaning you switch between online and offline each time you leave and come back to the stream, so several time per minutes for example).

As I see it, someone should stand up and take some time to clean the chat functionality. If that means switching from JSXC to ConverseJS then why not, I don't care that much. It is not the important point about the chat feature in my opinion. It still has to be easily integrable inside diaspora* and well maintained of course.

[cmrd-senya]

We don't even have one working implementation. Looking at our few resources, supporting two seems not a good idea.

That's my point: we don't have to support both implementations. We don't have one working implementation, but it was merged to diaspora, so there is no reason for not merging another "half-working" one. Nobody works on this anyway, so merging #7432 won't add us any extra support work. If somebody decides to work on chat improvements then we can easily drop another integration, that's not an issue and doesn't need much real job.

As I see it, someone should stand up and take some time to clean the chat functionality.

We don't know when this gonna happen, maybe never. But there are people (at least two in this topic) who want functionality which already has a PR, so why not just merging it with almost no additional efforts? If someone stands up then they will decide which one to persist or to have them both.

Maybe we'll see that podmins are massively switching to ConverseJS and that would mean that the community likes it more.

[SuperTux88]

so there is no reason for not merging another "half-working" one.

No, we don't want to add another half-working solution (two half working solutions don't make a working one ;) ). When nobody wants to work on the chat we should probably remove it completely again, because the current half-working solution does create support requests via IRC, and there is often nobody there to help. So it's better to have no chat at all than a chat that doesn't work and nobody wants to work on. The current chat solution also blocks dependency that can't be upgraded because jscx isn't maintained anymore. So it also blocks maintenance work. I really don't see why we should add even more code that nobody wants to work on.

We don't have one working implementation, but it was merged to diaspora

It was merged because back then somebody (@zauberstuhl) was working on it and also wanted to finish it, but this never happened, and it looks like he don't want to finish it anymore ... and now we have something in diaspora which is unmaintained and broken, so I don't see why we should keep it.

We don't know when this gonna happen, maybe never.

When somebody wants to work on the chat again, we can easily add it back, and the person working on it can decide which solution is the best for whatever reasons.

But because of that history with the chat I would only merge a finished solution, because I don't want another half finished chat in it that then again nobody wants to continue.

Maybe we'll see that podmins are massively switching to ConverseJS and that would mean that the community likes it more.

No because it's not about how the community likes it, it's about what the podmins like more. Users can't choose what they want to use.

But there are people (at least two in this topic) who want functionality which already has a PR

When only two people want this, they can maintain it themselves, because there is nobody who currently wants to finish and maintain the chat in the main repo. When you think it isn't doesn't need a lot of work to maintain this PR after merging it, then it shouldn't be a problem for these two people to do it.

In my opinion, the chat is currently in an unusable state. The installation guide is a mess (I didn't even succeed to re-enable it in a clean d-fr install), the UI and UX have a lot of problems ...

Yes, as @Flaburgan already wrote, the chat is currently in a really bad state, and somebody should either fix/finish it or we should remove it. Keeping the current state doesn't make much sense and only generates a lot of support requests in IRC from people who wants to try it (and it doesn't work) and they think it's an official supported feature (which it isn't, because there is nobody who wants to support it).

[cmrd-senya]

Okay, there is no one who is willing to work on chat and that would be more logical to remove JSXC as well then. What is the removal procedure then? Should we make contributors call first and/or make some announcement?

[cmrd-senya]

Maybe we can extract chat integration as a third party plugin?

[SuperTux88]

You can try to ask if somebody wants to work on the chat and finish it, and when the person thinks ConverseJS is better than JSXC it can be replaced. But yes, with the current state it doesn't make much sense to keep JSXC.

[SuperTux88]

Maybe we can extract chat integration as a third party plugin?

Diaspora doesn't support plugins, and while you probably could hack something and write a tutorial for podmins how to add a third-party chat, but when they already fail to setup the current built-in chat, I don't think a third-party-chat is easier to setup ;)

[Flaburgan]

It would be a shame to see the chat completely remove. Maybe we can try to find someone to work on it.

[cmrd-senya]

Actually, what I think, is that if we want to support both XMPP and diaspora protocol for private messaging, we should at least support them inside the same web UI. Otherwise, having two different PM approaches in the same application feels weird.

Should we target to creating a common web UI for private conversations with two protocols at the same time?

[CitizenPrayer]

This project appears to have been stuck for some time. I'd like to ping out a reminder that there is an active $250 bounty on this project. I can confidently add that I can and have successfully been able to implement XMPP chat on my pod as of yesterday with the current guide that is up on the newest version of Diaspora.

[SuperTux88]

The chat was removed with #8069, this is obsolete now.