On 5/16/13, brandon <brandon@dal.net> wrote:
I think it only goes to -relay if it's -m. If it's +m, it goes nowhere.
Yes; that's right. I am aware of what the functionality is that is shown in the patch. But I believe combining the relay behavior with the suppression of non-voice/chops in users list and suppression of NICK change messages, etc; Makes the auditorium mode less useful than it would be otherwise; if these different aspects were separated out into two different channel modes. You could reasonably want all the auditorium functionality, except the relay function, such that with a -m auditorium channel, messages sent by non-voice users went to the channel as per normal. This could be useful in scaling channels to very large numbers of users, such as 2000+, where JOIN/PART/NICK chatter eventually becomes prohibitive. IRC protocol is not very suited to such large channels in the first place, but it could nonetheless help in more routine circumstances for very large channels [*]. Also, for it to be generally useful and safe to be opened for founders to choose -- I do not believe any /MODE information at all should be suppressed. For example, Mode changes and TOPIC change operations, which can be performed only by chanops, should still be propagated to members. [*] IRC protocol is not very suited to such channels in the first place, and there are still issues regarding every message "broadcast" to the channel, essentially has to get unicasted out, typically, in a TCP/IP network inefficient way -- an efficient path to thousands client IP addresses, will often not be the path the packets actually get to take, as users are often connected to the wrong server, or the topology through the IRC network results in a less efficient path, than if the peer IRC clients could exchange the packets with each other directly..
brandon@dalnet [irc.dal.net] Routing & Peering Team Lead -- -JH