Last Comment Bug 735215 - Enable Jabber / generic XMPP protocol
: Enable Jabber / generic XMPP protocol
Status: RESOLVED FIXED
:
Product: Thunderbird
Classification: Client Software
Component: Instant Messaging (show other bugs)
: Trunk
: All All
: -- normal with 4 votes (vote)
: Thunderbird 15.0
Assigned To: Florian Quèze [:florian] [:flo]
:
Mentors:
: 744002 (view as bug list)
Depends on: 741550
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 06:49 PDT by Sonny Piers [:sonny]
Modified: 2015-07-30 03:37 PDT (History)
21 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch to enable it (1.24 KB, patch)
2012-03-14 06:38 PDT, Florian Quèze [:florian] [:flo]
clokep: review+
Details | Diff | Splinter Review
xmpp icons (4.25 KB, patch)
2012-04-18 07:19 PDT, Andreas Nilsson (:andreasn)
no flags Details | Diff | Splinter Review
xmpp icons (v2) (4.28 KB, patch)
2012-04-18 07:38 PDT, Andreas Nilsson (:andreasn)
no flags Details | Diff | Splinter Review
xmpp icons (v3) (4.30 KB, patch)
2012-04-18 08:36 PDT, Andreas Nilsson (:andreasn)
bwinton: ui‑review-
Details | Diff | Splinter Review
icon preview (18.63 KB, image/svg+xml)
2012-04-24 14:46 PDT, Andreas Nilsson (:andreasn)
no flags Details
XMPP icons (7.56 KB, patch)
2012-04-25 08:33 PDT, Andreas Nilsson (:andreasn)
florian: review+
bwinton: ui‑review+
Details | Diff | Splinter Review
patch with icons (v5) (7.54 KB, patch)
2012-04-25 08:41 PDT, Andreas Nilsson (:andreasn)
no flags Details | Diff | Splinter Review
patch with icons and enabling (8.49 KB, patch)
2012-05-28 05:06 PDT, Andreas Nilsson (:andreasn)
florian: review-
Details | Diff | Splinter Review
Screenshot of the icons in use (59.42 KB, image/png)
2012-06-04 03:25 PDT, Florian Quèze [:florian] [:flo]
no flags Details

Description Sonny Piers [:sonny] 2012-03-13 06:49:57 PDT
After a discussion with Florian it appears that generic Jabber support is disabled because of the lack of support for DNS SRV (see bug 14328).

While it might makes sense on InstantBird since libpurple does provides SRV support and XMPP-JS doesn't, meaning it would be a regression, I don't think TB should wait for SRV support to enable generic Jabber.

Almost every public Jabber servers runs on port 5222.
Comment 1 Florian Quèze [:florian] [:flo] 2012-03-14 06:38:13 PDT
Created attachment 605724 [details] [diff] [review]
Patch to enable it

In case we decide we want to go ahead with this request, here are the trivial code changes needed.

If we enable it, we will also need icons for it (the icon Instantbird currently uses for XMPP comes from libpurple, so I assume it's GPL'ed).
Comment 2 Rimas Kudelis 2012-03-16 06:20:05 PDT
AFAIK, SRV support is only needed to find the right server to connect to? If so, perhaps it's possible to simply add a separate input field (or two) to enter server details, until SRV support is added?
Comment 3 Sonny Piers [:sonny] 2012-03-17 05:38:44 PDT
Rimas, those fields already exists.
SRV support are only needed if the XMPP server software is not running at the same host than the domain and/or if a custom port is used.

Florian, who is supposed to decide either generic Jabber is enabled or not ?

