Closed Bug 735215 Opened 12 years ago Closed 12 years ago

Enable Jabber / generic XMPP protocol

Categories

(Thunderbird :: Instant Messaging, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 15.0

People

(Reporter: sonny, Assigned: florian)

References

Details

Attachments

(3 files, 6 obsolete files)

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.
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).
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?
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.
(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.
Assignee: nobody → florian
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.
(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.
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).
The main downside would be potential support issues?
(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.
thx, cc'ing Roland then. But I suspect Jabber users are probably more tech savvy than the average user.
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. ;)
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.
+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)
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.
Right, I forgot about that... :)
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.
Summary: Generic Jabber should be enabled → Enable generic XMPP protocol
Depends on: 545866, 14328
Summary: Enable generic XMPP protocol → Enable Jabber / generic XMPP protocol
Depends on: 741550
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.
I also would like to use Jabber too.
Attached patch xmpp icons (obsolete) — Splinter Review
Not that I've gotten something backwards with the jar.nm file so this dude won't compile properly.
Attached patch xmpp icons (v2) (obsolete) — Splinter Review
This compiles! :)
Attachment #616119 - Attachment is obsolete: true
Attached patch xmpp icons (v3) (obsolete) — Splinter Review
There, sorted out the somewhat inconsistent xmpp/jabber naming scheme, so now the icons should display correctly.
Attachment #616128 - Attachment is obsolete: true
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).
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 on attachment 616154 [details] [diff] [review]
xmpp icons (v3)

Setting this up for review
Attachment #616154 - Flags: ui-review?(bwinton)
Attachment #616154 - Flags: review?(florian)
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 ?
Attachment #616154 - Flags: ui-review?(bwinton) → ui-review-
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...
> 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.
(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.
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.
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)
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.
> 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.
s/not part/now part/ (sorry - I'll shut up now)
Attached image icon preview (obsolete) —
Something more like this?
A bit messy in the smallest size maybe, but I'll see what I can do.
(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.
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
Attached patch XMPP iconsSplinter Review
Attachment #616154 - Attachment is obsolete: true
Attachment #618055 - Attachment is obsolete: true
Attachment #616154 - Flags: review?(florian)
Attached patch patch with icons (v5) (obsolete) — Splinter Review
And make sure we use the name xmpp everywhere.
Attachment #618282 - Attachment is obsolete: true
(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).
Any update?
Attached patch patch with icons and enabling (obsolete) — Splinter Review
This also changes the name jabber to xmpp in xmpp.js and puts it all on top of Florian's patch.
Attachment #605724 - Attachment is obsolete: true
Attachment #618286 - Attachment is obsolete: true
Attachment #627670 - Flags: review?
Attachment #627670 - Flags: review? → review?(florian)
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
(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 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.
Attachment #627670 - Flags: review?(florian) → review-
Comment on attachment 605724 [details] [diff] [review]
Patch to enable it

This will need a review, requesting it from Patrick.
Attachment #605724 - Attachment is obsolete: false
Attachment #605724 - Flags: review?(clokep)
Attachment #618282 - Attachment is obsolete: false
Attachment #618282 - Flags: review+
Attachment #627670 - Attachment is obsolete: true
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.
Attachment #618282 - Attachment description: patch with new icons (v4) → XMPP icons
Attachment #618282 - Flags: ui-review?(bwinton)
Attachment #605724 - Flags: review?(clokep) → review+
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 :).
(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 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.
Attachment #618282 - Flags: ui-review?(bwinton) → ui-review+
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 15.0
> 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?
(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.
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.
Depends on: 787369
No longer depends on: 14328, 545866
No longer depends on: 787369
You need to log in before you can comment on or make changes to this bug.