Carbons doesn't seem to work from one Pidgin instance to another

[rrthomas]

I have Pidgin installed much the same on two Ubuntu machines (2.14.10), and have Carbons installed and activated on both. Carbons only seems to work reliably with one running instance of Pidgin; if I have two, then one of them gets all messages "carboned" from Snikket, but the other doesn't, and neither seems reliably to get messages I send on the other.

Any hints on what I might be doing wrong?

Thanks very much for this plugin and lurch, which together make Pidgin work much better with Snikket.

[gkdr]

hi, thank you for your report.

you mean both pidgin instances are running at the same time, right? could you copy the raw xml messages from the debug log of the instance which does not (visibly) receive the messages it should?

if you quit pidgin while the debug window is open, pidgin will start with the debug window open the next time. so you could also check if the feature discovery + activation works.

this is a simple protocol and it has been pretty stable, but sometimes servers change or mangle their replies. i don't really know snikket, do happen to know which server software it uses?

Thanks very much for this plugin and lurch, which together make Pidgin work much better with Snikket.

thank you, i appreciate that 🙂

[rrthomas]

I'm sorry I've not found time to respond yet: having found various problems with Pidgin and modern XMPP, I switched to Gajim. But I would like Pidgin to improve, so I will find time to get those debug logs!

I can tell you one thing: Snikket is just a repackaging of Prosody (server) and Conversations (Android client).

[gkdr]

thank you!

there was in issue with a specific prosody version in the past, however i doubt that snikket would use such an old version on purpose.

[rrthomas]

Here's a received XML stanza that does not cause a message to display:

20:08:37) jabber: Recv (ssl)(2498): <message type='chat' to='[email protected]/_WdAhts7tpQ9' from='[email protected]'><sent xmlns='urn:xmpp:carbons:2'><forwarded xmlns='urn:xmpp:forward:0'><message to='[email protected]/Snikket.sB-P' xmlns='jabber:client' id='purplea02776e4' xml:lang='en' type='chat' from='[email protected]/oKGJ-6ueo7DJ'><active xmlns='http://jabber.org/protocol/chatstates'/><encrypted xmlns='eu.siacs.conversations.axolotl'><header sid='775194703'><key rid='12192'>MwixoeIEEiEFZLZqXLJn3zuXBQ+1LpjrXXGQIGx2CvpW1xVWzTz6wTUaIQW0EUNuZEN4m4GJcXKAoVmg8vBwnEvPOuY/iednu3KPfyJiMwohBSlGezCAQ/UEyaBRmJt9UIUilutxIE/al6eYMK/K2OpEEAUYACIwmsMl99ee9qwn1JKq9UwZNPXwGgitbZk0gfQxSFdLI9mgh1yyi3ybEsRKjZ3MGEm3h/kGWAJvfCgoz5DS8QIw/PkD</key><key rid='305807645'>MwjU1IiuAhIhBZH9lEn2PWkQ+TYPplaM3oyvmtvq1n57wuIX1alOsaETGiEFtBFDbmRDeJuBiXFygKFZoPLwcJxLzzrmP4nnZ7tyj38iYjMKIQW4vqk8gt+VDUNOLWYaDvyKTAneMGpIlWMT0+4/obWIcRAFGAAiMD2y2zyHNm/IAL9gJZhFI7neNgT0iOThbu0rfBml/ZZ1XL6+nhbCx5jvMb1tAflYOKc2hE/tVy7qKM+Q0vECMIb8hRw=</key><key rid='1151725020'>MwhQEiEF5hPKsls5R83lv2a/Mi1Rf2Kg8hSEWLLKoP5kQv97jz0aIQW0EUNuZEN4m4GJcXKAoVmg8vBwnEvPOuY/iednu3KPfyJiMwohBSe9nrClGFeIWDsDwPFviKGkV4RL055bIt78UVCnOydBEAUYACIwVwUBX4uIQcFr9faNQj3n03LVaU9Ml81zZmkmt9VrIqFYErbmnKNxGsGgn7SiH4imisDQm2ZQLIEoz5DS8QIwAQ==</key><key rid='1270443444'>MwohBSaZHwEV7oIFFuqdWoOKuMu9y5aOgM/rsOjqTi66kH89EA4YACIwN/JSjG6AhGT527zdISzwXXpXIJs5AOX1oAi7YTDLMZgpi0DqOVpPgmdAlYm8iBJxLB1/u5Tct0w=</key><key rid='1370957859'>MwjZmrwBEiEFN0SJCLWSo/AvzY35SAiZrGWYTam8ftzMISKFVnk7TjEaIQW0EUNuZEN4m4GJcXKAoVmg8vBwnEvPOuY/iednu3KPfyJiMwohBXpI/2XwONrXKl/kOpAIVub/gYw97DEw+CrWneEmxpRuEAUYACIwzhUUdEZsmTkItpK5roc8rJw6vUVvXMuR2aMPCCgQqZTU0U8zm9RODSK/BCt7EvUI3W+t/nZUoXsoz5DS8QIwv8wD</key><key rid='978244675'>MwjKx/cDEiEFZ2dKTvOz5tOMjC/Rt2yWUlANBDvc0Jo5OqjA+EGVyw8aIQW0EUNuZEN4m4GJcXKAoVmg8vBwnEvPOuY/iednu3KPfyJiMwohBUwg8yfH1P9qcXGp6ud3+5N8IGhzsKMgjc0tvfn48JhCEAUYACIwjCd7ZapK6i/v2HLfEDkIE6Q6bbOGrCXFGx3WYCCaaKZTHGS784hqiZQRyXmZxYUsmaS4qYEYDxkoz5DS8QIw7LgD</key><key rid='1743046599'>MwohBVqvtHKKiqwYhVufT2c74PVfm9nHoWd7UoDpLq8J/M8LEAEYACIwaCVcKtEpQjqKZafPBPc2ggqBHeCXRLFRlBqYNCl+XLunpWCKFdQlKC3550SUogCKys6iXqDuZO0=</key><iv>od4SwJwg/Ys2boeH</iv></header><payload>ButTsA==</payload></encrypted><encryption name='OMEMO' xmlns='urn:xmpp:eme:0' namespace='eu.siacs.conversations.axolotl'/><store xmlns='urn:xmpp:hints'/><stanza-id id='qJTOEO-sboUj1vuWOR39UB9U' xmlns='urn:xmpp:sid:0' by='[email protected]'/></message></forwarded></sent></message><r xmlns='urn:xmpp:sm:3'/>

