[Standards-JIG] Roster Subscription Synchronisation

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Sep 13 20:09:18 UTC 2004

On Mon, 13 Sep 2004 10:42:49 -0600, Peter Millard <pgmillard at gmail.com>  

> On Mon, 13 Sep 2004 18:19:05 +0200, Tijl Houtbeckers
> <thoutbeckers at splendo.com> wrote:
>> On Mon, 13 Sep 2004 15:30:37 +0100, Richard Dobson  
>> <richard at dobson-i.net>
>> wrote:
>> > Because JEP-0093 provides an existing way of representing a contact or
>> > list of contacts that can be transmitted between to jabber entities,
>> > this is effectively what you are trying to do, i.e. transmit a contact
>> > or list of contacts between two jabber entities, the user and the
>> > transport, it seems a perfect match to me, and several others too, ive
>> > counted at least four of us that feel this way.
>> If that's all we're trying to do it could work. However, we are not. We
>> are synchronizing subscriptions. Not just sending contacts.
> OK, I think here in lies the rub. If we have a protocol for allowing
> services to start mucking around with my roster, what prevents a SPAM
> company from creating a service, and start adding people to my roster
> and sending SPIM from them?? I am VERY opposed to anything that can
> change my roster. It's a privacy issue. I'm NOT opposed to having a
> service send me things/contacts/people that I MAY want to subscribe
> to. This is why the verbiage in the XMPP specs is the way it is. We
> need to be EXTREMELY careful about exposing any protocols which allow
> folks/services to influence rosters. Control of who/what I subscribe
> to should always be at the user's discretion. This is why I REALLY
> don't like having a transport send me any kind of subscription
> packets.

Have you read the proposal?

"If the client receives a presence subscription packet with an  
roster-subsync tag, but the originating domain is not authorised on the  
user's contact list, the client MUST ignore the roster-subsync tag, and  
treat the presence packet as normal. This prevents arbitrary Jabber users  
 from auto-authorising themselves."

Further more a client can ask for permission from the user on a  
once-per-session basis, or even for every contact for the most paranoid  
amongst us. (a Yes/No/Always/Never dialog would provide both) Yes you have  
to trust the transport that you added in your roster. For that matter, if  
you don't trust your transport the transport itself could send you spim :)

> Is this a problem of synchronizing rosters something that the
> community (not just the authors of this JEP) is interested in
> solving?? I think that the current state of affairs with transports is
> not optimal, but from what users tell me, the use case they are
> interested in solving is just import my contacts the first time.

My roster is full with "ghost" transport contacts. I find this very  
annoying. This is particulary intresting for people who still switch  
between Jabber and legacy networks. For example, using jabber on your  
mobile, and the official client (or a multiprotcol client like GAIM) at  
home. Or people who use different clients at home or at work. etc.

The use-case right now has been brought on mostly for MSN, so there the  
inserting ("both") and removal ("none") are most intresting, but gateways  
can do more than just MSN.

Of course users right now are most intrested in solving the initial import  
(which this proposal does), and I don't think most will be content with  
"just" JEP-0093 (prefering a more automated solution). It doesn't mean  
they won't like it that when they delete a contact on a legacy network  
they don't have to do it again in Jabber.

Keeping your Jabber roster in the same state as your legacy roster sounds  
like a usefull feature to me. As you can see, it's not a very complicated  
thing to implement either. Why not document such a technology in an  
informational JEP?

> They
> typically don't change clients that much. IMO, that use case is not
> something we should be optimizing for.

This solves the "initial import" just as well as any other solution I've  
heard so far, and I doubt it will take more than a few lines of code. The  
only benefit I've heard so far for sticking to JEP-0093 is some form of  
backwards compatibility for client that support jabber:x:roster already.  
Though if you use an "upgraded" JEP-0093 (in the <message/> stanza) for  
synchronization it could give some weird results for those clients.

More information about the Standards mailing list