Double the console ban limit
Short, concise description of the idea
The existing limit imposed on console bans (“ban_set” command) is getting less sufficient due to exponential nature of LiveJournal's growth. The limit should be raised to at least twice the current amount of allowed bans.
Full description of the idea
FAQ 20 says:
This is an extremely valueable tool.
Generally, a LiveJournal user may choose to write for a limited number of more or less known friends, to be very restrictive in access control. This is called Friends Only Mode. It's OK when it's just one of the possible options; but it should not be possible to force someone to become Friends Only.
However, if a user tends to keep his/her journal open, sooner or later a comment arrives that cannot be left unmoderated, and/or a commenter who's not welcome any longer.
When a comment is deleted, there's always an option to ban its author. However, there are situations more complex than a simple offensive comment, and they require using Admin Console. Anyone, I hope, can think of a dozen examples.
There are communities dedicated to flood or meaningless comments. (“First post!” and alike; sometimes more obscene.) To keep a journal clean, it is wise to ban all readers (or at least active participants) of these communities.
A journal with an annoying (or questionable) name can be created, serial-adding people to friends. Banning such a journal is the only way to keep your “Friends of” list clean.
If a brute force script (or a malicious webiste) is getting passwords necessary to hijack dozens (or even more than a hundred) of livejournals, it is wise to ban zombies, and to use related banlists exported by friends, so that zombie spammers are stopped.
If some banned authors is manifesting their presence in a journal of banmaker's friend, the banmaker may offer the related part of exported banlist to be executed in friend's Admin Console. (If their presence is malevolent, the banlist sometimes becomes the only way free from being blamed by the friend.)
Some blog-oriented search tools offer search results exportable as daily updated RSS feed, which in turn can be syndicated as a LiveJournal.com blog or used in local RSS reader installations. These feeds can be used (and, in fact, are used) to track any subject being mentioned in the blogosphere and/or forums. For example, if you're going to criticize a real world celebrity, it is always wise to ban a considerable number of hardcore fans beforehand.
If an obscene comment is left and then immediately deleted, it still may be wise to ban its author.
If a comment is polite enough, but may cause an unwelcome discussion, the whole thread is freezeworthy. If a commenter is likely to be annoyed and to protest, it may be wise to ban him/her, leaving his/her comment intact.
All the above examples require, more or less, using the Admin Console. However, the Console has a semi-official (not documented in FAQs, as far as I know) limit: when the number of active bans exceeds 5000, the “ban_set” command fails.
It is still possible to ban much more users when you delete comments (for example, I've banned 5184 already), but the tool is less effective, the above given examples are not covered anymore, and it's not comfortable to delete comments that could be kept as an explanation for other readers curious about why the ban happened. This also means that my banlist can not be shared and imported “as is”; still very useful for me, it has lost most of its usefulness for my friends...
So, as you may have already guessed, I suggest a higher console limit for bans. At least, 10000.An ordered list of benefits
- Without invite codes, it takes a two or even ten bans sometimes to prove that it's still easier to ban than to register a new account. The ban limit should be at least doubled to prevent this strategy, to give the banmakers equal benefits.
- LiveJournal grows. There are already celebrities (virtual and real) and communities with thousands of readers. The ban ceiling should be raised to reflect this growth.
- It is sometimes ten times harder to find a good friend than an annoying offender. If the number of friends is limited by 750, the ban limit should be at least 7500.
- No one should ever be forced to become friend-only. Without the console, one may be.
An ordered list of problems/issues involved
- Once I was told by an Abuse Team member that the limit is imposed on a per-journal basis to optimize the query of determining whether a user has been banned from commenting in a journal. However, it still may happen to bring an overall benefit if the ban marks could be stored at the banned accounts instead of being stored at the account of banmaker protected by bans.
- I was also told that the ban limit of 5000 accounts was selected to achieve a balance allowing users to ban others, while not imposing heavy strain on the LiveJournal servers. However, this strain is already regularly multiplied by the growth of total population; is it going to be doubled if the ban ceiling raised to twice the current amount? And, if the only alternative is going to friends-only mode, won't the strain be even higher than the strain of 5000 extra bans? In friends-only mode, not only commenting, but even reading a typical blog entry requires a thorough (list-based) security check.
An organized list, or a few short paragraphs detailing suggestions for implementation
- The limit of 5000 is not an integer power of 2; so, in binary system, the number looks pretty artificial. It may mean that the source code uses some inefficient array search through the banlist (maybe, even the most inefficient -- incremental checks against the first array item, then the second, and so on) instead of having a binary tree of the banlist stored. Upgrading the data structures (using a binary tree) should optimise the search (eliminating the unnecessary strain), and raise the ban ceiling up to the more natural 8192 (2^13), or to 65535 (hexadecimal FFFF), or something similar.
- In this case, the binary tree should be built each time when a new user is banned from the given blog; all subsequent checks aimed to determining whether a user has been banned from commenting in a journal should use the existing tree, moving along the tree branches via simple dichotomy checks.
- 13 dichotomy checks are enough for 8192 bans, 16 checks for 65536 bans. Not a heavy strain, right?