Mention that servers may use ERR_NOSUCHCHANNEL instead of ERR_CHANOPRIVSNEEDED to conceal +s channels

[progval]

This matches InspIRCd's behavior, which Ergo is considering too.

As far as I can tell, no one else implements it this way, so this is not phrased as a requirement.

[slingamn]

I missed this earlier, but I would suggest mentioning 442 ERR_NOTONCHANNEL as an alternative (i.e. sent in both cases, whether the channel exists or not), since it is more "truthful" ;-)

[progval]

done

[tommyrot]

The text is confusing, are you suggesting ERR_NOSUCHCHANNEL and ERR_NOTONCHANNEL to be valid responses to PRIVMSG and NOTICE? Below are the valid responses from the RFCs. It seems you want to add two? I haven't seen implementations use the aforementioned ones. @slingamn if Ergo is indeed the only one deviating, can't it use one of the listed responses instead (e.g. ERR_NOSUCHNICK)? It's becoming the wild west of responses which is very confusing.

   Numeric Replies:

           ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
           ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
           ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
           ERR_NOSUCHNICK
           RPL_AWAY

[progval]

that's not my intent, I need a better way to phrase this.