[Standards] Council on Stanza Repeaters without Multicast
Carlo v. Loesch
CvL at mail.symlynX.com
Thu Apr 3 13:58:41 UTC 2008
Pedro Melo typeth:
| <allow_local_subscription />
Yes, I like this one. That's how junctions do it by default.
| Trust, like, "I want to know if the notification is really from my
| friend Peter" is a problem for PKI and digital signatures, not the
| "multi-cast" system on top of XMPP. IMHO.
And I'm + on this one, too.
| Again, I only see this as useful for auditorium-style MUC rooms. For
| normal MUC rooms, then you are implementing IRC on top of XMPP and
| multicasting message will be the least of your concerns (think
| netsplits, and making sure your nick is unique).
If you do it in an IRC way, yes. But that should be avoided, no
matter which size makes MUCs worthy of full Multicast treatment.
Whereas smart unicast is always a plus.
Netsplits should not happen, since XMPP can organize its routing
better than through IRC's strict tree structure. The kind of
Multicast I am suggesting creates a new tree optimized to each
context on top of a federated infrastructure. You would not have
IRC-style netsplits, because it isn't IRC, but of course you can
still have a serious network failure which in PSYC's scenario
means those people are temporarily cut out. No conversations
in the subtree, no conference control battles. Complete silence.
You *can* do it differently, but it's a can of worms.
Unique nicknames: Just never let slave nodes decide upon nicknames.
That is a very un-IRC thought, but should be quite natural for
XMPP. The top MUC is in charge of assigning a nickname. Honestly
I prefer people were always talking with full URIs, but that's
just my gut feeling.
| My opinion, is that without remote fan-out for pubsub, XMPP will not
| be a long term option as a notification network. Yes, it beats
Guess what, currently PSYC is better for pubsub - scalingwise.
Of course it doesn't have all the fancy features to it.
| Yes, and I think that even if there is no consensus about repeaters
| as a general solution, we should have something to repeat public
| information via pubsub and certain types of MUC rooms.
We can have Repeaters as a swiss army knife, then later develop an
extra hammer that suits certain nails better. Trying to find the shoe
that fits all princesses will keep XMPP from scaling for further years.
More information about the Standards