[Standards] Fwd: Meeting minutes 2010-02-15
dave at cridland.net
Fri Feb 19 12:41:21 UTC 2010
On Fri Feb 19 11:35:20 2010, Philipp Hancke wrote:
> Dave Cridland wrote:
>> Ah, gotcha, you're referring to smart presence distribution, and
>> ironically comparing the reaction of the council. How witty.
>> 1) Without trundling back to the threads to remind myself what the
>> sync liabilities are, I suspect this refers to assymetric rosters,
>> which have remained a problem (and the current resolution is to
>> respond to probes on a case-by-case basis to re-symmetrize - if
>> that's a word - the rosters, which'd entirely break with "smart"
>> presence distribution). Distributed MUC is specifically designed
>> (one hopes) to handle synchronization of relevant state data, and
>> is allowed (specifically) to do all manner of weird things to
>> mitigate the liabilities therein.
> Simple chatrooms actually do not need shared state and control. All
> need is smarter routing.
Depends on what you're shooting for.
>> 2) S2S compression remains our best solution to the matter of
>> inter-domain presence bandwidth, but I'd note we have nothing like
>> the issue that other protocols have. I do have some research I
>> need to carry out on this, but I currently lack the time. In any
>> case, I've read this proposal as an attempt to tackle resilience
>> rather than efficiency as the primary goal, so I'm not convinced
>> this argument is worth revisiting
> In http://mail.jabber.org/pipermail/muc/2010-February/000144.html
> you say
> "Another distinction between the two approaches is what the core
> are - in PSA-style, it's to provide resilience between servers,
> whereas in KD-style, it's largely to reduce redundant message
> from being repeated redundantly repeated."
> So you changed your mind already and think reducing redundant
> is no longer worth revisiting?
Not for presence as a whole, no. For chatrooms, I think it's worth
looking at, especially if we can gain some levels of resilience out
of it as well. Sorry, but by trying to combine two arguments, you are
muddying the waters and confusing two cases which I don't think are
Let me also clarify - if we could send IM presence once over a link
and have fan-out controlled by a foreign domain, I'd be happy with
it. But I don't think that's a practical option, given that it
requires greater trust between domains, and prevents various other
forms of control. FWIW, the same applies to PEP versus general
PubSub, I think, and these are the same protoclo, but with different
>> for this proposal - but the distinction of trust delegations means
>> different solutions may apply.
> One fabulous side effect of "smart" distribution techniques, where
> let the receiving server know who's to receive things from somewhere
> is the amazing way how this protects you from SPIM. If the protocol
> all built on unicast, there is hardly a way to detect SPIM. If a
> message has to go to all recipients of a certain context, be it a
> distributed chatroom or a person's presence, multicast SPIM leads to
> unsubscription from the "infected" source whereas unicast SPIM is
> obviously illegal and doesn't need to be delivered to the recipient.
> So having proper multicast structures actually strengthens trust and
> solves not only the effeciency issue.
>> 3) I'm not sure exactly what Matt Miller intended to mean at this
>> point, but I suspect it relates to Peter's suggestion to get hard
>> data. See above - on the subject of inter-domain presence (and,
>> for that matter, inter-domain MUC traffic), I'm intending doing
>> some measurements when I can on actual field data, although my
>> measurements based on more theoretical cases seemed to hold up,
>> and the observation that the bulk of bandwidth consumption is
>> highly self-similar, and thus should compress well, is still valid.
> No doubt. But those properties also mean that the traffic pattern is
> similar to a SPIM or flood attack, making those undistinguishable.
Okay, I can go along with this, but I also suspect it's again much
more of an issue with chatroom (and PubSub) traffic than it is with
general presence (and PEP), which in general terms has an established
relationship involved as well. Luckily, this is very similar division
to the trust issue - fan-out of chatrooms and pubsub nodes is, I
think a lot more likely to be practical without any changes to the
trust model we have.
>> 4) I understand this proposal is aimed at bringing simple
>> resilience for chatrooms across heterogeneous XMPP networks, very
>> much like IRC. I'd be interested in seeing how you'd do it. I do
>> think you're much better
> lynX will post to muc@ about that.
>> placed to find a reasonable solution, and in this case, where
> Unfortunately, there is no single "reasonable solution". The only
> common pattern is "at most once per link".
I don't think that's the only goal. I think shared state to provide
resilience is useful and important too, but I think we can require a
formalized trust relationship there.
>> relationships are explicitly configured, I'd expect the kinds of
>> solutions you're likely to propose to be more acceptable to us
>> annoying folk in the XMPP world.
> Beware, I still consider sending stanzas without a 'to' attribute
> most elegant approach ;-)
Sure, from some perspectives. I just think that thanks to various
other features of the architecture, doing this blindly will lead to
But I'm pretty sure you understand my perspective on this - you
pointed out in private IM that "the moderator which uses a slave
needs different information from the master than the average user" -
things like jid disclosure, etc, may indeed mean that a simple
master/slave isn't suitable for all cases, and we'll need to consider
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards