Hi,
On Mar 18, 2008, at 2:18 AM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Mar 17, 2008, at 4:28 PM, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Stanza Repeaters
Abstract: This specification defines an XMPP extension that enables
optimization of interdomain traffic that is intended for delivery to
multiple recipients, using the concept of a stanza repeater.
URL: http://www.xmpp.org/extensions/inbox/repeaters.html
The XMPP Council will decide at its next meeting whether to accept
this proposal as an official XEP.
I'm sure there is some security implication that I'm missing, but
why do
we need to make the hash of the repeater ID so tightly coupled
with the
recipients list?
We don't need to. That was one suggested approach.
I understand the need of keeping the ID unique but I fail to see what
else is gained by this complexity.
On the other hand, the use of an ID that doesn't change each time we
update the recipients list would be easier to work it in the
presence of
multiple senders.
Probably, yes.
Regarding the use of repeaters for <presence>, maybe we should
just use
the domain of the users as a virtual repeater, like PEP is a virtual
pubsub at the users domain. This was suggested two years ago, btw.
It was? I don't remember that.
There may be privacy concerns related to presence repeaters (my home
server should have control over how my presence is distributed -- it's
not acceptable for my server to just send my presence off to another
server for it to distribute however it pleases). In any case I
don't see
presence as the key driver for repeaters -- IMHO, MUC and pubsub
are of
greater interest.
This is a misconception in my opinion. The notion that you control
your presence distribution after the stanza leaves your trusted server.
You just don't control how your presence will be distributed by
remote servers, you assume that they will do the right thing. And
most if not all will.
But nothing prevents a remote server from channeling all incoming
presence to some external component for further study. I'll bet that
this practice will become even more widespread as statistical anti-
spim tools arrive...
But this is getting off-topic a bit. Yes, pubsub and muc are the big
winners for this, and again, I think we should drop the complex hash
generation, or at least drop the coupling with the recipients list.
The roster at the remote host could be used as the distribution
list, no
need for costly updates. Just reverse-query the roster if your DB
system
provides that (easy for SQL-based rosters, not as simple for LDAP-
based
ones).
Rosters can get out of sync. The roster at the remote host is not
necessarily to be trusted.
Yes, true. But keeping the rosters in sync might be a worthy goal,
probably for a new XEP. A small extension to the initial probe, with
the current status... Anyway, off-topic in this thread.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
