Alchera wrote:Channel modes +p (private) and +s (secret) are basically the same as in the channel will not be seen by non-users if either is set.
Actually, I think I figured out why.
First, private and secret are
not the same. However, I had always read that
private prevents a channel from displaying in a /whois request and
secret prevents a channel from displaying in the channels list.
This is apparently not entirely accurate either.
Both
private and
secret do not show up in a /whois. However,
private channels
will display in a channel list.
Secret channels do not (among other things). Basically,
secret overrides
private as being more hidden.
According to the
RFC 2811 document (Internet Relay Chat: Channel Management) section 4.2.6, it specifically states that +p and +s must not both be set at the same time. Although some servers may allow it (Efnet), a +p mode is “silently ignored” if a +s is also present. See below:
The channel flag 'p' is used to mark a channel "private" and the channel flag 's' to mark a channel "secret". Both properties are similar and conceal the existence of the channel from other users.
This means that there is no way of getting this channel's name from the server without being a member. In other words, these channels MUST be omitted from replies to queries like the WHOIS command.
When a channel is "secret", in addition to the restriction above, the server will act as if the channel does not exist for queries like the TOPIC, LIST, NAMES commands. Note that there is one exception to this rule: servers will correctly reply to the MODE command. Finally, secret channels are not accounted for in the reply to the LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) when the <mask> parameter is specified.
The channel flags 'p' and 's' MUST NOT both be set at the same time. If a MODE message originating from a server sets the flag 'p' and the flag 's' is already set for the channel, the change is silently ignored. This should only happen during a split healing phase (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).
So krimson is probably correct that Eggdrop has a check for this because it is maintaining RFC compliance.