Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add conversejs and replace jsxc chat front end #7432

Open
wants to merge 1 commit into
base: develop
from

Conversation

9 participants
@Zauberstuhl
Copy link
Contributor

Zauberstuhl commented Apr 28, 2017

related to #7336

$(document).ready(function() {
if (app.currentUser.authenticated()) {
$.post("/user/auth_token", null, function(data) {
if (converse && data.token) {

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

'converse' is not defined.

This comment has been minimized.

@Zauberstuhl

Zauberstuhl Apr 28, 2017

Author Contributor

I guess I can ignore that. If someone points me to the right exception file for pronto I will add it.

if (app.currentUser.authenticated()) {
$.post("/user/auth_token", null, function(data) {
if (converse && data.token) {
converse.initialize({

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

'converse' is not defined.

$.post("/user/auth_token", null, function(data) {
if (converse && data.token) {
converse.initialize({
bosh_service_url: $('script#converse').data('endpoint'),

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Expected indentation of 10 space characters but found 12.
  • Identifier 'bosh_service_url' is not in camel case.
  • Strings must use doublequote.
if (converse && data.token) {
converse.initialize({
bosh_service_url: $('script#converse').data('endpoint'),
auto_login: true,

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Identifier 'auto_login' is not in camel case.
  • Expected indentation of 10 space characters but found 12.
converse.initialize({
bosh_service_url: $('script#converse').data('endpoint'),
auto_login: true,
jid: app.currentUser.get('diaspora_id'),

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Expected indentation of 10 space characters but found 12.
  • Strings must use doublequote.
bosh_service_url: $('script#converse').data('endpoint'),
auto_login: true,
jid: app.currentUser.get('diaspora_id'),
password: data.token,

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

Expected indentation of 10 space characters but found 12.

auto_login: true,
jid: app.currentUser.get('diaspora_id'),
password: data.token,
debug: true,

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

Expected indentation of 10 space characters but found 12.

jid: app.currentUser.get('diaspora_id'),
password: data.token,
debug: true,
allow_registration: false,

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Expected indentation of 10 space characters but found 12.
  • Identifier 'allow_registration' is not in camel case.
password: data.token,
debug: true,
allow_registration: false,
auto_reconnect: true,

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Identifier 'auto_reconnect' is not in camel case.
  • Expected indentation of 10 space characters but found 12.
debug: true,
allow_registration: false,
auto_reconnect: true,
keepalive: true

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

Expected indentation of 10 space characters but found 12.

keepalive: true
});
} else {
console.error('No token found! Authenticated!?');

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Unexpected console statement.
  • Strings must use doublequote.
} else {
console.error('No token found! Authenticated!?');
}
}, 'json');

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

Strings must use doublequote.

= javascript_include_tag :jsxc, id: 'jsxc',
data: { endpoint: get_bosh_endpoint }
- if AppConfig.chat.frontend.eql? "converse"
= javascript_include_tag :converse, id: 'converse',

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
  • Space inside { detected.
  • Space inside } detected.
= javascript_include_tag :converse, id: 'converse',
data: { endpoint: get_bosh_endpoint }
- else
= javascript_include_tag :jsxc, id: 'jsxc',

This comment has been minimized.

@diaspora-code-review

diaspora-code-review Apr 28, 2017

  • Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
  • Space inside { detected.
  • Space inside } detected.
@Zauberstuhl

This comment has been minimized.

Copy link
Contributor Author

Zauberstuhl commented Apr 28, 2017

ah sorry .. forgot to run the stylethingy

@Flaburgan

This comment has been minimized.

Copy link
Member

Flaburgan commented Apr 28, 2017

What's the problem with JSXC?

@Zauberstuhl

This comment has been minimized.

Copy link
Contributor Author

Zauberstuhl commented Apr 28, 2017

@Flaburgan non, it is not a replacement. On default you still have the jsxc front-end

@SuperTux88 SuperTux88 added this to Needs review in Pull Requests May 1, 2017

@SuperTux88

This comment has been minimized.

Copy link
Member

SuperTux88 commented May 1, 2017

So what are the advantages of the one or the other? Shouldn't that be selectable by the user, not the podmin (because they are still both installed and precompiled, even when the chat is disabled. Then we can also give the user the choice if they are there anyway)?

@jhass

This comment has been minimized.

Copy link
Member

jhass commented May 1, 2017

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

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Jun 28, 2017

So we need to enlist the exact pros and cons of the new and old chat integration and then we can decide if we prefer one or another or both available. I think that I'll plan to review both of them and post my findings.

@Flaburgan Flaburgan added the chat label Jul 7, 2017

@SuperTux88 SuperTux88 moved this from Needs review to Needs discussion in Pull Requests Jul 21, 2017

@tursiops33

This comment has been minimized.

Copy link

tursiops33 commented Sep 10, 2017

Hi everyone I just wanted to say that this chat has now been merged with my pod at diasporing.ch
Would anyone help resolve the conflict that prevents this from being merged?
One main advantage I found was that when the site was on a tablet like an ipad, the current chat would hide on the right and often when I wanted to post something I would click on the chat tab instead of the post button. Which was pretty annoying.
This no longer is the case with the new chat system.

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Sep 10, 2017

For the record, here is this PR's branch rebased on top of current master: https://github.com/cmrd-senya/diaspora/tree/conversejs-0.7.0.0

@tursiops33

This comment has been minimized.

Copy link

tursiops33 commented Sep 11, 2017

In order to do a feature comparison, here is the advertised features of converse.js

Available as overlayed chat boxes or as a fullscreen application. See inverse.chat for the fullscreen version.
Plugin Architecture based on pluggable.js
Presence information (online, busy, away)
Single-user chat
Contacts and groups
Multi-user chatrooms (XEP 45)
Chatroom bookmarks (XEP 48)
Direct invitations to chat rooms (XEP 249)
vCard support (XEP 54)
Service discovery (XEP 30)
In-band registration (XEP 77)
Roster item exchange (XEP 144)
Custom status messages
Typing and chat state notifications (XEP 85)
Desktop notifications
Messages appear in all connected chat clients (XEP 280)
Third person "/me" messages (XEP 245)
XMPP Ping (XEP 199)
Server-side archiving of messages (XEP 313)
Client state indication (XEP 352)
Off-the-record encryption
Supports anonymous logins, see the anonymous login demo.
Translated into 16 languages

@jcbrand

This comment has been minimized.

Copy link

jcbrand commented Sep 26, 2017

BTW, FWIW since this pull request has been made lots more work has been done on Converse.js and it's now at version 3.2.1 (the version in the pull request is 3.0.2).

The changelog is here: https://github.com/jcbrand/converse.js/releases

Main additions are emojis via emojione, support for MAM2 (message archive management), lots of bugfixes and also a full-screen version which you can try out here: https://inverse.chat

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Sep 26, 2017

@jcbrand I bumped the version to 3.2.1 at my branch for this PR, which I also rebased on top of the current release.

https://github.com/cmrd-senya/diaspora/commits/conversejs-0.7.0.0

And it is also the version which is running at https://diasporing.ch

@Zauberstuhl Zauberstuhl force-pushed the Zauberstuhl:conversejs branch from 5b8fb53 to 58c94b4 Sep 27, 2017

Add conversejs as alternative to jsxc chat front end
Signed-off-by: Lukas Matt <lukas@zauberstuhl.de>

@Zauberstuhl Zauberstuhl force-pushed the Zauberstuhl:conversejs branch from 58c94b4 to a2d2af6 Sep 27, 2017

@Zauberstuhl Zauberstuhl changed the title Add conversejs as alternative to jsxc chat front end Add conversejs and replace jsxc chat front end Sep 27, 2017

@tursiops33

This comment has been minimized.

Copy link

tursiops33 commented Dec 8, 2017

I would like to add that jcbrand decided to take 3 months off his work to dedicate himself to his chat client this might convince you that this chat client is going to be much more feature rich and maintained than jsxc version. Reference for this is here https://twitter.com/jcopkode/status/938028287804215296
Even jabber supports his work https://twitter.com/jabber_at/status/938064320990208000

Hope this helps.

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Dec 17, 2017

I've been thinking on this issue for a while. Actually what I think is that we shouldn't use ready-made javascript clients like JSXC or Converse.js. These clients are basically GUI clients based on strophe.js XMPP JS library. These clients don't provide rich integration options, they make a lot of assumptions. Primarily, they assume that you want to integrate the chat as an overlay to your web application. Since we have our own messaging system and its frontend, it will always be confusing to have two separate messaging systems in the UI for the users. It already happens: people ask if the XMPP integration suppose that the XMPP messages archive is available in diaspora inbox, because that's what they expect from integration.

Basically, non-technical people don't care about protocols and it makes no sense at all to have two different messengers in the same application for them. It is totally unclear in which cases a user should use one over another. So I think that what we need is a single common messaging UI for both diaspora messaging and XMPP. That's something we can't provide by integrating JSXC or Converse.js because it goes against the assumptions made by developers of these clients. What we need is a multiprotocol JS messaging client, which supports both diaspora messaging and XMPP in the same UI.

I'm not aware of the existence of a multiprotocol JS messenger. If there was one we could just extend it to support diaspora. If there is not, we basically should develop one. Also, I think that to do that in the best possible way we also should base this client on the future specified official diaspora API instead of internal API for diaspora messaging support. For XMPP we can take strophe.js as an XMPP library, just like Converse.js and JSXC do.

Furthermore, if we are going to work on such a project, it would make sense to make this software modular, so that people can reuse this code on their websites. This is basically JS code, so that shouldn't depend too much on diaspora design. Designing protocol support for XMPP and diaspora as modules for the core messenger client would mean that this project could be reusable as an XMPP client by other projects. Especially that could be useful for other federated network projects, because they would likely face the same problems.

Of course this is a big task. I would love to work on that myself. I have to finish the account migrations thing first though. It is not that long to go, but still it would take time. By accident I'm working on a similar problem at my paid stuff, which includes XMPP over JS. So that would be convenient since I can reuse the same knownledge. Unless I'm hit by bus or a similar valid reason I'll work on the chat as my next big project for diaspora after the migrations work finished. But I won't give any terms now. So if anyone takes this over I'm totally fine with it.

Of course, if anyone has the points against the approach I propose, I'd love to know that.

@SuperTux88

This comment has been minimized.

Copy link
Member

SuperTux88 commented Dec 18, 2017

It sounds difficult to me to unify diaspora-messages and XMPP, because with messages you can have multiple conversations with the same person (with different subjects), while with XMPP you usually have one 1:1 chat with that person where you talk about everything. Also diaspora conversations can have up to 20 participants, while XMPP usually only has two (there are group chats, but that's again something different to me). So I think it's difficult to design a UI for this, where you can create a new diaspora conversation with many recipients as also answer to XMPP chats.

But your proposal still sounds better than everything we had yet, so I think it goes in the right direction. And with a unified UI we can also hide that only some of the pods have XMPP, and it still looks the same, and when a contact doesn't have XMPP we can just fallback to diaspora message.

So please don't get hit by a bus, and I'm happy that this chat topic finally gets some love again, because the current half-finished unmaintained experiemental state is bad (for example we can't update some dependencies, because the chat depends on old versions ...).

@jcbrand

This comment has been minimized.

Copy link

jcbrand commented Dec 18, 2017

These clients don't provide rich integration options, they make a lot of assumptions. Primarily, they assume that you want to integrate the chat as an overlay to your web application.

Actually, you're making a lot of assumptions.

The overlay option is one way of doing things, and IMO if fits well to something like Diaspora*. From what I can tell, the lack of integration manifests elsewhere, not with the overlay UX paradigm.

That said, Converse.js also has a fullscreen view and also has the option of embedding a groupchat inside a page (i.e. not overlayed). This could be expanded for private chats as well if need be.

Furthermore, it can also be used completely headless, so that you have all the internals (the "engine" so to speak) without any UI, which you would then implement yourself.

There's a developer API, lots of documentation and a 3rd party plugin system. I've spent a lot of time and effort on these things, so to hear "don't provide rich integration options" is kind of annoying.

Also, it's been integrated into Intranets, Desktop applications and various content management systems.

Can things like the API, the documentation and whatever else be improved? Yes.
Would it be better with ${your-favorite-feature}? Probably yes.

If so, why not contribute on those things for Converse.js (or JSXC if you so prefer) and make the existing code base better, rather than starting from scratch?

I get it, writing something from scratch is much more fun and there're no legacy issues to have to worry about. It's also the reason why lots of FOSS doesn't get off the ground, because so many devs think they'll replace/redo something (which took years to build) over a weekend, then inevitably figure out it's more effort than they thought and then abandon it or let it languish.

Converse.js is in use right now in professional and commercial websites that charge money and therefore have more accountability and that have more users than Diaspora pods.

Also, if you think Converse.js is simply a UI wrapper around Strophe.js, you're mistaken.
I've been maintaining Strophe.js for about 3 years now, and when I could I would implement features directly in Strophe.js instead of in Converse.js

However, Converse.js provides automatic reconnection, intelligent roster management, conversation management, caching of resources across page loads and various other features that are more high level.

Furthermore, with Strophe.js by itself, the Strophe.Connection object is global, allowing malicious JavaScript to access the user's messages, archive and to even send presence and messages on the user's behalf.

Converse.js is designed to keep all the private stuff (including Strophe.Connection) in a closure, so that it's not accessible from the outside.

Ok... so all of that said. Better integration into Diaspora* is obviously a good thing, and if you could somehow show the Diaspora* messages and the XMPP messages in one place, perhaps that's good as well, although it's not clear to me how you expect to do this.

If this is your goal, you could still do all of this with Converse.js. Like I said, you can use a headless/non-UI build and build your own UI and integration and then add the Diaspora messaging API integration into a 3rd party plugin.

Obviously I'm biased, but this is the approach I would take if I wanted to write my own UI, and for what it's worth Converse.js is currently running in exactly this way in a large commercial website.

This is basically JS code, so that shouldn't depend too much on diaspora design. Designing protocol support for XMPP and diaspora as modules for the core messenger client would mean that this project could be reusable as an XMPP client by other projects.

In other words, doing exactly what Converse.js and JSXC are doing except with added Diaspora* messaging support.

Diaspora* messaging could be implemented as a 3rd party plugin for Converse.js.

for example we can't update some dependencies, because the chat depends on old versions

Converse.js is bundled in such a way that it's completely self-contained. So if you were to use it, this wouldn't be an issue.

@SuperTux88

This comment has been minimized.

Copy link
Member

SuperTux88 commented Dec 18, 2017

for example we can't update some dependencies, because the chat depends on old versions

Converse.js is bundled in such a way that it's completely self-contained. So if you were to use it, this wouldn't be an issue.

What I was talking about was JSXC (which diaspora uses currently), because when the chat was added JSXC was forked (I don't know why?) and now nobody maintains the fork, so it still depends on old dependencies.

I didn't have to do much with the chat, and I never used it myself (neither JSXC nor converse.js), but what I had read about this topic now, it would already be an improvement to drop JSXC and replace it with converse.js.

But when senya wants to work on this now, I think we can just wait what he plans to do, and maybe he can use converse.js in his solution. I only want to get rid of the old unmaintained JSXC fork. :)

@Flaburgan

This comment has been minimized.

Copy link
Member

Flaburgan commented Dec 18, 2017

First of all, I'm very happy to see you want to work on that topic @cmrd-senya. As @SuperTux88 said, the current state of the chat is a real problem for diaspora* evolution.

That being said, I mainly agree with @SuperTux88: to unify diaspora* and XMPP probably is not worth it. The use cases are different. I use PM to plan my vacations with my friends. I chat when I have something quick to say. I know Facebook unified PM and chat and that's probably the only reason why we would want to do that: an UX similar to facebook is easier for the new users. But that looks like a lot of work for this only.

I personally don't care about Converse or JSXC, what I want is a chat feature:

  • Which is easy to install (the current guide is a mess, with migration from vines to prosody, we need something damn simple)
  • Which is available on every diaspora* page, with logging in / out at each refresh
  • Which allows to control who can chat with whom
  • Which has a design nicely integrated in diaspora*'s one
  • Optionally, OTR and chat history would be nice
@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Dec 18, 2017

@jcbrand, thanks for your reply and explanations!

I spent some time with Converse.js, not too much though. I skimmed through available docs and I didn't see any notice of this "headless" integration. I really don't think we should use the provided UI since we will not have enough control over it so headless mode is probably the thing which we should try here. Could you please provide any link to some information on how it works and where should I start from?

It sounds difficult to me to unify diaspora-messages and XMPP, because with messages you can have multiple conversations with the same person (with different subjects), while with XMPP you usually have one 1:1 chat with that person where you talk about everything. Also diaspora conversations can have up to 20 participants, while XMPP usually only has two (there are group chats, but that's again something different to me). So I think it's difficult to design a UI for this, where you can create a new diaspora conversation with many recipients as also answer to XMPP chats.

Well, XMPP have MUCs and we have a feature request to support MUCs with XMPP integration, so we probably should just use MUCs for that. But it's true that XMPP MUCs are quite different from our multi user conversations.

The use cases are different. I use PM to plan my vacations with my friends. I chat when I have something quick to say.

Well, for me such explanation doesn't show the difference :P

Diaspora messanging and XMPP are basically doing the same thing: they pass messages from one client to another using federated servers. So technically use cases can't be different. It can be different in terms of UI. To say something quick you may want to have a little overlay window and to plan and write big messages you may want to use full screen messenger on a separate page. But this is just a matter of UX, not of the protocol. The same thing may be implemented both with XMPP and Diaspora. And there are some people who don't want to learn about protocols, so why should we put UX in dependence of protocols?

3 cases are possible:

  • Contact is added from diaspora and doesn't have XMPP support
  • Contact is added from diaspora or XMPP external client and has XMPP support and is a diaspora user
  • Contact is added from XMPP external client and is not a diaspora user (XMPP-only contact)

That is something that we already have. I mean each case already happens in diaspora. So we have to deal with that in a clean way.

I think that when all parties support XMPP we should use XMPP for chatting. In this case we can use message archiving XMPP feature to make messages accessible from diaspora Web UI afterwards. So if a person makes a switch from XMPP client to diaspora web app during the talk they will still see the message history (unless they use encrypted chat of course). When XMPP is not available then we just use diaspora protocol for messaging and don't use neither XMPP c2s nor XMPP s2s. Messages that are sent by diaspora protocol are not forwarded to XMPP so they won't be visible to external XMPP clients and therefore diaspora protocol should not be used when XMPP is available. UI should select XMPP automatically in this case. Also I think that XMPP roster should only contain contacts who support XMPP so that user can't write from external XMPP client to a contact whose pod doesn't support XMPP. Otherwise things would get complicated.

It's get more complicated with multiuser chats, since XMPP MUCs require explicit connection, you can't send a message to a user if they are not online. XMPP doesn't federate MUC messages unless user is connected to the chat.

That needs additional consideration but I think it is okay to assume that multiuser conversations can be possible only with the diaspora protocol for the first time, before we come up with a better solution.

@Flaburgan

This comment has been minimized.

Copy link
Member

Flaburgan commented Dec 18, 2017

Diaspora messanging and XMPP are basically doing the same thing: they pass messages from one client to another using federated servers. So technically use cases can't be different.

Well in that case, we could drop the diaspora* protocol completely :p

I'm sorry but I disagree here. Use cases are different. A diaspora* PM has rich content. It has a subject, several recipients. I can have different threads with the same user. It supports HTML, you can write in it with markdown, embed image, (hopefully soon) videos, link diaspora posts with diaspora:// links... All that wouldn't be rendered in a traditional XMPP client like Pidgin for example. PM is like e-mail. Chat is like... chat. I don't see why we should force them to be merged.

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Dec 18, 2017

Well in that case, we could drop the diaspora* protocol completely :p

We can't, otherwise we'll have to force podmins to install XMPP servers in order to have working PM, and that would be a maintanance nightmare.

I'm sorry but I disagree here. Use cases are different. A diaspora* PM has rich content. It has a subject, several recipients. I can have different threads with the same user. It supports HTML, you can write in it with markdown, embed image, (hopefully soon) videos, link diaspora posts with diaspora:// links... All that wouldn't be rendered in a traditional XMPP client like Pidgin for example. PM is like e-mail. Chat is like... chat. I don't see why we should force them to be merged.

Again, there is no reason why one can't use XMPP for email or IMAP for instant messaging. That not a question of protocols, that's a question of frontend. If one implements an IMAP support Pidgin plugin that would totally work. That just doesn't make too much sense, because people don't use IMAP this way (because it is old and limited). But with social networking software people expect UI to be asynchronous. People expect new messages to appear without a page reload. So basically having separate UIs for diaspora protocol and XMPP would mean implementing the same UI concept twice without clear difference of use cases.

If you see different UI usecases for messaging, it is totally fine. I agree with that. There is a case when you want to type a quick note and that is convinient to do in a little overlay window and there is a case when you want to type a long message with formatting and this requires a separate full screen page for that. That's fine to support both approaches: having overlay on pages and a separate page. But that has nothing to do with the protocol. Protocol just defines the details of how messages get from one client to another. That's it. You can use protocol in different ways and some people even build social networking on XMPP, so our limited usage of XMPP should be totally fine for any possible UI approach we come up with.

XMPP supports rich content in some way, so I guess it's mostly about conversion from markdown to whatever XMPP supports. Support of diaspora:// links in external software is something we can't do anything about and that would be a problem even with the current XMPP integration.

@Flaburgan

This comment has been minimized.

Copy link
Member

Flaburgan commented Dec 18, 2017

Well in that case, we could drop the diaspora* protocol completely :p

We can't, otherwise we'll have to force podmins to install XMPP servers in order to have working PM, and that would be a maintanance nightmare.

That was a joke. When I was saying completely, I was saying... completely. No more diaspora_federation. Build a social network on XMPP, exactly like you talked about later in your answer. But as you said for IMAP, XMPP is not good for that. And, at the moment, I guess diaspora* is not good for chat (even if we never tried, it was not thought for instantaneous usages).

We pick up XMPP because we thought it was not a good idea to add IM feature inside the diaspora* protocol, especially when there is already a standard widely used and which works well. We're not Facebook, and it looked fair to have our XMPP server open, so users can be connected with external clients. To try to render markdown and all rich content, separated threads etc like I described above looks like a massive task totally not worth it.

I have difficulties to understand you here, let's go to IRC it will probably be easier ;)

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Dec 18, 2017

There is no reason why we can't build IM in diaspora with the diaspora federation protocol. Again, it's not a question of a protocol. I can write a simple frontend which would rely on diaspora web app and diaspora federation which would work as IM messenger. I don't need XMPP for that and we don't even need any federation changes for that. Just frontend changes and, well, maybe some controller changes. Basically there is absolutely no need to support XMPP for IM for us, that's a mistake to assume that XMPP support in diaspora is required for IM support. The reason to support XMPP is to support more protocols, so that people who are outside of diaspora can communicate with diaspora users without a need to register a new account. This is the same reason why we want ActivityPub or WebSub support in diaspora. XMPP as a way to support IM brings more issues than it solves and if that's the only reason why we support XMPP then we should drop XMPP and go on our own (because it's simpler).

@Flaburgan

This comment has been minimized.

Copy link
Member

Flaburgan commented Dec 18, 2017

As wrote, the reason we went with XMPP is because we love standards. But that means we need to support external client. So we're limited in our use of XMPP, that's why even if I agree protocol and UI are two different things, we can't mix it there: there is an UI we don't control.

@jcbrand

This comment has been minimized.

Copy link

jcbrand commented Dec 19, 2017

I skimmed through available docs and I didn't see any notice of this "headless" integration. I really don't think we should use the provided UI since we will not have enough control over it so headless mode is probably the thing which we should try here. Could you please provide any link to some information on how it works and where should I start from?

Converse.js is comprised out of plugins, so all features (except the very basic session management) are implemented as plugins.

You can see all the plugins in the src directory. They're all prefixed with converse-, for example converse-vcard.js.

The simplest way to make a headless build is to simply edit the src/converse.js file to remove those plugins that implement UI.

Then you run make build to generate a new build.

There is documentation on making custom builds of converse.js which explains this procedure but it doesn't specifically mention "headless" builds.

I'll update the documentation with regards to that, and I can also create a standard "headless" configuration and build for people to use.


Concerning the resulting discussion....

Markdown support

There is the newly created XEP-0393 which details a markdown-like syntax for XMPP messages and how displayed messages should be styled.

Some XMPP clients like Conversations already support this and I will add support for this to Converse.js as well.

There's also XEP-0394 which implements a more future-proof and more cleanly separated way of specifying rich content. This spec came out of a discussion around markdown support (and XEP-0393) and the fact that many people don't like including formatting information in the actual message text. So XEP-0394 separates the formatting info into a separate/sibling XML element.

There is also the HTML-IM XEP which adds support for HTML rendering in XMPP messages, but it's been decided to deprecate this XEP in favor of the above two, especially XEP-0394 I believe, since there have been multiple security bugs in the past with webclients implementing HTML-IM.

XMPP versus Diaspora* messaging protocol

FWIW, I tend to agree with @Flaburgan that it makes more sense to me to keep chat and long-form/threaded/rich messages separate.

Perhaps because I don't understand what @cmrd-senya really has in mind.

I don't see how you would combine the two. Would you want to duplicate all the Diaspora* messages across the XMPP network as well, or still keep some kind of separation between the two? If you still keep some kind of seperation between the two, then I don't see how a unified UI can be anything but confusing to users and also reduce interoperability with other XMPP clients and users who don't use Diaspora*.

If you really wanted to combine the two, then an alternative approach might be to instead implement a bridge between XMPP and Diaspora* Messaging, and then not have an XMPP client running in the browser at all. But then you'd need to translate all the concepts of Diaspora* messaging to XMPP. Many of them you could, for example rich messages, threads etc. However one thing XMPP doesn't support well yet is the concept of multiple different conversations with the same person. There's no way of grouping messages with someone else into separate conversations, unless you made each one a MUC or MIX conversation.

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Dec 19, 2017

I don't see how you would combine the two. Would you want to duplicate all the Diaspora* messages across the XMPP network as well, or still keep some kind of separation between the two? If you still keep some kind of seperation between the two, then I don't see how a unified UI can be anything but confusing to users and also reduce interoperability with other XMPP clients and users who don't use Diaspora*.

We don't need to dublicate the messages. Yesterday we had a discussion at the IRC channel and we came up with a term "messaging center" which combines all kinds of PMs in the same UI, but still renders them in a distinguishable way, so it is clear for a user whether they start a XMPP chat or a diaspora* conversation. Unified UI is still helpful, because some people don't care about protocols and it is more confusing to have similar messaging systems which look and feel differently than have them look and feel similar, but with underlined differences (e.g. subject field). XMPP and diaspora* messaging have many in common as for UI and I believe they should share the same UI implementation for the similar things.

However one thing XMPP doesn't support well yet is the concept of multiple different conversations with the same person. There's no way of grouping messages with someone else into separate conversations, unless you made each one a MUC or MIX conversation.

Well, I don't think we're going to implement current features of diaspora* conversations with XMPP, but there is actually a XEP-0201 which defines "threading" support for XMPP, and I think this is exactly what allows this "multiple different conversations with the same person" thing to be implemented. Maybe that would be interesting for us sometime in future, but not now.

@jcbrand

This comment has been minimized.

Copy link

jcbrand commented Dec 19, 2017

Ah, I didn't realise that the threading XEP could be thought of in such a way (I haven't studied it). If so, that's good then!

Thanks for the explanation regarding the UI center, I understand now and makes sense.

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Jan 17, 2018

I just noticed, that Converse.js is licensed under MPLv2 which is actually incompatible with AGPLv3 used by diaspora* project. We want to use converse.js as a library, but I'm not quite sure it works that way for javascript applications, since webapps are bundled together in a single entity.

@jcbrand

This comment has been minimized.

Copy link

jcbrand commented Jan 17, 2018

MPLv2 is compatible with GPLv3.

AFAIK version 2 of the MPL was created specifically to maintain compatibility with GPL.

https://opensource.com/law/11/9/mpl-20-copyleft-and-license-compatibility

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Jan 17, 2018

Ok, nevermind. After a short talk with @jcbrand he explained to me that MPLv2 is actually compatible with AGPLv3 so it should be fine.

@cmrd-senya

This comment has been minimized.

Copy link
Member

cmrd-senya commented Feb 18, 2018

After this discussion it feels like chat improvements and rework are blocked by our future UI redesign plans

@denschub denschub added the orphan label Nov 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.