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.. ;) Meow.
