private messages originating in jabber chat rooms are slightly broken

[penny@…]

when someone sends me a private message out of a chat room, it starts a new query with their id set to username@whatever/something - not sure where the "something" part comes from, it's often /work.

I see their message fine but when i reply in the new window, I get a no such user error. This happens even if they're on my contacts (without the /work part of their id) - so I have to go back to control and start a new query with them in order to be able to reply.

Obviously this doesn't work at all (meaning I can't reply) when they're not on my contact list - I then have to go to control and add them a start a new query to be able to reply in that case.

this is 1.2.5 (not an option in version-select)

[anonymous]

sorry, that's irssi-0.8.10 and I just realised -5 (not .5) in my bitlbee version was part of the debian version string, not bitlbee's.

[wilmer]

Ah, heh, that clears up some confusion. :-) CAn you see if 1.2.3 has the same problem? I may have fixed this in 1.2.1 (and everyone should be using 1.2.3 anyway because of the hijacking bug), not sure.

[penny@…]

No, but I've further narrowed down the problem.

They message me and it has the /something I reply in the new window, it says "user is offline" This actually gets to them, but it arrives in a different window in *THEIR* client (psi in the most recent case) They reply in the new window Their reply starts a new query window with me, without the /something We can talk normally in this new window

[anonymous]

Wow, line breaks got eaten. Sorry, that makes that kind of hard to read.

[anonymous]

In the u@h/r format, the "r" bit is called the "resource." It is a way of grouping several related things together by the "u@h" part. This gives the protocol a way of delivering messages generally to "u@h" in general or a fully-qualified "u@h/r" in specific.

Behind the scenes, each registered resource has a numeric priority. This is used when delivering to a "u@h" without the resource bit. For example, say the following are registered:

• u@h/larry (priority 10)
• u@h/curly (priority 300)
• u@h/moe (priority 0)

If a message is sent to "u@h", the "u@h/curly" registrant should receive it because it has the highest priority. The only way that the other two names will receive messages is if they are addressed directly (e.g. as "u@h/moe") or if the higher priority registrants log out (e.g. if "u@h/curly" logs out, then messages sent to "u@h" [without the resource bit] will go to "u@h/larry" as the highest remaining priority).

Sounds like bitlbee is trying to do the right thing -- if someone writes to you as "u@h/r", you want to respond to the same exact resource.

[Wilmer van der Gaast <wilmer@…>]

Hello,

Yes, that's what it does, and there's a setting to change the behaviour to send messages to the last resource that talked to you. But I'm a bit confused by your bug report, what's the exact breakage?

Sorry if maybe I just misread your report.

[penny@…]

Hey - sorry, two anonymous users posting here - I'm the original reporter.

The breakage is that when I get a message from a user with a /r, and reply in the new query window, I get the 'user is offline' error, even though it goes through to them (but in a *new* query window to the one they opened when messaging me originally). They then reply to me in their second window, which spawns another new window for me.

Summary: it should be two new query windows, one per user, and no 'user is offline' error. Instead it's four query windows (two each) and the error.

Maybe it's correct behaviour (certainly could be, I don't know much about jabber and it sounds in the explanation above as though it might well be that way) but it seems a bit weird at least to be getting the 'user is offline' error, even if the four windows are correct.

Hope that clarifies :)

[wilmer]

Hmm, oh, wait, so this is in non-anonymous Jabber chat rooms? When people start a chat with you from there? Hmm, this is starting to make sense. I think I should make BitlBee treat anonymous and non-anonymous chatrooms equally. The underscores are ugly, but issues like this keep coming up and are uglier.

[penny@…]

I'm not sure what the difference is between anonymous and non anonymous chat rooms in jabber, sorry! :( Is there a way to query the chat room settings from within bitlbee?

[wilmer]

In anonymous chatrooms you can't find out a person's real Jabber JID, while in non-anonymous ones you can. In those, BitlBee uses the same nicknames for persons as it does in &bitlbee, while in anonymous ones it generates unique nicknames for everyone.

So one way to see it is by seeing if there are nicknames with underscores in the channel.

[anonymous]

Right. There seems to be a mix of nicknames with underscores at the end and not... that maybe corresponds to people with underscores NOT being in my contact list. Does that help ?

[wilmer]

Hmm, how odd. That sounds more like an anonymous room.

And still, when someone opens a query with you, you see their real Jabber ID and not roomname@confserver/nickname (or, actually, nickname=roomname@confserver) ?

[penny@…]

Yep.

It may be that I've only tested with people in my contact list as well though. I can't test this right now as all the people there with underscores after their name (who aren't on my contact list) are asleep in NZ :)

[dx]

The issues mentioned here don't seem to apply anymore in bitlbee 3.x. At least in the case of non-anonymous we already reuse the real JIDs. If they are anonymous channels there's nothing we can do about it being a different JID.