[rrthomas]

Prosody version says (unhelpfully): Snikket release beta.20220119.2

As far as I can tell from the scripts that build Snikket's docker image, it uses the nightly build of Prosody current on the relevant day, which for the date above is somewhere around 0.11.1 to 0.11.2.

[rrthomas]

I captured a debug log from starting up Pidgin with the Debug window open, and it says "Successfully activated carbons". Is there anything else you need to know on that front?

[nPHYN1T3]

This kinda feels like a necrobump but it's still open and still an issue. Server is ejabbered (because of the previously mentioned issues with prosody). Everything works fine with gajim but pidgin still refuses to work. I was just testing pidgin + this again because while gajim works it's become a monstrosity of preschool colors and obnoxious screen wasting UI.

Running with pidgin -d I get
(01:04:12) carbons: Received carbon copy of a sent message.
(01:04:12) carbons: Invalid sender: [email protected] (should be: [email protected])
(01:04:12) carbons: Ignoring carbon copy of sent message with invalid sender.

Some pedantic posix something else that starts with p... ;p

[gkdr]

Hey @nPHYN1T3, thanks for your comment!
Wow, interesting this didn't pop up more often. This is a feature implementing the security considerations part of the spec, but apparently not quite right! I checked the JID spec and it it does seem like among other things, every letter should be mapped to its lowercase equivalent for comparisons. Since this is UTF-8 I'll have to check how to correctly do it, and should probably add the other rules as well.

[nPHYN1T3]

Well hopefully you can wrangle things. This ticket's 2 years running but more so the fact pidgin still doesn't do this natively has been a real issue for far longer. (I was using pidgin before it was pidgin [gAim]) Back in the day barely anyone had more than one device so it wasn't really a big deal, but once everyone had a Desktop(s), Laptop(s), Cell, Tablet the fact pidgin still couldn't keep things straight against each device made Pidgin...well worthless. It would be nice to ditch the "Duplo Block" Gajim and go back to Pidgin.

[gkdr]

@nPHYN1T3 would it be possible for you to build the fix from the PR in #49 and confirm that it works?

[nPHYN1T3]

Build fails on Arch despite having the dependencies so I had to dig out a Debian based vm. Well that was a chit ton of rigamarole for it to not work heh. Nothing in the debug output this time either. I'm not sure if it matters (it shouldn't) but the other party being messaged was offline (no one is on/up ATM). Gajim sees all messages sent either way where as the messages sent from Gajim don't show in Pidgin and the nothing in the logs. Debug shows carbons is loaded.

[nPHYN1T3]

I set up a few test accounts to "test" the offline curiosity. I got something in the debug but no message as expected.

