Hello, I am verry sorry for the trouble. I have fixed my code, upload them to my branch and finally had the chance to do a thorough testing. The link to my branch is in the github comment. Thank you, Daniel. On Sun, Apr 26, 2015 at 1:58 AM, Aaron Wiebe <epiphani@gmail.com> wrote:

Thanks for the submission Daniel, however I've reviewed your code and it will not achieve what you want - nor would it compile. We'll review the idea, but as it stands I'll have to reject your pull request.

-Aaron

On Sat, Apr 25, 2015 at 12:33 PM, spithash <spithash@hotmail.com> wrote:

...

This is a rather a fantastic idea my friend :)

It sounds really helpful. It could work great..

On 24/04/2015 05:44 πμ, Daniel Tan wrote:

Hi all,

Upon enduring endless occasions of NOTICE floods in channels, I hereby propose a new channel mode +T as a more effective mitigation tool for channel ops compared to traditional methods (i.e. channel mode +m or +M).

Channel mode +T would block non voice or non ops from sending NOTICEs to the channel thus eliminating the necessity to enable the moderation mode.

The codes to introduce this new channel mode +T is now available for viewing at Bahamut's Repository at PR #15. I highly appreciate you to review and please feel free to place comments on the PR itself.

Thank you.

Regards, DBoyz/Daniel

_______________________________________________ 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

_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src

I'm getting on this real late; sorry. JH made the point that notice and PM are identical, and +T might be a bloat in code. I am not sure how it would be a bloat (with all the channel and user modes already in existence). Would one more mode be that much of a strain? DALnet coders already intervened with PM user modes (R). Couldn't this concept be expanded to channel notices without chanop control; i.e. only registered users can send chan notices? Could +bquiet (the feature that prevents banned addresses/users from sending channel messages) be extended to include unregistered users from channel noticing (if a new, unchangeable mode will not be added)? If +bquiet cannot be extended, can an alternative be devised (that would not prevent unregistered users from sending regular messages and regular notices to channel)? The issue might be raised that unregistered users should be able to channel notice; e.g. a DALnet oper might be monitoring a problematic channel with an unregistered nick (and he may need the channel's attention for some reason). I doubt this will ever occur. The only instance I can see this issue being a problem is for staff of #nohack. I recall, years ago, a nasty virus going around. It disabled most forms of communication (on IRC) for infected users (many unregistered). Maybe staff communicated via noticing. I don't recall how they finally communicated with the infected users; many changing channel topic with commands for the users was employed. I think it is an interesting idea. I know a trivia channel I am manager of, for a short time in 2014, was getting unregistered users that chan-notice flooded. On Sunday, April 26, 2015 11:48 AM, Jimmy Hess <mysidia@gmail.com> wrote: On Thu, Apr 23, 2015 at 9:44 PM, Daniel Tan <danieltan1901@gmail.com> wrote:

Channel mode +T would block non voice or non ops from sending NOTICEs to the channel thus eliminating the necessity to enable the moderation mode.

I believe the focus of flood prevention should be message rate-based controls,  not message "form",  which is just coincidence.    It provides more "useful information" for flood detection if a less-often-used message format such as NOTICE is used,  So mitigations/defense should not be used that just attempt to make bad actors "conform"  their messages so they look more like good ones; the fact that NOTICE is used provides useful information, which ought to be kept and made part of a detection model,  instead of "Attempting to force bad actors to send their floods using PRIVMSG instead of NOTICE". Have we considered that blocking NOTICE doesn't really mitigate the problem, which is flooding,  And it's at most a one-line  conditional for Bad actors to send PRIVMSG floods instead of NOTICE floods? Therefore... we aren't forcing them to not flood or  doing anything that will stop flooding with +T,  but instead  just forcing an adaptation,  And the bad actors are highly effective at adapting and do so rapidly. So the weight of the additional mode in the ircd codebase would seem to exceed the benefits hoped for. Seeing as PRIVMSG and NOTICE are identical, Except for the fact NOTICE is in fact a special PRIVMSG that is to be used for all automatic responses and guaranteed not to send replies,  and there's really no strong reason for an evil flooding person to favor one or the other. Meanwhile.... having NOTICE blocked in some areas for specious reasons can very well  encourage bad behavior on the part of legitimate bot/script developers,  such as using PRIVMSG for automatic responses, which can result in auto responder loops  that generate accidental flooding. -- -JH _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src