This as really to be fixed, SRV is a nice to have feature but shouldn't be a blocker.
Comment 4 Rimas Kudelis 2012-03-17 05:43:38 PDT
(In reply to Sonny Piers [:sonny] from comment #3)
> Rimas, those fields already exists.
> SRV support are only needed if the XMPP server software is not running at
> the same host than the domain and/or if a custom port is used.

Yeah, but I mean that if I KNOW the right hostname and port, then I could just enter that info manually even without SRV enabled.
Comment 5 Florian Quèze [:florian] [:flo] 2012-03-17 06:52:17 PDT
Also note that specifying a custom connect server will cause a problem for encrypted connections, as the hostname NSS will expect in the certificate will be the hostname of the connect server; whereas the XMPP spec says it should be the hostname that is part of the Jabber ID.
Comment 6 Florian Quèze [:florian] [:flo] 2012-03-17 06:55:15 PDT
(In reply to Sonny Piers [:sonny] from comment #3)

> Florian, who is supposed to decide either generic Jabber is enabled or not ?

Not sure, but most likely jb + a subset of bienvenu, bwinton, Standard8 and me.
Comment 7 Florian Quèze [:florian] [:flo] 2012-03-20 09:18:03 PDT
I discussed this with Jb today, he thinks we should take this change, so we will need an icon for this protocol plugin (CC'ing Andreas).
Comment 8 David :Bienvenu 2012-03-20 10:28:52 PDT
The main downside would be potential support issues?
Comment 9 Florian Quèze [:florian] [:flo] 2012-03-20 10:34:25 PDT
(In reply to David :Bienvenu from comment #8)
> The main downside would be potential support issues?

Right, users may be confused by the lack of auto-detection of the connect server (DNS SRV) and by the broken SSL certificates because of mismatched hostnames (see comment 5) if they do configure the connect server by hand.
Comment 10 David :Bienvenu 2012-03-20 10:36:09 PDT
thx, cc'ing Roland then. But I suspect Jabber users are probably more tech savvy than the average user.
Comment 11 Rimas Kudelis 2012-03-20 10:44:31 PDT
Advanced settings (manual server configuration) could be hidden in about:config. :) This way only tech-savvy users could get to the options. AND this would probably make at least a few admins add SRV entries to their zones. ;)
Comment 12 Matthew Wild 2012-03-20 12:16:05 PDT
Hi folks, for what it's worth I disagree with the gist of both comments #10 and #11 - I can guarantee that there are many people using XMPP who are not any more tech savvy than the average user.

Most mainstream XMPP clients today do indeed hide the setting for manually specifying the connection host+port away in advanced configuration - as a result you would be extremely hard-pushed to find any XMPP services out there in the wild that require manual configuration of this. SRV is always present where necessary - but do make sure you fall back to A records when no SRV is present, as many services do *not* have SRV records when the target would be the same as the XMPP hostname.
Comment 13 Roland Tanglao :rolandtanglao 2012-03-20 12:21:44 PDT
+1 on supporting random jabber servers of doom :-) (I like jabber & have BTW) if we have a nice settins UI as per comment 11, comment 9 and comment 12 
i.e. SRV, A records, etc plus OPTIONAL (if we have dev resources) hidden manual config for people using unorthodox servers)
Comment 14 Florian Quèze [:florian] [:flo] 2012-03-20 13:04:26 PDT
Comments 11, 12 and 13 seem to assume we have DNS SRV support. We don't (and that's written very clearly in the first sentence of comment 0); it's blocked on bug 14328, the ETA of which is very uncertain even though there seems to be some work happening there these days.
Comment 15 Rimas Kudelis 2012-03-20 14:02:05 PDT
Right, I forgot about that... :)
Comment 16 Sonny Piers [:sonny] 2012-03-20 14:56:37 PDT
It seems we won't have SRV support in a short time and as Florian told us in comment 5 there are issues with SSL and custom host/port so my suggestion is:
Generic Jabber is added.
No GUI for custom host / port (comment 11).
Advocate about the possibility for addons to add a "non-generic Jabber protocol" (such as Gtalk and Facebook).
A document somewhere that explains the issues, how to use a custom host/port and how to add a certificate exception.
Comment 17 Ben Bucksch (:BenB) 2012-04-02 14:29:16 PDT
In the mail account setup wizard, we needed DNS MX. We had the same problem as here, and decided to use a web service (and switch to client-side DNS requests as soon as it's possible in Mozilla).
https://live.mozillamessaging.com/dns/mx/web.de
This is fairly simple to implement on server-side and client-side.
The obvious privacy issue of "phoning home" is 1) limited and 2) relative.
1) We only need to do that at setup, to save the user from knowing the XMPP server hostname (which he can't), and cache the hostname in prefs (in a different pref, separate from a user-entered hostname). Optionally, we can also query the web service again when we fail to connect, in case the hostname changed (and only if the hostname was cached and not entered by the user)
2) The privacy impact of pushing existing Jabber users to using Facebook and GTalk is much more severe, as Facebook and Google log all conversations (!), not just the hostname. The privacy impact is a lot more severe, so we shouldn't worry about hostname lookups and rather concentrate to not push Facebook over Jabber, but rather encourage users to leave Facebook, not join it.

