[Standards] Council on Stanza Repeaters without Multicast

Peter Saint-Andre stpeter at stpeter.im
Tue Apr 8 23:35:30 UTC 2008

Pedro Melo wrote:
> On Apr 4, 2008, at 9:04 PM, Dave Cridland wrote:
>> On Fri Apr  4 15:55:26 2008, Philipp Hancke wrote:
>>>> If we solve scalability in MUC and PubSub - and I think we can
>>>> *without* repeaters, and I think that repeaters are not well
>>>> understood, and may cause greater harm than good - then I think this
>>>> is way beyond good enough. I believe that for both MUC and PubSub,
>>>> using a slave entity which passes on subscriptions to a master
>>>> entity, and manages
>>> may pass on for "open" nodes ;-)
>> I think MUST at all times.
>> First off, open nodes should get the statistics. This is arguably a
>> political choice rather than technical, but I suspect that if a feed
>> publisher knows there are several million subscribers, they'll make
>> more effort in their XMPP strategy.
>> There is the technical argument that is that the policy of the node
>> should be handled by the node, and not by a proxy.
> Sure, but if a node owner is ok delegating the subscriber policy to the
> remote proxies, why should a future spec prevent that?

How do I know that a subscription request comes from a proxy? Does my
pubsub service need to send a disco#info request to each subscriber in
order to determine its identity, then ask me to approve the subscription
request if it comes from a proxy?

> Better: when I send a message to a remote proxy I could ask for a
> "delivery report" message back, stating how many JIDs the message was
> resent to.
> So I can get one report per message I send and keep my bean-counters
> happy. I know the reach of each message.
> This could be an option in the initial response to the subscribe request
> by the proxy or a per-message flag somewhere.

I'd prefer it as a subscription option, because it's not *really*
something you care about for each message, I think.

>> A full solution to its woes would be essentially indistinguishable for
>> Stanza Repeaters, so there's little point in doing so, but anyway, the
>> point is that these three cases are not actually as similar as one
>> might hope, and the case that has the highest cost in terms of
>> complexity is also the one which has the lowest gain.
> Yes. I agree with this.
> And although its always nice to solve a lot of problems with a single
> XEP, I would like to see the pubsub problem solved first, at least for
> the public node scenario. I think that the experience we can get by
> solving that will be useful to attack the others.

I tend to agree that the most interesting use cases here are MUC and
pubsub. Now, you could argue that MUC is just a specialized form of
pubsub, but in reality it's different enough that we may need to handle
it separately.

Presence is just a specialized form of pubsub, too, as has been pointed
out many times before. But I'm not yet convinced that we need to tweak
presence much.

Generalized solutions are appealing, but there's always the danger of

As I see it, MUC and pubsub already can be multicasted if you don't mind
having bots in your MUC rooms and pubsub services subscribed to pubsub
nodes. Send to the bot or proxy and it distributes messages on the
remote end. You can even chain those together. Granted we might want
more elegant solutions, but these might be enough to get the job done
for a while.

Another approach: when you try to join a room or subscribe to a node,
you are redirect to the local slave/proxy. We'd need better support for
the redirect error but that seems doable.

Still pondering...


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080408/bd57292d/attachment.bin>

More information about the Standards mailing list