Not rejoining groups in pidgin even when autojoin-chats is configured

[Juliaria08]

It seems like the plugin isn't telling pidgin that it rejoined the groups. Even when autojoin-chats is enabled.

Is there any way I can help debug?

[hoehermann]

Thank you for the report.

Is there any way I can help debug?

You can start Pidgin with debug output by supplying -d on the command line. Alternatively, you can disable the WhatsApp account, open Pidgin's debug window, filter for whatsmeow and then re-enable the account. You can remove sensitive information and paste the output here or send it via email to github@hehoe.de.

For me, this feature is working as intended. Please note that WhatsApp and Pidgin have a different understanding of what "joining" means:
In WhatsApp, you can join a group. Then you are a participant of that group. You receive messages sent to that group even if you are currently offline.
Pidgin does not really know groups. Pidgin knows conversations in two flavours: Instant "direct" message and chat. A conversation window is opened when you join the chat. If you close the conversation window, you automatically leave the chat. You will no longer receive messages sent to the chat.
Obviously, the Pidgin behaviour does not play well with WhatsApp. You do not actually want to leave the WhatsApp group when you close the Pidgin window. That is why this plug-in never leaves the group and does not open up the conversation window by default. The setting only affects opening the windows explicitly – which allegedly is relevant to bitlbee and/or Spectrum. Entering or leaving the WhatsApp group is not actually implemented in the plug-in. For group administration, you need to make use of the official client.

I hope this helps.

[Juliaria08]

Thanks, Because pidgin was made to implement XMPP or IRC, where leaving actually leaves. And in WhatsApp if you leave it's harder to join again (you've got to be invited).

I enabled the option that's supposed to tell pidgin, hey you're in this group, but it seems to not be working. I've restarted pidgin with that flag, and will later read the logs when the behavior happens again. (it usually happens to me overnight)

Thanks for making the plugin.

Offtopic:

I don't know if leaving is the same in pidgin or in libpurple, but I think they're implemented the same. Right? And I guess pidgin would consider messages to something like this (in XMPP land): tilde.green@muc.tilde.green/jmjl as if it were a "direct" message right? And reading the docs you wrote that if the plugin tells pidgin that the user's offline they can't be sent a message probably also because of how xmpp was implemented right?

[hoehermann]

I received the log via mail. Thank you for your trust. In the debug output, this message occurrs:

whatsmeow: [Client] Unknown element in group node xxxx@g.us: <membership_approval_mode><group_join state="on"/></membership_approval_mode>

This is an error within the library I am using. It looks like it has already been reported as issue https://github.com/tulir/whatsmeow/issues/401. There is not much I can do about it, I am afraid. Due to the error, the information about the entire group seems to be discarded. If it was working, a line like this would appear:

whatsmeow: recieved group (subtype 0) for account 0x56311352d590 remote xxxx@g.us

---

I don't know if leaving is the same in pidgin or in libpurple, but I think they're implemented the same.

In my opinion, Pidgin is the default frontend to libpurple. Consequently, they should agree on how stuff should be done. For this reason, I speak of Pidgin and libpurple as one thing. You are correct: Leaving a chat sends a control message to the server in virtually all protocols (IRC, XMPP, WhatsApp,…). However, in IRC and XMPP, we can re-join chats without an invitation. In WhatsApp we need an invitation, thus we do not want to leave the group giddily. There even is an option to disable leaving the chat when closing the Pidgin conversation window, but I do not want to find out how that works for other front-ends such as Gaijm, Spectrum or bitlbee.

I guess pidgin would consider messages to something like this (…) as if it were a "direct" message

Unfortunately, no. Pidgin uses almost completely distinct functions to handle "direct" and "chat" messages, respectively. The username actually does not matter. That is why I need to have a flag "is_group" in multiple places in the code so I know which function to use for handling a particular message.