So, being a privacy advocate myself, I would much rather have TB make a hostname lookup at mozilla.com than have even a single (!) TB release that supports Facebook and not Jabber. Jabber must be there from the start.
Comment 18 Kami 2012-04-05 00:57:16 PDT
I also would like to use Jabber too.
Comment 19 Ludovic Hirlimann [:Usul] 2012-04-10 07:46:24 PDT
*** Bug 744002 has been marked as a duplicate of this bug. ***
Comment 20 Ludovic Hirlimann [:Usul] 2012-04-10 07:49:22 PDT
*** Bug 744002 has been marked as a duplicate of this bug. ***
Comment 21 Andreas Nilsson (:andreasn) 2012-04-18 07:19:38 PDT
Created attachment 616119 [details] [diff] [review]
xmpp icons

Not that I've gotten something backwards with the jar.nm file so this dude won't compile properly.
Comment 22 Andreas Nilsson (:andreasn) 2012-04-18 07:38:45 PDT
Created attachment 616128 [details] [diff] [review]
xmpp icons (v2)

This compiles! :)
Comment 23 Andreas Nilsson (:andreasn) 2012-04-18 08:36:00 PDT
Created attachment 616154 [details] [diff] [review]
xmpp icons (v3)

There, sorted out the somewhat inconsistent xmpp/jabber naming scheme, so now the icons should display correctly.
Comment 24 Patrick Cloke [:clokep] 2012-04-18 08:42:46 PDT
A drive by comment for both Florian and Andreas: I think I'd prefer seeing XMPP throughout both sets of patches, it's the "proper" protocol name. I believe using "Jabber" as a name is deprecated and should not be further encouraged (see http://xmpp.org/about-xmpp/history/). I could be convinced otherwise for user facing strings...but internally, it should be XMPP (as are all the JSMs that implement it).
Comment 25 Yunier J. 2012-04-19 11:00:18 PDT
For what version of Thunderbird, XMPP will be present? In my school exit a server Jabber and many people have comment about this feature and not support for XMPP protocol.

Here we using proxy and Thunderbird never connected to Facebook or Gmail, I thing that Thunderbird not use the configuration of my proxy for connect.  Someone can me clarify this?
Comment 26 Andreas Nilsson (:andreasn) 2012-04-24 02:04:40 PDT
Comment on attachment 616154 [details] [diff] [review]
xmpp icons (v3)

Setting this up for review
Comment 27 Blake Winton (:bwinton) (:☕️) 2012-04-24 12:15:07 PDT
Comment on attachment 616154 [details] [diff] [review]
xmpp icons (v3)

I think the new icon looks a little too much like Facebook.

Perhaps we can use the official XMPP icon?  Something like http://tinyurl.com/7t5ty5e ?
Comment 28 Rimas Kudelis 2012-04-24 12:22:37 PDT
I haven't looked at the patch attached and I don't know what they show, but I think I'd prefer a lightbulb icon for XMPP. It's somewhat a de-facto standard, IMO.

Although if the XMPP icon looks good and recognisable at low resolutions, it may work as well too...
Comment 29 Ben Bucksch (:BenB) 2012-04-24 12:29:41 PDT
> lightbulb icon for XMPP. It's somewhat a de-facto standard

Yup. And please call it "Jabber" in the UI, because Facebook and GTalk are technically XMPP, too. And "Jabber" is a more appealing name to users.
Comment 30 Patrick Cloke [:clokep] 2012-04-24 12:35:22 PDT
(In reply to Ben Bucksch (:BenB) from comment #29)
> > lightbulb icon for XMPP. It's somewhat a de-facto standard
> 
> Yup. And please call it "Jabber" in the UI, because Facebook and GTalk are
> technically XMPP, too. And "Jabber" is a more appealing name to users.

I would really prefer it gets called XMPP in the UI, as that's it's actual name... See comment 24. I don't see what this has to do with Facebook or GTalk using XMPP as a backend, by that argument "Jabber" should be an alias for jabber.org accounts. We don't hide other actual protocols (such as POP3 or IMAP or SMTP) in the UI, no reason to call XMPP by anything other than what it is.
Comment 31 Ben Bucksch (:BenB) 2012-04-24 12:47:05 PDT
XMPP is the generic protocol, including pure computer-to-computer communication,
Jabber is "cute" common name for the IM network, including server-to-server messaging, but for human-human-communication.
Comment 32 Mike Taylor [:bear] 2012-04-24 13:00:32 PDT
XMPP is the proper name for the protocol and also the many services using the protocol.

My preference would be to use XMPP and the official XMPP logo.  Jabber is an older deprecated name and also copyrighted by Cisco.

The XMPP logo should also be used for the same reasons.

bear
(wearing my XMPP Software Foundation board member hat)
Comment 33 Blake Winton (:bwinton) (:☕️) 2012-04-24 13:09:14 PDT
Those sound like good reasons to go with XMPP to me, bear.  To make it official, calling it "XMPP" gets my ui-r+.

Now, hopefully, we can get on to other important matters, like deciding how many pixels wide the default contact list should be…  ;)

Thanks,
Blake.
Comment 34 Ben Bucksch (:BenB) 2012-04-24 13:50:17 PDT
> Jabber is ... also copyrighted by Cisco.

Just to de-mystify this:
1. You can't copyright a name, so it's a trademark.
2. Jabber, Inc, not part of Cisco, owns the trademark, but explicitly allows unlicensed (!) use of "Jabber" when refering to the technology, very similar to "Linux" or "Open-Source"
http://xmpp.org/about-xmpp/xsf/jabber-trademark/guidelines/
3. Unlike patents, once a name is in general use, the trademark owner cannot just revoke it anymore.
So, the trademark doesn't pose a problem for us. The trademark only protects against abuse of the name.

Most programs I've seen use "Jabber", others use "Jabber/XMPP". The latter allows users who are familiar with either name to find it.

That said, whatever bwinton says is the decision.
Comment 35 Ben Bucksch (:BenB) 2012-04-24 13:50:59 PDT
s/not part/now part/ (sorry - I'll shut up now)
Comment 36 Andreas Nilsson (:andreasn) 2012-04-24 14:46:55 PDT
Created attachment 618055 [details]
icon preview

Something more like this?
A bit messy in the smallest size maybe, but I'll see what I can do.
Comment 37 Blake Winton (:bwinton) (:☕️) 2012-04-25 07:46:53 PDT
(In reply to Andreas Nilsson (:andreasn) from comment #36)
> Something more like this?
> A bit messy in the smallest size maybe, but I'll see what I can do.

ui-r=me for that.  Also, feel free to ping the XMPP people, since they probably already have icons of various sizes we can use…  ;)

Thanks,
Blake.
Comment 38 Neustradamus 2012-04-25 08:27:26 PDT
I am ok with comment 24, comment 27 and comment 32 : XMPP and XMPP logo.

It is XMPP since 2004, we are in 2012.

http://xmpp.org/about-xmpp/history/
http://en.wikipedia.org/wiki/File:Logo_XMPP.svg
Comment 39 Andreas Nilsson (:andreasn) 2012-04-25 08:33:49 PDT
Created attachment 618282 [details] [diff] [review]
XMPP icons
Comment 40 Andreas Nilsson (:andreasn) 2012-04-25 08:41:36 PDT
Created attachment 618286 [details] [diff] [review]
patch with icons (v5)

And make sure we use the name xmpp everywhere.
Comment 41 Florian Quèze [:florian] [:flo] 2012-04-25 13:25:20 PDT
(In reply to Andreas Nilsson (:andreasn) from comment #40)
 
> And make sure we use the name xmpp everywhere.

I think you noticed at comment 23 that the protocol plugin is called prpl-jabber and that this name is required for the icon to be used (this string isn't visible in the UI).
Comment 42 Sonny Piers [:sonny] 2012-05-25 09:58:16 PDT
Any update?
Comment 43 Andreas Nilsson (:andreasn) 2012-05-28 05:06:43 PDT
Created attachment 627670 [details] [diff] [review]
patch with icons and enabling

This also changes the name jabber to xmpp in xmpp.js and puts it all on top of Florian's patch.
Comment 44 Patrick Cloke [:clokep] 2012-05-30 12:09:24 PDT
Florian: I assume you added the application bit in the manifest so Instantbird will not use this until we have DNS SRV support?

So Florian and I discussed this a bit on IRC and we're not super happy about renaming the iconBaseURI to be different than the prpl-id. [1] Unfortunately we can't really just change all the backend code to refer to prpl-xmpp because Instantbird will require migration code then.

Although as we're only enabling this for Thunderbird anyway, it's possible we could switch to using prpl-xmpp and write the migration code later for Instantbird. Florian, what do you think?

[1] http://log.bezut.info/instantbird/120528/#m129
Comment 45 Florian Quèze [:florian] [:flo] 2012-05-30 12:57:06 PDT
(In reply to Patrick Cloke [:clokep] from comment #44)
> Florian: I assume you added the application bit in the manifest so
> Instantbird will not use this until we have DNS SRV support?

Right. Another solution would be to use an ifdef in the Makefile to package xmpp.js and xmpp.manifest only for Thunderbird.

> So Florian and I discussed this a bit on IRC and we're not super happy about
> renaming the iconBaseURI to be different than the prpl-id. [1] Unfortunately
> we can't really just change all the backend code to refer to prpl-xmpp
> because Instantbird will require migration code then.
> 
> Although as we're only enabling this for Thunderbird anyway, it's possible
> we could switch to using prpl-xmpp and write the migration code later for
> Instantbird. Florian, what do you think?

I think we can keep prpl-jabber. I don't think anybody cares enough about the jabber vs xmpp name to be upset if "jabber" is still used in an internal id that has no good reason to ever be exposed to the user.
Comment 46 Florian Quèze [:florian] [:flo] 2012-06-04 03:14:24 PDT
Comment on attachment 627670 [details] [diff] [review]
patch with icons and enabling

r- per comment 44.

Attachment 618282 [details] [diff] looks good to me though, so except if you (Andreas) have a strong opinion against it, I propose that we take that one.
Comment 47 Florian Quèze [:florian] [:flo] 2012-06-04 03:15:05 PDT
Comment on attachment 605724 [details] [diff] [review]
Patch to enable it

This will need a review, requesting it from Patrick.
Comment 48 Florian Quèze [:florian] [:flo] 2012-06-04 03:20:38 PDT
Comment on attachment 618282 [details] [diff] [review]
XMPP icons

Attachment 616154 [details] [diff] has an ui-r- flag from Blake, so we need another ui-r from Blake on this new version of the icons.
Comment 49 Florian Quèze [:florian] [:flo] 2012-06-04 03:25:15 PDT
Created attachment 629738 [details]
Screenshot of the icons in use

Here's a screenshot of the XMPP icons used in the UI to simplify Blake's ui-review of attachment 618282 [details] [diff] [review].

These icons are based on the idea Blake gave in comment 27, so I'm confident he will be OK with them :).
Comment 50 Andreas Nilsson (:andreasn) 2012-06-04 05:24:43 PDT
(In reply to Florian Quèze from comment #46)
> Comment on attachment 627670 [details] [diff] [review]
> patch with icons and enabling
> 
> r- per comment 44.
> 
> Attachment 618282 [details] [diff] looks good to me though, so except if you
> (Andreas) have a strong opinion against it, I propose that we take that one.

Ney, I think it's good to keep the name consistent through the code, but I don't think that should block this bug.
Comment 51 Blake Winton (:bwinton) (:☕️) 2012-06-04 07:59:13 PDT
Comment on attachment 618282 [details] [diff] [review]
XMPP icons

I did say "ui-r=me for that", but to make it official, ui-r=me, based on the screenshots.  ;)

Thanks,
Blake.
Comment 52 Florian Quèze [:florian] [:flo] 2012-06-04 11:15:39 PDT
https://hg.mozilla.org/comm-central/rev/b1b9cdd88b60
https://hg.mozilla.org/comm-central/rev/5d613926d417

Resolving this bug as FIXED for Thunderbird 15, where we will have XMPP in the list of supported protocols, but resolving DNS SRV records is explicitly not supported yet in this version.
Comment 53 Ben Bucksch (:BenB) 2012-06-05 03:21:17 PDT
> resolving DNS SRV records is explicitly not supported yet in this version.

So, that means it's visible, but I can't use it (if the XMPP server hostname is not the domain itself)?
If so, can I request that we leave this bug open until this is resolved?
Comment 54 Patrick Cloke [:clokep] 2012-06-05 03:25:11 PDT
(In reply to Ben Bucksch (:BenB) from comment #53)
> > resolving DNS SRV records is explicitly not supported yet in this version.
> 
> So, that means it's visible, but I can't use it (if the XMPP server hostname
> is not the domain itself)?
> If so, can I request that we leave this bug open until this is resolved?

The depends to bugs are the bugs about DNS SRV (people should feel free to CC themselves to those). This bug is about enabling the XMPP protocol. Since that is done, this should remain closed. If you want to file a bug about XMPP not supporting DNS SRV, that would be appropriate.
Comment 55 Ben Bucksch (:BenB) 2012-06-05 03:28:06 PDT
Sorry, this makes no sense to say "yes, it's enabled, but it's not actually working".
In comment 17, I made a suggestion on how to do DNS SRV until the "DNS lookup in Mozilla" bugs are resolved.

Note You need to log in before you can comment on or make changes to this bug.