I remember proposing use of ad-hoc distribution lists for this purpose about
three years back (though it was not limited to presence). Rejoining last week,
I see that the discussions continue to be the same :-)
While number of stanza's in S2S connections are usually dominated by presence
broadcasts, the 'source of truth' for a contact's roster must always be the
hosting server - and not remote servers : else any distributed system breaks
down over time.
Regards,
Mridul
--- On Wed, 1/4/09, Pedro Melo <m...@simplicidade.org> wrote:
> From: Pedro Melo <m...@simplicidade.org>
> Subject: Re: [Standards] Presence distribution
> To: "XMPP Standards" <standards@xmpp.org>
> Date: Wednesday, 1 April, 2009, 12:03 AM
>
> On Mar 31, 2009, at 5:36 PM, Dave Cridland wrote:
>
> > On Tue Mar 31 16:00:20 2009, Pedro Melo wrote:
> >> 1) as much as you have right now: remote servers
> can do whatever they want with your presence, you have
> no control after they leave your own server (a
> pessimist would even say that you don't have any
> control after they leave your client);
> > Well, there's trust, and responsibility. If a contact
> has an outright evil server, there's little you can do -
> similarly if your own server, or even client, is subverted.
> For things like this, it's really game over. We generally
> choose to model a trusted client and a trusted server,
> although we assume an untrusted server for content in the
> case of e2e encryption.
> >
> > But then there's responsibility - right now, it's
> inarguably your local server which enforces who gets your
> presence, and a reverse-roster lookup causes immediate
> problems there - if people don't get to see your presence
> (or worse, do when they shouldn't), you've then got two
> places to debug instead of one.
>
> Yes, agreed. The multi-cast solution would change the
> responsibility axis of the problem, not the security axis.
>
>
> >> 2) if subscription state gets out of sync, the
> protocol will behave better or worse than the current
> version :), it really depends which roster is correct.
> There was a thread 2 or 3 weeks back with a tentative
> solution to keep subscription state in sync using the
> initial <presence type="probe" />.
> > I'm not sure your initial analysis is correct, and
> it's related to the above comments I make - if rosters are
> out of sync now, while it's tricky to discover, you know
> where the blame lies instantly in each case.
> >
> > And a rough analysis suggests that in the current
> situation, you'll either get presence when you *no longer*
> wanted it, or else you won't get presence when you want it.
> With a reverse roster lookup, it's possible to end up in a
> situation where you'll get presence when the sender doesn't
> want you to, which is substantially worse, and without any
> bad actor involved. (I could be wrong here, please check
> this.)
>
> if I accept your subscription (my server will move to
> 'both' or 'to') but if that <presence
> type="subscribed"> does not reach you (you keep 'none' or
> 'to') then the remote fan-out is less revealing. I guess I
> could also argue from your side and say that in that case I
> already gave you permission to see so in principle I'm
> disclosing as much as I wanted.
>
> I do believe that out-of-sync rosters is a separate
> problem, and it could be solved with a handshake between
> servers at presence-probe time, but maybe thats the topic of
> another thread.
>
>
> >> But let me clarify something: although the
> bandwidth and processing savings of a multi-cast
> approach to presence distribution should be relevant,
> I don't believe this is compatible with a lot of other
> protocols that we have, so although I think multi-cast
> presence is a worthy long-term goal, I don't think we
> are ready to address it at this moment.
> >
> > I'm not even convinced of this.
> >
> > We have this famous thing about ~87% (the figure
> varies) of traffic being presence, and I'm afraid I think
> these figures skew vastly the moment compression takes
> effect, since, by the very nature of the data we're sending,
> it compresses really well. In fact, I'm not sure that it's
> even worth worrying about as a problem, given how well this
> should compress.
>
> My main concern is actually not bandwidth but processing
> cost. One stanza, one access and sequential fetch to a index
> seems to be more efficient that processing several stanzas.
>
>
> > I basically refuse to consider any solution seriously
> unless you're measuring the effects of it post-compression -
> and I agree that's hard.
>
> Sure, and given that I actually think of this as an
> optimization for overall processing cost, then it will be
> even more difficult to prove.
>
> I guess I need to hack on some server to prove this
> hypothesis.
>
> Best regards,
>
Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/
