I'm studying for exams at the moment, but when that is done I'll get started. In the meantime, my thinking on the design of the anti-samefag mechanism as described in
>>11535 is starting to take form, but almost none of my programming experience has been concerned with web development.
While all my database experience is with MySQL, I'm going to assume thatthe fundamentals are similar to Mongo. Message data would be parsed on the client rather than the server during a post to search for all strings containing two '>' characters followed by a string numbers. This data would be stored in a table that keeps track of the userID, user post number, and one of the quoted post numbers so long as it already exists as a user post number. Before becoming a record, each quoted post number is checked against the user post numbers that share the same userID, and if this returns true too many times, then the user ID is enabled. Such a system would only be implemented on threads with low velocity, if thread velocity is a metric measured here. In events of spam, where the UID/Post ratio is very high, all (1)s without any replies (as these are the most likely to be spamposts) would be given a special ID for filtering. Some genuine posts would be caught up in it, but for the moment it would work. This is something that might be fine-tuned by factoring in the ASN, but it wouldn't do much good with very large botnets.
I'd like to discuss other possible metrics that could be examined to evaluate samefags and spamfags that wouldn't be too computationally taxing.
>>11539
You could probably have a bracket system where depending on the size of the thread, different prevention and mitigation systems are enabled/disabled. Sounds like a lot of work, but it's easy enough to conceptualize.