Quoting Jeekay <[EMAIL PROTECTED]>:

> On Mon, 1 Dec 2003, Andrew Miller wrote:
> > MODE #channel +ko something +something someop
> > would desync clients - you can't change server-client protocol and not
> expect
> > problems.
> 
> If the text were only sent to clients attempting to join the channel, this
> is not a problem as the clients currently in the channel do not see the
> text. The text returned to a client attempting to join a channel with such
> a key message could be fairly trivially modified to support this by adding
> a %s in the appropriate place. I expect the real problem would either be
> memory usage (although I don't expect many channels would take advantage
> of this feature, through a lack of education if nothing else).
The original mail suggested implementing this as a channel mode. It would need
to propagate to other servers, and clients(at least chanops) in the channel
would need to be informed that the mode had been set. It could, of course, be
implemented with a new command in a similar way to TOPIC. Of course, it would
then have to propagate at the burst and we could have the same old TOPIC
bandwidth issue again. It would need a way to be unset as well.

As for notifying clients trying to join the channel, probably a numeric would be
the most useful.

If we are going to implement this, it could expire after a network-wide
timeperiod. For example, channel DoS attacks are usually transient situations,
and expiring the "Turing test" question after 30 minutes might not be a problem.

Alternatively, the channel could be set +r, as the cservice set has a similar
check on it anyway. This does however impose a significant time burden on people
wanting to join the channel, and may simply result in people using another
channel, and fragmentation of channels.
> 
> GK
> 
> 

Reply via email to