The Auditorium feature (cmode +A)
Hi all, This feature is intended to let us run network-wide events where people may ask questions during the events without "disturbing" the event. When a channel is in auditorium mode (+A'ed), the following applies to users who are not opped or voiced: 1) The user list of the channel is hidden, they can only see ops/voiced on the channel (with /names). 2) When the channel is not moderated (+m'ed), messages that are sent to the channel are being relayed to #channel-relay. 3) Joins are hidden. 3) Parts are hidden. 4) Nick changes are hidden. 5) Quits are hidden. 6) /who +c is hidden. 7) Mode changes are hidden (with the exception of +o/-o/+v/-v which makes the opped/voiced appear to join/part as needed). Opped and voiced users can still see the send messages to the channel, see channel user list, mode changes, etc. This feature (channel mode) is currently can only be set by u:lined servers (services). It may be opened to all users in the future but it will probably be limited to channel managers/founders as it isn't a mode that needs to be changed on the fly. Do you think this feature will be good for other usages? do you feel like it should be opened for everyone? do you have any other comments/questions? feel free to share. -Kobi.
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
On Wed, May 15, 2013 at 7:30 PM, Jimmy Hess <mysidia@gmail.com> wrote:
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.
Eww.
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.
Why flood out NAMES? If you change the channel +A, sent PART messages as needed... if you go -A send JOINS. Yes, it's a bit floody... but it lets everyone's client stay in sync -- klb
On 5/15/13, Kevin Buley <klb@dal.net> wrote:
Why flood out NAMES? If you change the channel +A, sent PART messages as needed... if you go -A send JOINS. Yes, it's a bit floody... but it lets everyone's client stay in sync
To be clear; except during a Netsplit/Netjoin type operation (between servers); I don't recommend flooding out anything to users related to +A, whether it be /NAMES or JOINS/PARTS. I recommend requiring the channel reasonably assured to be in a state in which nothing would need to be flooded. The inconvenience of reaching this state, before starting the 'event', should be very minor, compared to the benefits of auditorium mode for the 2 or 3 channels that should have use of the mode.
klb -- -JH
Hello, I believe it's a good feature! And an excellent feature from getting rid of packet kiddies targeting a specific channel when it's set to +A. If the mode can only be applied by Founder/Manager; other ops (sop/aop) should not be able see the nicklist as well. They should be treated just like the other users of the channel until. Also if the cannel is +m the messages would go to #*-rely channel. I believe it's bad idea considering someone flooding a channel and instead rely channel is being flooded. Also what is the need of having a rely channel at first place ? Let me know if I am missing something here. The mode should be visible to everyone. I think it should be considered as an emergency mode for a channel in case they have some trouble makers in it. Best Regrds, Sunny On 16؍ مئ 2013, at 12:33 دن, "Kobi Shmueli" <kobi@DAL.NET> wrote:
Hi all,
This feature is intended to let us run network-wide events where people may ask questions during the events without "disturbing" the event.
When a channel is in auditorium mode (+A'ed), the following applies to users who are not opped or voiced: 1) The user list of the channel is hidden, they can only see ops/voiced on the channel (with /names). 2) When the channel is not moderated (+m'ed), messages that are sent to the channel are being relayed to #channel-relay. 3) Joins are hidden. 3) Parts are hidden. 4) Nick changes are hidden. 5) Quits are hidden. 6) /who +c is hidden. 7) Mode changes are hidden (with the exception of +o/-o/+v/-v which makes the opped/voiced appear to join/part as needed).
Opped and voiced users can still see the send messages to the channel, see channel user list, mode changes, etc.
This feature (channel mode) is currently can only be set by u:lined servers (services). It may be opened to all users in the future but it will probably be limited to channel managers/founders as it isn't a mode that needs to be changed on the fly.
Do you think this feature will be good for other usages? do you feel like it should be opened for everyone? do you have any other comments/questions? feel free to share.
-Kobi. _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
I think it only goes to -relay if it's -m. If it's +m, it goes nowhere. brandon@dalnet [irc.dal.net] Routing & Peering Team Lead On 5/16/2013 4:28 AM, Sunny wrote:
Hello,
I believe it's a good feature! And an excellent feature from getting rid of packet kiddies targeting a specific channel when it's set to +A. If the mode can only be applied by Founder/Manager; other ops (sop/aop) should not be able see the nicklist as well. They should be treated just like the other users of the channel until.
Also if the cannel is +m the messages would go to #*-rely channel. I believe it's bad idea considering someone flooding a channel and instead rely channel is being flooded. Also what is the need of having a rely channel at first place ? Let me know if I am missing something here.
The mode should be visible to everyone. I think it should be considered as an emergency mode for a channel in case they have some trouble makers in it.
Best Regrds, Sunny
On 16؍ مئ 2013, at 12:33 دن, "Kobi Shmueli" <kobi@DAL.NET> wrote:
Hi all,
This feature is intended to let us run network-wide events where people may ask questions during the events without "disturbing" the event.
When a channel is in auditorium mode (+A'ed), the following applies to users who are not opped or voiced: 1) The user list of the channel is hidden, they can only see ops/voiced on the channel (with /names). 2) When the channel is not moderated (+m'ed), messages that are sent to the channel are being relayed to #channel-relay. 3) Joins are hidden. 3) Parts are hidden. 4) Nick changes are hidden. 5) Quits are hidden. 6) /who +c is hidden. 7) Mode changes are hidden (with the exception of +o/-o/+v/-v which makes the opped/voiced appear to join/part as needed).
Opped and voiced users can still see the send messages to the channel, see channel user list, mode changes, etc.
This feature (channel mode) is currently can only be set by u:lined servers (services). It may be opened to all users in the future but it will probably be limited to channel managers/founders as it isn't a mode that needs to be changed on the fly.
Do you think this feature will be good for other usages? do you feel like it should be opened for everyone? do you have any other comments/questions? feel free to share.
-Kobi. _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
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
Jimmy Hess wrote: <snip>
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.
Right, that's definitely something to consider... I would add that if the channel is not moderated and a user speaks, the server should automatically voice them and make them visible to the rest of the channel. As for the hiding of mode changes, I don't think channel users should care about the mode changes and I would surely not want them to see MODE +b floods during flood attempts (as the JOINs+KICKs are invisible to them). -Kobi.
Doesn't this negate the whole point of the mode? On May 18, 2013 8:33 PM, "Kobi Shmueli" <kobi@dal.net> wrote:
Jimmy Hess wrote: <snip>
Right, that's definitely something to consider... I would add that if the
channel is not moderated and a user speaks, the server should automatically voice them and make them visible to the rest of the channel.
-Kobi.
Doesn't this negate the whole point of the mode?
Not really. It's a semantic argument... what should the behaviour of a channel be when it's +A and -m... or +A and -m. To be honest, I think it will confuse people. I think +A should automatically set +m, so there's no ambiguity. -Aaron On Sat, May 18, 2013 at 8:36 PM, Kevin Buley <klb@dal.net> wrote:
Doesn't this negate the whole point of the mode?
On May 18, 2013 8:33 PM, "Kobi Shmueli" <kobi@dal.net> wrote:
Jimmy Hess wrote: <snip>
Right, that's definitely something to consider... I would add that if
the channel is not moderated and a user speaks, the server should automatically voice them and make them visible to the rest of the channel.
-Kobi.
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
I agree with Aaron here! Thanks, Ragnar On Sun, May 19, 2013 at 1:46 AM, Aaron Wiebe <epiphani@gmail.com> wrote:
**> Doesn't this negate the whole point of the mode?** **** Not really. It's a semantic argument... what should the behaviour of a channel be when it's +A and -m... or +A and -m.
****To be honest, I think it will confuse people. I think +A should automatically set +m, so there's no ambiguity.
-Aaron
**** ** On Sat, May 18, 2013 at 8:36 PM, Kevin Buley **<klb@dal.net>** wrote:
Doesn't this negate the whole point of the mode?
On May 18, 2013 8:33 PM, "Kobi Shmueli" <kobi@dal.net> wrote:
Jimmy Hess wrote: <snip>
**
Right, that's definitely something to consider... I would add that if
the channel is not moderated and a user speaks, the server should automatically voice them and make them visible to the rest of the channel. **
-Kobi.
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
**
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
Sunny wrote: <snip>
If the mode can only be applied by Founder/Manager; other ops (sop/aop) should not be able see the nicklist as well. They should be treated just like the other users of the channel until.
I would understand if you said voiced users shouldn't be able to see the nick list but what would the ops do as ops without seeing the user list? ;)
Also if the cannel is +m the messages would go to #*-rely channel. I believe it's bad idea considering someone flooding a channel and instead rely channel is being flooded. Also what is the need of having a rely channel at first place ? Let me know if I am missing something here.
Like brandon said it's the other way around but let's say people are trying to flood #channel and #channel-relay is being flooded instead, I don't see it as a bad thing because our goal is to "protect" the event on #channel... As for the "need" of the relay channel, people may ask questions during the events and while we want to let them do that, we don't want to "disturb" the channel... sure, there are alternatives like having it go as op notice instead of a relay channel or we could let them /msg #anotherchannel or a bot...
The mode should be visible to everyone. I think it should be considered as an emergency mode for a channel in case they have some trouble makers in it.
What kind of emergencies? -Kobi.
On 5/18/13, Kobi Shmueli <kobi@dal.net> wrote:
Sunny wrote: I would understand if you said voiced users shouldn't be able to see the nick list but what would the ops do as ops without seeing the user list? ;) [snip]
The channel ops may in some cases need a way to access the complete user list. Otherwise, it could become difficult to deal with certain kinds of abuse or effectively eject some kinds of abusers from the channel, or detect that a ban has been circumvented. If there are 1000+ users in channel; the ops may not wish to be burdened with the JOIN/PART/NICK spam either, this may overwhelm their IRC clients, or result in the chanops getting disconnected from the server due to SendQ limit exceed. In some cases, it might be more useful for them to have an "Out of band" command for querying the channel membership, and some mechanism for alerting the chanops if a "large amount of join/part" operations have occured since they last looked.
Like brandon said it's the other way around but let's say people are trying to flood #channel and #channel-relay is being flooded instead, I don't see it as a bad thing because our goal is to "protect" the event on #channel...
As for the "need" of the relay channel, people may ask questions during the events and while we want to let them do that, we don't want to "disturb" the channel... sure, there are alternatives like having it go as op notice instead of a relay channel or we could let them /msg #anotherchannel or a bot...
Yes. I see benefits of both the RELAY functionality, and benefits to being able to have the auditorium functionality without RELAY and without moderation Scenarios: Auditorium Moderated Auditorium Unmoderated with Relay Audotirum Unmoderated with no Relay. There may also be a benefit to having a mechanism for "voicing" a channel member temporarily, to recognize them as a speaker in an event... E.g. "To hand them the microphone"; without simultaneously causing them to start seeing the JOIN/PART operations, or gain access to the full user list.
The mode should be visible to everyone. I think it should be considered as an emergency mode for a channel in case they have some trouble makers in it.
What kind of emergencies?
In case of emergencies, i'm sure +m is more suitable; possibly combined with an option such as +b to block NICK changes....
-Kobi.
-- -JH
participants (7)
-
Aaron Wiebe -
brandon -
heimdall -
Jimmy Hess -
Kevin Buley -
Kobi Shmueli -
Sunny