GNOME Bugzilla – Bug 541156
Handle xmpp:// links
Last modified: 2018-05-22 13:10:17 UTC
It would be great to have an xmpp handler for a better desktop integration.
John uses its browser and click on an xmpp links (contact or chatroom) and it opens directly with empathy.
irc://, aim:// and all others are welcome to.
Yes, could be great. Could you describe the xmpp:// URI format? is it simply xmpp://firstname.lastname@example.org? What empathy is supposed to do, open a chat with the contact or add it the the contact list?
These chapters briefly describe all formats:
xmpp URI format is entirely describe in RFC5122 (which obsoletes RFC4622) and XEP-0147 here:
For IRC uri, I found these draft:
This document form Mozilla Team could be usefull:
For AIM, I found this wikipedia topic:
For Yahoo Messenger (ymsgr:):
For MSN (msnim:):
RFC3860 describe Common Profile for Internet Messaging (CPIM):
I hope this will help.
It probably should happen lower in the Telepathy stack; then it would do the appopriate D-Bus calls and Empathy would open if appropriate.
Xavier: do you have any idea about the Telepathy component that should handle this? Care to file a bug there?
When implementing this sort of thing, remember that URIs are noun phrases, not verb phrases.
xmpp:email@example.com (there is no // by the way, iirc) represents a noun, "Simon" (or possibly "Simon's IM client", depending on your point of view). It does not represent a verb like "talk to Simon", "call Simon", "add Simon to my contact list".
This is why the mailto: URI scheme is misleading - there are many things you can do with an e-mail address (send email to it, add it to your address book, add it to a whitelist/blacklist) - and all the non-standard URI schemes inspired by it, like callto: or voipto:, are wrong.
*In the specific case of XMPP* there is a concept of using query strings to indicate a verb. This doesn't really fit into the URI model, but anyway...
So, you can have (for instance) xmpp:firstname.lastname@example.org?message or xmpp:email@example.com?roster. See XEP-0147.
Understanding URIs is necessarily protocol-specific, so it's inappropriate for "Mission Control" (whatever that means in the new Account Manager/Channel Dispatcher design) to be responsible for it. Empathy already has to have some protocol-specific code, so in the short term it might be appropriate for Empathy to have protocol-specific understanding of URIs.
Rob has some ideas about adding an optional interface on connection managers that deals with URIs (and, in general, "other representations" for contact IDs). This is certainly not a short-term thing, though.
I am assigning this bug to myself as I'll now work on this.
As it stalled I will list the two major missing pieces to get it done properly.
1) no way to get the current list of contacts; there is a callback for add/remove contacts but no way to know when it is complete, which would be required to get the right McAccount (if firstname.lastname@example.org is in the contact list of my "jabber.org" account, xmpp:email@example.com?message... should open a chat window with that account, not with another unrelated "im.apinc.fr" account)
2) no way to prefill most dialogs, xmpp:firstname.lastname@example.org?roster;name=Foo should open the "new contact" dialog with the jid and alias prefilled; xmpp:email@example.com?message;body=hello should open a chat window with the text box prefilled with "hello".
How I can check this? Something like this?
It does'nt work. What I doing wrong?
Well, I have another question ... how this bug is supposed to be resolved for people with multi-account Empathy? Which account is used? Do we have a concept of "default XMPP/AIM/ICQ/whatever account"?
Given the Empathy UI, I think the sane way to handle generic xmpp:jid (no query) URIs is to start a conversation with that JID. If you have multiple XMPP accounts it could pop up a list of them and ask which one to use.
*** Bug 613847 has been marked as a duplicate of this bug. ***
From bug #642342:
Something like this I think:
diff --git a/data/empathy.desktop.in.in b/data/empathy.desktop.in.in
index 7cce226..448ff40 100644
@@ -10,6 +10,7 @@ StartupNotify=false
*** Bug 642342 has been marked as a duplicate of this bug. ***
For the record: http://wiki.xmpp.org/web/XMPP_URIs
So, I think the right way to implement this is to create a small empathy-uri-handler binary just responsible of handling such URIs. Depending of the action, it will:
- request a text or call channel and let MC dispatch it. Sending some messages if needed.
- Ask empathy (the contact list) to open the "new contact dialog" with some fields pre-filled. This should be done using a specific D-Bus API.
I think those 2 cases are good enough for a start.
(In reply to comment #13)
> For the record: http://wiki.xmpp.org/web/XMPP_URIs
> - request a text or call channel and let MC dispatch it. Sending some messages
> if needed.
In this case if there is more than one valid account, we should popup the user
asking him to choose the one it wants to use.
> - Ask empathy (the contact list) to open the "new contact dialog" with some
> fields pre-filled. This should be done using a specific D-Bus API.
This is not a problem here as user can easily select another account in the
'new contact' dialog if he wants to.
(In reply to comment #6)
> As it stalled I will list the two major missing pieces to get it done properly.
> 1) no way to get the current list of contacts; there is a callback for
> add/remove contacts but no way to know when it is complete, which would be
> required to get the right McAccount (if firstname.lastname@example.org is in the contact list
> of my "jabber.org" account, xmpp:email@example.com?message... should open a chat
> window with that account, not with another unrelated "im.apinc.fr" account)
This is now doable using contact list API.
> 2) no way to prefill most dialogs, xmpp:firstname.lastname@example.org?roster;name=Foo should
> open the "new contact" dialog with the jid and alias prefilled;
> xmpp:email@example.com?message;body=hello should open a chat window with the text
> box prefilled with "hello".
As said, this should be done using a specific D-Bus API.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/18.