Privacy and messaging handles within XMPP conferences

Etan Reisner pidgin at
Wed May 21 17:16:33 EDT 2008

On Wed, May 21, 2008 at 03:54:02PM -0500, Mark Doliner wrote:
> I don't think we're going to be able to convince each other, but I definitely
> think client-side blocking should be a core part of any IM client.  I think a
> large percentage of our users benefit from client-side blocking and relegating
> it to a plugin would be a bad usability decision.  I see it as a requirement
> for our privacy support to be considered "complete."
> -Mark

You are probably right. Where we differ is that I think a protocol without
useful privacy support is the object which is incomplete and I would
rather not paper over valid protocol distinctions and limitations in
pidgin when at all avoidable. Especially when papering over them breaks
perfectly valid usage scenarios and requires further hackery to avoid said

Actually, going back to the original topic, I'm not sure I agree that a
person who says "I only want people on my buddy list to IM me" should get
messages from people they open a conversation window with if that person
is not on the buddy list, since they explicitly said they don't want to
allow that sort of thing.

I don't think this is a case many protocols need to consider because most
don't allow chat room pseudonyms, so I don't think there is any real
precedent one way or the other. I realize the apparent logic behind the
proposed change but am even more loathe to start playing "guess what the
user really meant" in terms of privacy settings than I am to do that I
would be normally.

One more thing the core privacy check can't handle is the mapping of XMPP
room real JIDs to users on the buddy list and that doesn't have a simple
solution like scanning the list of open channels.

If we are going to keep the core privacy stuff (which I imagine we will
because we already have it and I am not going to unilaterally remove it) I
think we need to add a privacy_check prpl_info function so that cases like
the above two can be handled correctly.


More information about the Devel mailing list