Description

I think it would be great if libpurple supported ​XEP-0280: Message Carbons. It would make scenarios with multiple clients logged in at once much easier to handle.

I'm attaching a patch that implements support for this in libpurple. It adds a new menu item to any XMPP account that is logged in and where the server has indicated it supports Carbons (I think this is less confusing than adding a setting to the account's preferences that many servers won't support), allowing the user to toggle carbons on or off (if it had previously been set to on, it will enable it automatically when logging in).

The XEP's status is still Experimental, so I don't think Pidgin will add it yet, but it's good to have the code exist, in my opinion.

UIs will still need to be updated to support it: I think many of them don't properly handle PURPLE_MESSAGE_SEND.

(I'm opening a new ticket instead of updating #14663, as that one specifically requests it for GTalk, which currently uses a custom extension to do this.)

I hadn't noticed there was a version urn:xmpp:carbons:2 of the spec, I had implemented urn:xmpp:carbons:1. I've updated it to use version :2 (not much is changed, but the hierarchy of the <forwarded> element in :1 could conflict with other future XEPs).

Thank you for great patch! After brief testing works very well with latest prosody jabber server. I think it should be included in default pidgin.

I personally think, it would be better to configure it in account settings. If you have jabber account with many ad-hoc commands available, it is hard to realize where it can be turned on. And if you have jabber server with carbons ad-hoc options enabled, you end up with 4 carbon related options in account menu. But it is minor thing.

My rationale to make it a menu item instead of a field on the account's preferences was that the possibility of enabling it depends on wether the server supports it.

I think it would be even more confusing to have a "Enable message copies" in the account's preferences which does nothing on 90% of the servers. In general the account preferences seem to be static, and anything depending on server support is added as a menu item.

This is the SINGLE MAJOR issue about which all my jabber-using friends complain about! In fact, many have jumped over to threema or G+ because of the constant message-goes-to-wrong-device madness of jabber/xmpp. And, oh what a surprise, pretty much ANY other messaging service handles this better. (usually by simply sending the message everywhere)

Please consider adding this in! It will never happen if nobody starts supporting this. It can be an optional thing which can be enabled in the preferences, but please at least have it compiled into the regular release so that a regular user can enable it without recompiling the whole Pidgin client.

It's pretty sad that in this day & age where people regularly use multiple devices (desktop/laptop/tablet/mobile phone/etc) to communicate, that pidgin still doesn't support carbons. The patch is done, can we get someone to look at it and incorporate it so that users don't need to recompile from source just for this feature?

I can't tell you how many times I (unknowingly) get a message on the wrong device. It's a very annoying situation and I know many users would be very appreciative if pidgin supported carbons. I've got to think that at least some of the people involved with the project have been burned by a message going to their phone or PC when they were using the other device.

at least some of the people involved with the project have been burned by a message going to their phone or PC when they were using the other device.

They all seem to use Facebook, Google Talk and Skype.

Fair enough, but when a patch has already been written for you, what's the hold up?

that pidgin still doesn't support carbons

That is why I am still on Gajim 0.16-rc1.

I've thought about switching to something else, but in my situation I've got limited options. My workplace uses Lotus Notes Sametime (which I wholeheartedly detest), but I use XMPP for personal communications. I need a tool that does both, and pidgin does.

Dear developers, are there any problems with this patch? Is so, please share your thoughts. The community can help.

Agreed - if you need alpha/beta testers, you know where you can find willing & eager participants.

DEVS - I don't want to sound completely ungrateful for what really is a great app, we do honestly appreciate all the hard work you have put into this project, but is there something holding up the inclusion of this patch for carbons?

I tested some more. Can we not carbon OTR messages? It doesn't make a lot of sense at the moment because we can't sync keys.

To the contrary, I think we should definitely carbon-copy OTR messages. If you don't it'd be much more likely that an OTR message ends up only at the wrong instance which can't decrypt it. The instance tag support libotr 4 should make it handle this very well.

Is there an official policy against supporting experimental XEP's in libpurple?

Also, OTR shouldn't be considered an issue. OTR makes deep assumptions about how it's going to be used and only weakly supports multiple client connections. If one is using OTR one has to expect problems when multiple clients are connected - if anything, OTR could toggle off carbons or something.

In any case I don't think that's a valid reason not to include this. XEP-0280 and XEP-0198 are essential.

The status is that this patch is mandatory for many people, none of the dev's care and it will lay around here for another 3 years.

I tried to set up an debian cross-compile environment because of this patch but the documentation seems to be out of date and trying to get it run only created an intense pain in my rear food output interface.

Is there maybe someone here that could share the windows binaries of the current vanilla pidgin with just this patch applied? Thanks a lot.

I've been going nuts for the past few weeks trying to implement Message Carbons (XEP-0280) and Message Delivery Receipts (XEP-0184; I probably shouldn't mention that one in this ticket in Pidgin Win32, but if anyone's interested, you can download a plugin from: ​https://www.assembla.com/spaces/pidgin-xmpp-receipts/documents). I didn't want to invest the time to set up a development environment. But, after setting your Dockerfile, I went ahead and set up a build environment in Debian today and built the latest version of Pidgin with Message Carbon support. Thanks for this. I owe you a beer.

I've seen other requests for a download link for Pidgin Win32 with Message Carbon support. I have placed a copy in my DropBox? and I'd be happy to publish it here, but until I know if I'm violating the licensing, I can't publish it. Please advise.

@SamWhited?: I obtained the Assembla link from a different Pidgin Ticket. I could look it up and provide it if you'd like. I did, however, download the source code and DLL and also placed them on my DropBox?.

I really hope someone can tell me that providing a DropBox? link to the Pidgin Win32 with Message Carbons DOES NOT violate any licensing issues. I'd really like to share it with anyone that wants it. Before building it, I spent a fair amount of time trying to see if anyone had built it. All I was able to find were Linux versions that people had built. For my own purposes, I'll probably build it each time a new release of 2.10.x is released, so I don't mind updating my DropBox? with it.

I've been looking for a good XMPP client for Android that supports Message Carbons. Each one is lacking in one way or another either crashes occasionally or loses its connection to my Prosody server and won't connect without manual intervention. The most reliable XMPP client for Android I've found is XABBER which doesn't support Message Carbons. However, the devs seemed to have abandoned it. Fortunately, someone put together a PULL request (like this one for Pidgin) which adds Message Carbons. I built the APK which includes this support. So, now Pidgin + Xabber + Prosody gives me message carbons across Windows, Linux and Android.

I'd be happy to hand-off the binaries for Pidgin and Xabber to anyone who wants to make them available to those that needs Message Carbons + Message Receipts.

I am currently in the process of setting up a suitable build environment for building pidgin, so I will be more than happy to attempt a build on my own when I get an opportunity. I would however be very grateful if someone could profide a recent libpurple dll with the patches applied. Thanks.

There is GUI for this, there's a "Enable Message Copies" in the account's menu if your server supports it.

I disagree that it should simply be on all the time, there are many people with limited and expensive bandwidth.

I use jabber on my phone a lot with "Conversations" and it cost next to no traffic. I really wouldn't worry about the couple of extra bytes. I use ~5MB a month for jabber and it is my primary text app. Just my 2ct.

Whilst technically correct, I've found the use of serv_got_im(..., PURPLE_MESSAGE_SEND) isn't well supported by UI, and other prpl's will use purple_write_conversation() instead. In Pidgin in particular the use of _write_conversation() will colour the text in Blue as if it were sent from the client and won't trigger the 'outgoing IM' sound. In Adium, the message will be displayed (as opposed to using serv_got_im() which will not display the message at all).

In a semi-unrelated note, has anyone tried turning this into a plugin instead?

Whilst technically correct, I've found the use of serv_got_im(..., PURPLE_MESSAGE_SEND) isn't well supported by UI, and other prpl's will use purple_write_conversation() instead. In Pidgin in particular the use of _write_conversation() will colour the text in Blue as if it were sent from the client and won't trigger the 'outgoing IM' sound. In Adium, the message will be displayed (as opposed to using serv_got_im() which will not display the message at all).

The only difference I see between calling serv_got_im and purple_conv_im_write directly appears to be that serv_got_im fires a couple of signals ("blocked-im-msg", "receiving-im-msg" and "received-im-msg") and that serv_got_im (​server.c:554) sets:

/*
* XXX: Should we be setting this here, or relying on prpls to set it?
*/
flags |= PURPLE_MESSAGE_RECV;

Now I think a message with flags PURPLE_MESSAGE_RECV | PURPLE_MESSAGE_SEND makes sense (it's a message that was sent by you, but you also received it). But if some UIs can't handle this, then maybe the flags |= PURPLE_MESSAGE_RECV line should be removed? I think the effect would be the same, and it wouldn't require API-hacks.

How did you test this in Adium? This patch has been applied to Adium 1.6hg for a while (with some minor modifications to the UI), and there it seems to work fine.

In a semi-unrelated note, has anyone tried turning this into a plugin instead?

I confirm the need for better Message Carbons support in the case of OTR. At the moment, OTR messages from Pidgin are delivered to all clients (Gajim + Conversations in my case), and some notification noise ensues. Apparently due to carbons not being disabled for OTR messages at the sender [0]. There is some more rationale about preventing Carbon on OTR messages in the Conversations wiki [1].

Download in other formats:

All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!