Pedro Melo wrote: > Hi, > > 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. > 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. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
