[Standards] Decloaking and Temporary Subscriptions

Matthew Wild mwild1 at gmail.com
Wed Jan 20 20:30:53 UTC 2010

2010/1/20 Dave Cridland <dave at cridland.net>:
> Simon McVittie has made a proposal he's called decloaking, which effectively
> puts a bit of structure around the directed presence used to "back up"
> various client-client interactions, including Jingle calls and file
> transfers.
> As part of the discussion, a brief mention was made of an alternate
> approach, which I'll call Temporary Subscriptions - that is, actual roster
> subscriptions which are by intent expected to be later removed.

The actual semantics of temporary subscriptions are still up for
definition too. As I mentioned in the meeting, I'm thinking that we
just need a way to send direct presence but with a tag saying to my
server to keep the remote JID updated as my presence changes (not like
directed presence behaves now).

You could include this tag in your presence to MUC rooms for example,
and the server would automatically send the MUCs your new presence
when it changes - currently this is sent individually to each MUC room
by the clients (ick.). Though MUCs want only the presence of a single
resource (not all, like Jingle does), hmm.

Downsides are that this requires server support, especially thinking
of e.g. gmail.com here. Probably other things I'm missing too.

The downsides I see to de-cloaking as it stands is that to make it
secure the user would have to be prompted before revealing status. If
this prompt comes up at several of my clients at the same time, am I
likely to ok them all before the remote party decides I'm not there,
or selects the wrong resource?


More information about the Standards mailing list