[Standards-JIG] proto-JEP: Address lists

Michal vorner Vaner michal.vaner at kdemail.net
Wed Jun 7 19:56:30 UTC 2006

On Wed, Jun 07, 2006 at 09:37:32PM +0200, Carlo v. Loesch wrote:
> Michal vorner Vaner typeth:
> | > Precisely in a bottom-up approach, recipients can unsubscribe from a
> | > SPIM transmission, eventually leading to whole servers unsubscribing it,
> | > so the SPIM no longer gets anywhere. Or if the spimming server insists
> | > on sending something on a context that no longer has people on it, the
> | > receiving server easily figures out this guy is misbehaving and blacklists
> | > him.
> | 
> | Well, he can as well send direct messages as well and we will end up the
> | same, right? Do yo uwant to turn the whole xmpp inside-out?
> Oh you know I'm always ready to do that.. but jokes aside, in a unicast
> situation the spimmer will have to spend the same amount of energy to
> get the messages out as the receivers, so that's at least not doing him
> a favour like taking over the distribution job.

Hm, thats maybe why jep-0033 allows limits on size of the list. And,
if he has a possibility to build a list of 100 people, what is use for
him? He sends one message and needs another 100.

And yes, if we are about to build a multicast principle everyone can
use, then yes, everyone can misuse. But it is the same with everything.

> Also in a future network, where every message to multiple recipients
> is sent in smarter ways, many a copy of the same unicast message may just 
> arouse antispim attentions.. in other words, you have a chance to fight it.
> | > Whereas in a top-down approach the SPIM is distributed to all servers,
> | > which then will find most recipients have set up privacy bans against
> | > the sender, so the message was transferred for nothing. The recipient
> | > server may be able to figure out, that the sender probably is a spimmer,
> | > but there is nothing it can do to protect itself from the traffic,
> | > as the sender isn't doing anything illegal.
> | 
> | Well, <message> stanzas are based on push principle. So I guess it is
> | more logical to make the broadcast the same way.
> No I wouldn't agree. IP Multicast is also a push medium, but subscription
> operates bottom-up. Even IRC pushes something down a branch of the

But that is not transparent. That is why it is not used. You would have
to modify all the clients to subscribe to MUC messages, to this kind of
data, and to that kind of data..

This way, they do not even know it is multicast.

And, IP has a big limitation - the IP header has specified size. The IP
multicast is not a nice hack, in my opinion.

> multicast tree only when subscribers have JOINed the channel. Since no
> one can tell you not to PART the channel, once all subscribers have parted,
> the channel's noise no longer makes it to the server where the subscribers
> were located on. On a side note, Bitnet Relay wasn't as smart: It would
> distribute channel talk to all nodes no matter if there were people on it,
> giving administrators of relay servers a nice possibility to look into any
> channel conversation no matter how private (channel numbers >999) or secret
> (negative channel numbers).

Well, what channel are you talking about? You have subscription for
presence, you enter and leave MUC rooms and so on. We would have to
modify it all, make completely new infrastructure.


Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060607/91ccec11/attachment.sig>

More information about the Standards mailing list