Internally, WhatsApp seems to use at least two different servers: s.whatsapp.net for single conversations (usernames follow the 0000000@s.whatsapp.net pattern), g.us for group chats (group identifiers follow the 0000000@g.us pattern). However, this has not always been the case: Identifiers once contained phone numbers and dashes, now they are strictly numerical except when they are not, and there is a couple of different servers I know nothing about.

reading the docs you wrote that if the plugin tells pidgin that the user's offline they can't be sent a message probably also because of how xmpp was implemented

I am not perfectly sure about the history of Pidgin, but I suspect that is the case. In ancient days, you would not expect a server to store your messages. You could only communicate if both parties (sender and receiver) were online at the same time (much like a phone call). Storing messages was an optional feature, see https://xmpp.org/extensions/xep-0013.html.

[Juliaria08]

I received the log via mail. Thank you for your trust. In the debug output, this message occurrs:

No problem.

whatsmeow: [Client] Unknown element in group node xxxx@g.us: <membership_approval_mode><group_join state="on"/></membership_approval_mode>

This is an error within the library I am using. It looks like it has already been reported as issue tulir/whatsmeow#401. There is not much I can do about it, I am afraid. Due to the error, the information about the entire group seems to be discarded. If it was working, a line like this would appear:

Ok, then I'll wait :)

[hoehermann]

I looked at your mail again (after a night of sleep) and noticed I was mistaken. The message is only a warning, the group information is not discarded. whatsmeow is not at fault. However, the rest of the debug output is not very helpful. Can you build from https://github.com/hoehermann/purple-gowhatsapp/tree/dev? I added some more debug prints in that branch.

[Juliaria08]

Ok, I'll rerun it from that code, I'm compiling it now, and I'll send you the email with the new debug output tomorrow or next day.

If you could tell me if you only want the new debug lines or also the other lines, (as if you're going to only want those I can remove the other lines, I understand you only want debug lines added from commit e1bb3afd0036516eb61f04ac1fc80b6aaeaa2d71, right?) it'd be appreciated, that way, I take less time filtering the full log. But I can filter it fully if you want the full log.

[hoehermann]

Providing only the added lines should be sufficient. Plus the output from gowhatsapp_process_message (so I can infer the context). It would be reasonable to put a marker into those outputs ant the select them via grep or something. :)

[Juliaria08]

Providing only the added lines should be sufficient. Plus the output from gowhatsapp_process_message (so I can infer the context). It would be reasonable to put a marker into those outputs ant the select them via grep or something. :)

