RFE: Automatic global blacklist

(I'm used to Requests For Enhancement going in the same bin as Bugs. Since I didn't see a separate forum for them, I assume that's how you do it, too. If not, please move this thread to any appropriate subforum, and my apologies for the extra work.)


Goal:

Make the spammers have to work significantly more, with disproportionately little added work for the GMs.


Feature request and specification:

An account and a character are either grey, white, red, or black. All accounts are initially grey. All characters are initially the same color as their account. Server-side per-character data includes a count of blacklistings.

Grey and white characters can interact with other grey and white characters normally. Red and black characters are prohibited from communicating with other characters, exactly as though they were on every other character's blacklist.

When a grey or white character blacklists a grey character, the latter's blacklisting count is incremented and checked. If it's 50 or more, the blacklisted character becomes red, and a GM is notified.

A GM may set a character or account to be white or black, regardless of its current color. (Usually they will only do this to red characters.) Once a character is white or black, they will only ever change color by the intervention of a privileged user.

If an account has three or more white characters associated with it, that account and all characters associated with it are set to be white; likewise for black.

Blacklist counts are maintained for all characters for moderator reference, but can only cause automatic color transitions from grey to red.

The blacklisting count only includes grey/white characters' blacklistings. When a character's color is changed, all characters on that character's blacklist will have their blacklist counts updated appropriately. (This should be an infrequent operation.) Cascades may or may not occur, depending on implementation details.

Periodically, each client checks the color of each character on its blacklist, and removes any black characters, freeing up space. Messages noting this automatic removal can be filtered out of the log separately from ordinary blacklist manipulation messages, and are not shown by default. (The check period and client-side cache invalidation strategy are implementation details which are not specified here.)

The global blacklisting feature (the state transition grey->red) may be disabled on a per-world basis.

Optional: Another color, 'ashen', may exist. If so, only a GM or other privileged user may set a character ashen. Ashen characters are identical to white characters in all respects except that they do not participate in global blacklisting: they perceive red and black characters normally, and do not increment other characters' blacklist counts. Ashenness may be a temporary state—perhaps by policy, perhaps by programming.


Example behavior:

• An RMT spammer sends /tells to everybody on /search. Soon, they're automatically globally blacklisted (red). A GM sees that their last few actions are RMT advertisement /tells, confirms the blacklisting (setting them black), and closes the issue without further note.[br]

• A player has a habit of spamming emotes in public areas. Eventually, enough players blacklist them that they are set red. A GM is notified, and based on their last few actions, investigates per current policy as though a harassment call had been made. The GM lets them off with a warning (or whatever the current policy is; I don't propose to change it) and the offending player is set white. Existing and future blacklisting of that player works normally, with no GM intervention or notification.

• A large FC, for good reason or ill, ostracizes a given character; more than fifty members put a given character on their blacklist. The GM again investigates. The player is clearly not an RMT spammer and so is set white, although he remains blacklisted by the FC. If 'ashen' is a valid color, and if the GM determines that the FC (or its inhabitant demagogues) acted in bad faith, deliberately misusing the global blacklist as a punitive measure, they may set one or more of the FC's members ashen for some period of time. Regardless, the player is clearly not an RMT spammer, and so is set white.

• A large FC ostracizes a given character, deliberately attempting to misuse the global blacklist as a punitive measure; more than fifty members put a given character on their blacklist. Nothing different happens. Unbeknownst to the FC, that character has already been set white.

• An RMT spammer decides to make a bunch of accounts to punitively counter-blacklist anyone who blacklists their advertising accounts. They succeed... but only once per character. A GM investigates, and sees that the blacklisting players are largely mass-manufactured L1 accounts (or whatever the RMT spammers are using that week). They inform the player that their character is now immune to RMT counterblacklisting, thank the player for their service (possibly giving them a 100 MGP reward or other unfarmable pittance as a gratuity), and set their character white. The player is free to continue blacklisting RMT advertisers with no further adverse consequences and the cheerful certainty that they're actually having an effect.

• An RMT spammer keeps track of characters that have blacklisted them in the past, and ceases sending those characters RMT advertisements, to prolong the life of their adbots. Nobody does anything in response, because this is a victory. (They'll still try to advertise to new players, of course; but the harder they fight, the quicker they'll scare the fish.)

• An RMT spammer sends exactly 49 /tells before abandoning a character. They have effectively blacklisted themselves one /tell early. While this does clog up blacklists, it clogs up at most 49 characters' blacklists (as opposed to the hundreds it may currently clog); blacklist saturation [1] is therefore achieved much less quickly.

[1] The state in which every RMT-spammer blacklisting is preceded by a deblacklisting of a previous RMT-spammer account. (Sadly, this is the state of the game today.)

• Multiple large FCs take PvP too far, and start blacklisting each others' members en masse as a weapon of war. The GMs collectively decide to disable global blacklisting on that world, leaving RMT spammers to run unchecked and the entire world to drown in an eighth hell of its own devising—a second Calamity, told of by refugees to other worlds as a cautionary tale.



Known issues:

• That last paragraph is probably a bad idea, but it makes for a good threat.

• More clinically: "50" was selected randomly and may be a poor number, due to the potential for abuse by larger FCs or other alliances of bad actors. However, in practice I expect it will only negatively impact RMTers... especially since people will be warned in advance that abuse of this feature will lead to its removal and a concomitant reincrease in RMT spam. If 'ashen' is a thing, then it can be done on a per-character basis.

• I have not familiarized myself with other submitted suggestions on this topic. This, or a suggestion with similar flaws, may have been considered and rejected. If so, my apologies.

• I honestly have no idea how to handle the blacklisting count of someone who's in Another World at alteration time. I hate that it's currently not possible to blacklist someone offline or elseworld, and I'd rather there not be any additional reasons for that fact.

• Global blacklisting is not quite hellbanning; it may be deduced from the behavior of the Duty Finder. (I assume that blacklisted characters cannot join duties or parties with characters blacklisting them.)

• As noted, although it should mitigate the issue of blacklist saturation significantly, this would not actually solve it.