#1252 closed defect (notabug)

bitlbee should hide from listed clients when jabber/XMPP account have negative priority

Reported by: devnull@… Owned by:
Priority: major Milestone:
Component: Jabber Version: Unspecified
Keywords: Cc:
IRC client+version: Client-independent Operating System: Public server
OS version/distro:


jabber accounts with negative priority should be not receiving messages unless this device is directly contacted (by specifying full JID) and also not listed in others clients as connected client, which is common behavior.

Official server allows listing such client which leads to some missed messages due to routing messages to such device which can be not checked too often (because it shouldnt receive messages when other clients are not connected with the same jid but positive prio.

Attachments (0)

Change History (5)

comment:1 Changed at 2016-03-30T01:22:20Z by dx

I don't understand this issue. Are you saying that other contacts with negative priority should appear as offline? Are you saying that bitlbee should make itself appear offline when priority is negative?

comment:2 Changed at 2016-03-30T01:32:41Z by devnull@…

Nope. This account in bitlbee which you set to have negative priority should as you say look as offline for rest of the world.

Just try it yourself.. connect to some jabber account from two jabber clients (eg. psi 0.14 looks behaving correctly) and on one set -1 priority.. you will not see this client listed in connected "devices".

comment:3 Changed at 2016-03-30T01:45:57Z by dx

psi 0.15 sends this from account 1:

<c xmlns="" node="" ver="caps-b75d8d2b25" ext="cs ep-notify-2 html"/>

Receives this in account 2

<presence from="">
<c xmlns="" node="" ver="caps-b75d8d2b25" ext="cs ep-notify-2 html"/>

Displays it as away, not offline.

When trying to send a message to this priority -1 account the message is not delivered and an error comes from the server, which is not displayed in the psi UI, it just drops the message silently (log from the point of view of account 2)

<message type="chat" to="" id="aac7a">
<active xmlns=""/>

<message from="" type="error" id="aac7a" to="">
<error type="cancel">
<service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>

I still don't see what we're doing differently.

comment:4 Changed at 2016-04-02T21:51:56Z by dx

Ping? I still don't get what the bug is.

comment:5 Changed at 2016-04-29T22:27:34Z by dx

Resolution: notabug
Status: newclosed

Closing this since it doesn't seem like a bug, but feel free to reopen if i'm wrong.

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.