[Standards] Proposed XMPP Extension: Stanza Repeaters
Carlo v. Loesch
CvL at mail.symlynX.com
Fri Mar 21 15:03:20 UTC 2008
Dave Cridland typeth:
| Whether that's true or not, protocols do not make political or moral
| statements, and nor should they. Protocols just enable what people
| want to do, whether you agree with that or not. There's a name for
Yes, and this protocol just happens to enable you to watch the presence
of your contacts without revealing your own. I don't intend to say that
neither the designers of XMPP or those of IMPP intentionally planned it
that way, but that's the result. And a protocol where subscription is
directly related to distribution ensures that no subscriber is treated
differently than another. So if we decide to use subscription
information also for routing, we are treating all our subscribers
fairly and we make it necessary, that a proper unsubscription is made
whenever you want to exclude somebody from the list of subscribers -
not silently not make him receive content. That's just intransparent.
Using the existing subscription information isn't only the most
efficient strategy concerning network traffic and scalability, it also
improves transparency for the user, as she can rely upon being subscribed
to this or that - not silently having been excluded.
| If we consider a case where no privacy lists were in use, and if we
Since pretty much everyone considers privacy lists a not so successful
invention, I don't think IESG would object a lot if we were to say
"We've been there, we wore that t-shirt, it didn't look good."
The IESG would certainly understand that given the scalability challenge
XMPP is facing, having a drastic improvement in presence routing is
worth dropping those privacy lists which make presence intransparent.
If you don't want me to receive your presence information, unsubscribe me.
Contacts don't _have_ to be subscribed to presence all the time.
Everybody is throwing presence subscriptions at each other even if
they don't know each other. Maybe we should have more subtle levels
of being in contact. Presence out of politeness is a major burden
for the XMPP network.
| handle roster synchronization, and if we ignore directed presence,
Roster asyncness is a bug that needs to be fixed. Directed presence
can be transmitted in a way that it has no influence on existing
subscriptions. It can play a part in reducing the amount of politeness
presence - you could just send direct presence whenever you need to
talk to someone. Usually you will just send her a message. The real
hurdle is in the UI that doesn't show unsubscribed contacts properly.
As if that was the same as a friend who is *really* offline.
It's a UI problem, really. Maybe we should provide a BCP for that.
And unsubscribing someone should not look like an insult.
| and if we assume that users could and must trust (or, are morally
| obliged to trust) remote servers (quite a bunch of ifs, there), we
| could perform remote fan-out of presence based on the remote server's
| roster data.
You have to trust remote servers anyway, but remote servers should keep
their own data structures on who subscribed what, not let clients modify
them using the roster protocol. The server should be fair and
transparent to both local users and its friends.
| I would point out that if (like us, as it happens) users' rosters are
| stored in a per-user file, that reverse roster lookup is going to be
| exceedingly painful. It's not too bad if you're using SQL or LDAP,
You need files for your subscription lists too, in that case.
Or you keep all subscription lists in one. No big deal, really.
It's the same with the repeaters proposal, only the list of subscribers
is redundantly resent to you, which at least gives you a chance to
figure out your async rosters. ;)
Two years ago somebody suggested we should be able to have both
explicit distribution lists and implicit ones based on existing
subscriptions. That sounds like a compromise. First you fix the
rosters using an explicit list - then you turn it off and make
sure you don't break it again.. ;)
More information about the Standards