powered by Jive Software

Blocking a contact

I need to figure out how blocking a contact should be handled by the client and server. From what I’'ve seen in other clients, they merely block messages from clients, but do not actually make themselves invisible to these clients.

Using the alpha server, I tried sending a to make myself invisible to user B. This actually worked, and I appeared offline to user B, but online to all other users. However, I think this would break if I were to change my availability status to “away” or something, as the server probably would send a presence packet to user B saying I’‘m online but “away”. I haven’‘t actually tested this yet, so I’'m not sure.

I did test the following though. With user B thinking I’‘m offline, I got user B to send a message to user A (since offline messages are permitted). The server forwarded this message to user A, since it knows it’'s actually online. This may be something my client should handle: blocking messages from contacts that are blocked in my contact list.

I’'d like to know your views on how this should be handled…

Also I’'d like to know your view on how to have a client “Appear Offline” like in MSN Messenger…

Unfortunately, there is no way in the standard Jabber protocols to allow the server-side blocking of users.

There is a draft standard JEP-0016 (Server-Based Privacy Rules) which does allow a user to assert black lists and white lists:


It’‘s at draft standard right now which means it’'s pretty well established but not entirely stable (may change in the future) and as such, it is not recommended for mission-critical or large scale use.

At the current time, what you’‘re doing (sending presence directly to users on the roster) is pretty much the only standard method available. In essence, you don’‘t rely on the server to manage presence for you (don’‘t send presence to the server without a ‘‘to’’ attribute except the initial available presence to tell the server you’'re online). Instead, you manually update everyone on your roster with the presence you want them to see.

Messages will need to be silently dropped by the client if it comes from a blocked address.

So essentially the client does all the blocking and updating instead of the server.

Having said all that, we plan on supporting JEP-0016 in the future. If this is a critical feature for you we can bump the priority up (although I can’'t guarantee it being in the 1.0 release).

I will likely avoid implementing blocking at all, because without server-side support, it’'s not very robust. For example, say I block a contact by sending the presence packet to it. The contact can just sign off, and then sign in again, and the server will notify the contact that I am indeed online.

I wouldn’'t consider this a critical feature since the server would be deployed in a closed environment. Thanks for the info though.

I found that JEP-0018 deals with blocking and invisibility. I’'m not sure of the status of this JEP however; maybe you can enlighten me.


Snippet from JEP-0018:

  1. Invisibility


If it is sent when the client was previously available, the server automatically processes a first. When first received from the client, the server will only perform a probe, and will not broadcast or store this presence. The priority element is also processed and the server will route to the client incoming presence and messages as with available presence. The client may still send available presence to any jid individually to expose their presence to single users.


Routed to the jid just like a message (a client may choose to send this to a transport or other service that supports invisible mode, when these are received by the server for a local user, they are interpreted as unavailable presence and the type is set to unavailable to show the sending jid is offline). If the jid is one that would also receive a broadcast (has a subscription to the users presence), the server will no longer send any broadcasts to this jid (until the client either goes unavailable or sends that jid an available presence).

To understand the rules of the JEP process read


The status of each jep is noted in it’'s listing on the jep list:


In this case, the 0018 proposal is ‘‘experimental’’ which means it’‘s really just something someone is proposing but hasn’'t had any real review or acceptance.

Having said that, there is experimental support for invisible presence status in our XMPP server. I don’‘t think it’‘s really working properly but you can try it out and see (I haven’‘t been working on it to make it consistent with JEP-0018 behavior). I wouldn’'t call it true blocking but it may help do what you want.