Sent you an email :). If you want, I can recompile another version with a marker for me to grep easily, but those logs had to be hand selected. (I've also tried to find a entry which has the same problem, and handpick it's data, which seems to be a bit difficult), is there a way for me to add some kind of IF check so only group id 123456789@g.us (example) would log those messages with the marker for the gowhatsapp_enter_group_chat() function? (the other functions seem to properly say the group id, or the memory address where it is, which means finding it is easier, but that one doesn't give me any info about what group called it, which makes it hard to identify what called it, I think?

[hoehermann]

Thank you for the debug output. The lines with

Conversation for group …@g.us is 0x556a6a0e26e0.

indicate that Pidgin believes that the conversation is already active. For this reason, no new window is created. I think, I have seen this particular behaviour somewhere, but I cannot recall the exact details from the top of my head. It might be some obscure setting and/or side-effect of another plug-in. Also it may be useful to ask around in the Pidgin Discord server.

The next two weeks, I want to focus on other projects, but I want to pick this up again later.

Update: I just remembered a setting. Can you make sure that in the buddy list the "persistent" option is not set on the chat? That setting allows a chat to be "joined and active" while its window is not actually being shown to the user.

[Juliaria08]

Yep, that option seems to be set. I'll go one by one and remove them. Edit: But it's only set on some of the groups, and the issue seemed to happen on all.

[hoehermann]

Does removing the "persistent" setting improve the situation?

[Juliaria08]

Does removing the "persistent" setting improve the situation?

We'll see tomorrow, as every time I restart pidgin the issue seems to disappear, and appears after a disconnection.

[Juliaria08]

Does removing the "persistent" setting improve the situation?

No, it still seems to have the same behavior. I'll send you more logs from this time when I get to clean them up.

Edit: I think the behavior will happen again this night so I'll clean new logs tomorrow and I've made a build that helps me clean the logs up faster.

[Juliaria08]

Yes, it's been happening every time pidgin disconnects and reconnects from whatsapp's servers, maybe adding a "hotfix" to not tell pidgin about those disconnections? (which seems to happen every night)

[hoehermann]

For the general audience, I do not think this will be a good idea since the user could not tell whether the connection was active or not.

Do you build this plug-in yourself? You can take a look into src/go/handler.go. In the sections handling the Disconnected and StreamReplaced events, you may replace the purple_error with a call to log.Warnf(…) and handler.client.Connect(). I have no idea how that will affect the operations since it would do a new connection on a dirty state, but feel free to go ahead.

[Juliaria08]

For the general audience, I do not think this will be a good idea since the user could not tell whether the connection was active or not.

Do you build this plug-in yourself? You can take a look into src/go/handler.go. In the sections handling the Disconnected and StreamReplaced events, you may replace the purple_error with a call to log.Warnf(…) and handler.client.Connect(). I have no idea how that will affect the operations since it would do a new connection on a dirty state, but feel free to go ahead.

I built it to debug, and I had before because it was the easiest way to install it.

I've noticed that if I tell pidgin to leave the room and then join it, it appears to rejoin it, and I'm able to speak in the chatrooms, but leaving (closing the tab) seems to move the tab, which is a bit annoying, so I guess maybe adding an option to tell pidgin to leave and rejoin but maybe that's not possible?

[hoehermann]

Thank you for staying on this topic with me for so long. I am using separate windows, not the tabs. Hence I did not notice what behaviour you were experiencing. I think I understood and reproduced the issue. It turns out that Pidgin sets a special flag I apparently need to check. This is now implemented in https://github.com/hoehermann/purple-gowhatsapp/commit/029d607. Does it improve the situation for you?

[Juliaria08]

Thank you for staying on this topic with me for so long.

No problem.

I am using separate windows, not the tabs. Hence I did not notice what behaviour you were experiencing. I think I understood and reproduced the issue. It turns out that Pidgin sets a special flag I apparently need to check. This is now implemented in 029d607. Does it improve the situation for you?

I've recompiled purple-gowhatsapp to commit e94ff477710b827bb4316e1f37612f8c148fa102 and I think the behaviour no longer happens (I tried to set the state to Offline and back Online, and it rejoined).

Thank you for this awesome project.

[Juliaria08]

@hoehermann I'm not sure if I should reopen this, as it causes pidgin to show the groups 2 times, like when it reconnects it creates those tabs twice in the list. (But only one of them seems to receive messages)

[hoehermann]

I could destroy the old conversation tab and create a new one, but then the tabs would be moved around. Looking at the source, all I learned is that I cannot see how this is supposed to work properly. I have to ask grim about it.

[Juliaria08]

I've noticed then it acted as if both groups were disconnected but only for some specific groups, (ie. not all of them). I guess asking grim is a good idea. (then is used here as later)

[hoehermann]

grim has not answered yet, but I took a shower and had an idea. The forced re-join mechanism clashes with the autojoin option and we end up joining twice upon reconnect. Please try again with the updated code which includes f981b24.

[Juliaria08]

grim has not answered yet, but I took a shower and had an idea. The forced re-join mechanism clashes with the autojoin option and we end up joining twice upon reconnect. Please try again with the updated code which includes f981b24.

I think that fixed it, if I see another issue related to this I'll reopen this issue.

Thanks a lot for developing such an awesome tool.