Dave Cridland wrote:
[...]
In http://mail.jabber.org/pipermail/muc/2010-February/000144.html you say
"Another distinction between the two approaches is what the core aims
are - in PSA-style, it's to provide resilience between servers,
whereas in KD-style, it's largely to reduce redundant message traffic
from being repeated redundantly repeated."
So you changed your mind already and think reducing redundant redundancy
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 the
same.
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.
No. IIRC this is explained in detail in draft-ietf-simple-view-sharing-02
It does require a quite challenging protocol for subgroup managment.
But this is no different from MUC actually.
[...]
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.
Getting experience with that and postpone presence is fine with me.
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 trust
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.
Resilence makes sense for some use-cases, but there are some security
implications - such as people forcing your slave room to go to "split
mode" and then harassing users.
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 the
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 problems.
Of course. Doing that is nearly impossible when there is more than one
domain pair per s2s link.
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 that carefully.
That was actually just one of many examples why distributed MUC is every
bit as painful as presence.
philipp
