Not really bad at all.

Interesting. This is one of the problems 'LibStub' exists to solve, I wish more Library Authors would use it. An IoC provider (or dependency container/manager, which is what LibStub is) allows shared libraries to register themselves so they can be utilized by multiple Add-Ons, and also allows for add-on libraries which cannot be shared to not be registered (or be registered with a different name.)

Following convention, LibStib libraries do not collide in the global namespace. They must be explicitly resolved.

Unfortunately the vast majority of add-on developers seem to fail to see the value in dependency management.

Introducing a "shared file" breaks this sort of dependency management, which is superior to trying to manage individual files to achieve the same result. I would highly suggest not doing this for any library which:

1. Is LibStub compatible.
2. Incrementally modifies the global namespace, as is done via utf8.lua

Wow, thank you for pointing this out. These changes should not be used by anyone. "r7" was a POC I sent to Seerah privately and was not meant to be distributed, I also do not use any of the modifications which were made (and there is a bug in at least one of the extra methods which, at present, I have no intention of fixing.)

Short answer: do not use this, I will be replacing it with the official r6.

While you could potentially use my version of "utf8.lua" for all add-ons, I can't guarantee that this won't change in the future. The problem with utf8.lua is that several useful methods are local-scoped, and I often have to make them global or extend LUA's string type to expose the calls I need. My suggestion to you is to not "share" the version of utf8.lua I distribute, and instead continue to leave the X4D_LibAntiSpam.txt unmodified.

Pleasure is all mine, this thing keeps me sane and doesn't break my Chat Mod in the process.

I'm curious, do you manually update all of these TXT files or are you working on software to do it for you?

Also, you may find this an interesting read, while different it is conceptually identical to the problem you are currently facing: http://en.wikipedia.org/wiki/DLL_Hell, the most common solution in practice today (on windows and non-windows alike) is the section titled "Portable Applications".

The error is in reference to "/lib/utf8/utf8.lua" which was updated in 1.42 - I customize "utf8.lua" for use in LibAntiSpam, it it is not the same as "utf8.lua" found in other Add-Ons.

Lines 155-157 of "utf8.lua" should look like this, if it does not look like this it is not properly updated:


You may be able to fix the issue by simply re-copying utf8.lua from the ZIP file into the correct folder, or just delete the X4D_LibAntiSpam folder and re-copy the entire Add-On from the ZIP file.

Hope this helps.

There is no log, the state resets on every log-in.

If you want to disable Flood Checks simply set "Flood Time" to 0.

Setting "Flood Time" to 30 (seconds) means that anyone who repeats a message within 30 seconds will be blocked.

Setting "Flood Time" to 2 minutes (120) means that anyone who repeats a message within 2 minutes will be blocked.

The setting not only determines the amount of time a user cannot repeat, but also determines how long they will be blocked for. Flooder Blocking is NOT permanent, the block will eventually expire if the user stops sending repeated messages.)

Some ways to prevent people from getting blocked for flooding:

1. Set your "Flood Time" to 0. Default is 300 seconds (5 minutes.)
2. Add them to your friends list, this will white-list them ensuring they are never blocked for any reason.
3. Add them to your guild, or join one of their guilds. This will white-list them.
4. Join a group with them.

After 2, 3 or 4 you may want to /reloadui.

You can also execute a /reloadui if someone is accidentally blocked (maybe they said "lol" several times in a row.)

The purpose of Flood Checks is to prevent WTB/WTT/WTS spam, as well as Guild Advertisements. Prior to v1.41 this feature was actually not working correctly, if you prefer the old behavior simply set the "Flood Time" setting to 0.

Hope that helps

The limit was doubled today.

I really wish it were that simple. LibAntiSpam normalizes the text, to understand the problem in exact-matching that text consider the following faux spam messages:

\/\/_\/\/_\/\/

\/\/*W_-=\/V

***\/V****
***V\/**** BUYDERPIEGOLD.COM
***\/\/****

We would either be adding explicit '\/\/ \/\/ \/\/' checks until we turned blue, or the spammers would simply work around it.

Instead we match on more particular strings. Since a proper check for all possible 'WWW' combinations would most assuredly catch non-spammers (in addition to ALL spammers.) So instead we target strings which are specific to each spammer. This minimizes the chance that a non-spammer gets caught by the Check() method.

I'll add a 'generic' check for various combinations of "\/\/ \/\/ \/\/" since it might catch new spammers by surprise, but I guarantee they will just work around it and either stop using that text or find a way to bypass the checks. Presently, LibAntiSpam does not check for this text at all, and, presently, spammers use 8 different variations of "WWW".

That said,

Once spammers have seemingly exhausted all their means to bypass pattern-based add-ons I'll provide "layman's" instructions on creating new patterns, and I expect it to be a truly trivial effort in the end. I will also be introducing a set of heuristics to auto-block some of the less creative spammers, but cannot invest time in doing either of these until the normalization code has become stable/fixed for some time.

One user suggested added a menu-option to auto-create a pattern from spam text, and I like this idea. I will likely attempt to take this approach in the end.

Thanks

UPDATE: in response to this message I have just found a bug in the flood check code where it was not properly preventing flooders. I will be updating with a fix in a few minutes. Thank you for bringing this up.

Currently LibAntiSpam also performs 'Flood Checks', a 'Flooder' is any user that sends the same message in chat within a given time frame.

The default period for a flood check is 30 seconds, I believe. I personally set this to 300 seconds (equivalent to 5 minutes.) In the next release the max "flood time" you can set in the options to a maximum of 15 minutes (900 seconds.)

The flood check period also re-extends every time the chatter is detected to be flooding again/more. Thus, for recruiters that spew the same message to chat every 3 seconds for an hour, you would only see their first message (the rest are blocked.)

it's possible, but I haven't bothered looking at the Mail API calls yet. I was actually hoping that someone who already develops a Mail Mod would integrate with LibAntiSpam (since it can be accessed via LibStub as a library.)

Doesn't look like it had happened yet. I'll take a look at Mail API calls this weekend and see what I can do.