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.
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.)
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.
I basically refuse to consider any solution seriously unless you're
measuring the effects of it post-compression - and I agree that's
hard.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade