I use exodus 9.1.0 too, but it does not support invisibility…
It has only the “send invisible” command which won’'t work because it sends custom “invisible” presence not by using the privacy and invisibility lists…
The only client i have found working with invisibility is miranda …
I found out that exodus does blocking on the client side which is totally wrong.
The content of the first packet should be stored in the database in table JIVEPRIVACYLIST.
The 2nd packet activates the list, and Wildfire does not store this as a list must be activated for each session to become active. “spamexample.com” is no longer be able to send messages to "admin@example.com/spark". But is still can send messages to admin@example.com/home.
So if you re-login or if you login with another resource you need to activate it again.
Wildifre does store the lists and there was a problem with my xmpp packets.
I would like to ask you a question about the jep that i havent understand,
if a jave activayed a list which i change later do i gave to reactivate it, or wildfire is ‘‘clever’’ to aply the changes as this list is already the active one?
which JEP are you refering to if I may ask? It’‘s within http://www.xmpp.org/specs/rfc3921.html#privacy and reading through it I’'m pretty sure that one can change (but not delete) the active list without problems.
JEP-0016 has been retracted so we’'ll hopefully not see it in Wildfire.
I’'m not sure if one will implement support for JEP-0126 as JM-747 exists for experimental “[JEP-0186|http://www.jabber.org/jeps/jep-0186.html]: Invisible Command” support.
As RFC3921 also allows to block outgoing presence notifications - which is very similar to invisibility - I really wonder why JEPs 0016, 0126 and 0186 were created.
edited: JEP-0126: “However, RFC 3921 also defines a privacy lists protocol (i.e., the ‘‘jabber:iq:privacy’’ namespace) that can be used to implement invisibility in an XMPP-compliant manner. This JEP documents how to do just that.” - so Wildfire supports JEP-0126.
I’'m not sure if one will implement support for JEP-0126 as JM-747 exists for experimental “[JEP-0186|http://www.jabber.org/jeps/jep-0186.html]: Invisible Command” support.
I’'ve implemented JEP-0186 in my client (a new Smack-based plugin for Adium).
As RFC3921 also allows to block outgoing presence notifications - which is very similar to invisibility - I really wonder why JEPs 0016, 0126 and 0186 were created.
edited: JEP-0126: “However, RFC 3921 also defines a privacy lists protocol (i.e., the ‘‘jabber:iq:privacy’’ namespace) that can be used to implement invisibility in an XMPP-compliant manner. This JEP documents how to do just that.” - so Wildfire supports JEP-0126.
Well, I chose not to implement JEP-0126, since Adium also supports block lists. When someone goes invisible, I would have to modify the active block list on the server to match both the requirements for invisibility and that original block list itself (which is kinda ambiguous by itself). If my client crashes, it would have to clean that mess up after logging in again. I decided that this is way too messy for me, and simply implemented JEP-0186, even though I don’'t know of any implementation for it.
I didn’'t knew the existanse of JEP-0186 and it is really interesting.
I have tried to implement jep126 and it is just too much!
My problem is that my client should go out on the market soon, so i really need a way to support invisibility asap.
I can see that no server haven’'t yet support for jep126 and this could be a problem.
Do you think i should go on with jep126 in order for my app to have that invisibility support or to implement jep186 and wait for the servers to support it too?
every server which fully supports RFC 3921 does also support JEP-0126. Wildfire does not yet support JEP-0186 so I’'d implement RFC 3921/JEP-0126. Looking at the JEPs one will see that “Invisibility” is for the server a little more complex than just blocking IQ and Presence packets so I wonder if one will really implement it as tracking single sessions is not really kind. Doing the work (creating the proper list) on the client saves a lot of resources on server side.
Doing the work (creating the proper list) on the client saves a lot of resources on server side.
Yes, but it requires some crazy AI on the client side to be implemented properly (taking into account the existing block list, which can be very complex).
Should people on your whitelist see you when you’'re invisible? You also have to re-arrange the order number of the existing list.
Plus, what happens when you go offline while being invisible? You will leak that list.
My basic gripe with it is, that you mess with the user’‘s data there, the block lists should be fully configurable by the user, and the application shouldn’'t be messing around with it automatically.