On Tuesday 05 August 2008 08:54:22 Pavel Simerda wrote:
> On Mon, 04 Aug 2008 16:59:50 -0600
>
> Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> > Right. Or XEP-0191. Effectively Google Talk (and other similar
> > services) deploy a rule of "forbid communications with people not on
> > my roster" on the user's behalf -- no need for fancy privacy rules
> > managed by the user.
>
> But this also disallows chatting with people outside your roster, which
> is something I often do.
>
> I'm for any way that doesn't leak presence but allows chat sessions (or
> single messages)... without giving any presence info. It's nice to be
> able to decide about the non-roster people blocking separately.
>
> Some people would also like to use the "invisible" facility, that would
> also be orthogonal to the roster subscriptions. (I never used
> invisible personally.)
>
> Sorry if I'm just repeating the obvious.
I've suggested using directed presence (which need not contain the same
information as broadcasted presence, if any) for this.
A related discussion is that we wanted a way to trade caps and resource
information between unsubscribed/invisible contacts. Robert suggested
sending directed presence with caps and a special field to indicate you want
to trade capabilities and reveal each others' resource name. E.g.:
<presence from='contactA/Resource' to='contactB'>
<tradewithme/>
<c ...> // caps
</presence>
I believe most clients drop unsolicited presence on the floor. What we'd need
is for clients to notice the <tradewithme> element on these stanzas as a
request to trade presence temporarily with the sender, but not necessarily
form a subscription. So your client might say, "User 'contactA' wishes to
engage in communication with you. Is this okay? [Yes/No]" If the user
selects 'Yes', then your client would reply with the same kind of presence
packet. Now, each party may determine disco information of the other, and
they can chat, do file transfers, jingle, etc.
Servers could then have a scheme where they block/bounce all communication
except from contacts that have your presence. Presence is the key word here,
not subscriptions, since if you login invisible you'd still want the bouncing
effect on subscribed contacts that you've not revealed yourself to. I think
presence is the most natural privacy control mechanism.
There's just one problem, and this was brought up at the summit: if both
parties forbid communication with people not in the roster (or, more
appropriately, forbid communication with people who don't have their
presence), then it would not be possible to trade directed presence. Oops!
IMO, for this to work we need to define some server exceptions. For example,
GTalk will let <presence type='subscribe'> packets through. We'd want to
take this a step further and let through any presence packet containing a
<tradewithme> element.
We need two new XEPs: "Temporary Presence Exchange" (for exchanging
caps/resource information with unknown/invisible entities),
and "Presence-based Privacy" (which is TPE-aware).
-Justin
