On 5/15/13, Kobi Shmueli <kobi@dal.net> wrote:
Hi all, 7) Mode changes are hidden (with the exception of +o/-o/+v/-v which makes the opped/voiced appear to join/part as needed).
be limited to channel managers/founders as it isn't a mode that needs to be changed on the fly.
I am agreement on this. My feeling is that auditorium mode should be frozen ON or OFF permanently, at least, while the channel exists, and there are any non-chanop non-voice members of the channel; in other words, vacate the channel completely, send ChanServ a command to "queue up" a request to change the auditorium status. The change should not take effect, until the required conditions are met. Obviously the danger is very low, if auditorium mode can only be requested by a server administrator. I think it would be dangerous to allow this to be set by users on the fly, as clients would be left with an inconsistent/desynchronized view of the channel after the mode were set/unset, and flooding out a new /NAMES result to all members of the channel after a change of +A / -A is not great either, as that could potentially be a large flood for the server to deal with in a large channel. So not flooding a resync to members is good, but that means, unless the channel members list is empty at the time of the change, there are client protocol status inconsistency issues.
Do you think this feature will be good for other usages? do you feel like it
My thinking is the suppression of the display of MODE commands other than +o and +v, and the forced relay to #Channel-Relay limits the potential utility. Possibly these should be separate channel modes, for example /mode #SourceChannel +R or /mode #SourceChannel +R #RelayChannel * Where #RelayChannel must be -R and cannot itself be an auditorium. Particularly if this were opened to general use, there would be a risk that #SourceChannel-Relay is already taken. "-Relay" seems like an arbitrary suffix added here; which is not supposed to have any special meaning within the context of the IRC protocol. furthermore, it would be ashame to automatically grant the owner of #Internet ownership of #Internet-relay Or treat "-Relay" as a verboten word for channel registration; people could want an ordinary channel that ends with that, for nothing to do with the auditorium feature, and yet, it would wind up conflicting. the namespace pollution could be avoided, by allowing a _choice_ of auditorium /and/ relay to specified channel, or auditorium /and/ no relay (send to current channel but still hide the NICK changes and other stuff), or Auditorium and relay to the Modeless Equivalent channel name, E.g. #MyChannel relays to +MyChannel Or invent a different new channel name prefix besides # to denote relay target. Then the question would be... would there ever be a reason to want Relay _and_ Delivery to the source channel as well; or multiple different Auditorium channels relaying to a shared relay channel? These are more complicated scenarios that could have some usages. For example: Relay but still deliver to the source channel, could provide channel operators a way of monitoring activity on the channel, in order to detect potential abuse, when they are (however) idle, not wanting to participate, or concerned that their channel may be specifically targetted for abuse when a chanop is not present. A channel bot could also be placed onto the relay channel, to monitor for in-channel commands, without concerns about cluttering up the /names list Multiple auditoriums relaying to a single place could probably be too confusing to be useful.
should be opened for everyone? do you have any other comments/questions? feel free to share.
With the proper precautions; I would say, its usefulness would be maximized if it were.
-Kobi. -- -JH