(07:07:29) jabber: Recv (ssl)(502): <message xml:lang='en' to='[email protected]' from='[email protected]/gajim.978FDQCB' type='chat' id='c984c633-9bb1-4389-bd77-6e6d0c24231c'><archived by='[email protected]' id='1725282449414714' xmlns='urn:xmpp:mam:tmp'/><stanza-id by='[email protected]' id='1725282449414714' xmlns='urn:xmpp:sid:0'/><received xmlns='urn:xmpp:receipts' id='752c9950-eefe-4a90-b8ff-73c0fb7f47ee'/><store xmlns='urn:xmpp:hints'/><origin-id xmlns='urn:xmpp:sid:0' id='c984c633-9bb1-4389-bd77-6e6d0c24231c'/></message>
(07:07:29) jabber: Recv (ssl)(26): <r xmlns='urn:xmpp:sm:3'/>
(07:07:29) jabber: Sending (ssl) ([email protected]/6313730899742083725927108): <a xmlns='urn:xmpp:sm:3' h='47'/>

[gkdr]

Thanks for the effort. I do think that it could matter that the recipient is offline. What you received is a MAM message (judging by the xmlns of that element), and Pidgin can't parse those. The server probably stores it in the message archive instead of sending it, as the recipient is not online, and that might be why it shows up in Gajim (which can probably parse these). Is it possible to test it with a recipient who is online?

Sorry, I know XMPP support for Pidgin is a mess. With the next major version of Pidgin that is coming up, the protocol support has to be reimplemented, which might be a chance to handle XMPP extensions in a better way. Currently it would mean yet another plugin for MAM. Would you be interested in using that?

[nPHYN1T3]

That is online. My first message I tested with one of my normal contacts, but as I said, everyone was offline/away. So I made some test accounts so I could test with everyone online. The debug message above in the second message is from the "everyone online" test.

[gkdr]

Oh, thanks for clarifying. Well I am not sure what to say then, the server seems to not be sending the messages. Could you check the debug log during connection establishment for something like Found carbons in server features, sending enable request ?

The plugin can only handle messages it receives, so unless you see a <received xmlns='urn:xmpp:carbons:2'> or <sent xmlns='urn:xmpp:carbons:2'> in the raw XML of the XMPP messages you receive, there is nothing to parse.
For instance, in the debug log you posted above that gave me the idea for the fix, it said:

(01:04:12) carbons: Received carbon copy of a sent message.

[nPHYN1T3]

When pidgin is started with debug the only mentions of carbons are:
(17:54:04) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/carbons.so

(17:54:04) jabber: Recv (ssl)(3823): <iq xml:lang='en' to='[email protected]/1129218158185580434316130' from='doughmain.com' type='result' id='purpleabe94b5a'> ... <feature var='urn:xmpp:carbons:2'/><feature var='urn:xmpp:carbons:rules:0'/> ... </iq>

[gkdr]

That's weird. Is it still active after you recompiled it? Or is there maybe in error in the plugin list? It should at least log some things during startup, e.g. "Sent feature discovery request" to see if the server it is connected to even supports carbons.

[nPHYN1T3]

Nope nothing like that in the debug output. The only thing that even slightly matches on the word "request" is about xmpp-stanzas. i.e. no plugin seems to be querying if a feature is or isn't enabled/available, at least not with the string example you've mentioned.

What do you mean "still active after I built it?"

There is no error, as I showed above it says it's loading the plugin:
(17:54:04) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/carbons.so

[gkdr]

Every line it logs should be preceded by "carbons" for easy filtering.

What do you mean "still active after I built it?"

If I got it right, you are trying out the bugfix I tried to implement (thanks!). So you must have built and installed the plugin. I am wondering if it e.g. is still active in the plugin list.

There is no error, as I showed above it says it's loading the plugin:
(17:54:04) plugins: probing /usr/lib/x86_64-linux-gnu/purple-2/carbons.so

IIRC that just means it found the file. There might still be an error with the plugin, e.g. it could be greyed out in the list.

[nPHYN1T3]

Nope you caught it. Seems between the pre-built binary and rebuilding with the src pidgin had disabled carbons from the list. I didn't even think to check it because well...hell it was already installed and enabled.

Double checking the plugin list and re-enabling it it does in fact seem as though the new build is working. Hazzah!

[gkdr]

Awesome, thanks for your help! Guess I'll get out the first release in almost 4 years soon :D

[nPHYN1T3]

Heh well neato! ;) Sadly though now I gotta figure out why it fails to build on Arch. Though I suppose I could just be lazy and wait for the Aur to update it...IF they update it heh.

[gkdr]

That is weird, this small plugin barely has any dependencies. If you want, you could open a separate issue about the build failure and we can figure it out there.

[nPHYN1T3]

Your call. I'm just firing up the VM I initially tried to build it with to refresh myself on what the issue was. It complains about not finding glib.h which is installed in /usr/include/glib-2.0/glib.h.

P.S. Thanks for revisiting this issue.

P.P.S. Built fine on my workstation so I'm guessing something stupid in the build environment on the VM install.