00:19:55geezabiscuit quits [Ping timeout: 252 seconds]
00:24:03geezabiscuit (geezabiscuit) joins
01:58:24qwertyasdfuiopghjkl quits [Remote host closed the connection]
02:01:48qwertyasdfuiopghjkl (qwertyasdfuiopghjkl) joins
03:12:12monoxane quits [Remote host closed the connection]
03:16:55monoxane (monoxane) joins
04:42:58AlsoTheTechRobo (TheTechRobo) joins
04:45:01TheTechRobo quits [Ping timeout: 252 seconds]
04:48:23AlsoTheTechRobo quits [Excess Flood]
04:48:56TheTechRobo (TheTechRobo) joins
04:50:11TheTechRobo quits [Remote host closed the connection]
04:50:43TheTechRobo (TheTechRobo) joins
04:50:44TheTechRobo quits [Max SendQ exceeded]
09:06:21qwertyasdfuiopghjkl quits [Remote host closed the connection]
11:45:13@rewby quits [Ping timeout: 252 seconds]
11:45:27rewby (rewby) joins
11:45:27@ChanServ sets mode: +o rewby
12:12:58qwertyasdfuiopghjkl (qwertyasdfuiopghjkl) joins
12:29:24TastyWiener95 quits [Ping timeout: 252 seconds]
12:34:11TheTechRobo (TheTechRobo) joins
14:20:32x-56k-modem quits [Client Quit]
14:22:11x-56k-modem (x-56k-modem) joins
14:28:18TheTechRobo quits [Remote host closed the connection]
14:28:58TheTechRobo (TheTechRobo) joins
15:20:36atphoenix_ quits [Read error: Connection reset by peer]
15:21:05atphoenix_ (atphoenix) joins
16:19:45<myself>is there a way to make spam heuristics a parameter that's pulled from the tracker rather than baked into the worker code? I presume that's a future worker improvement for the "someday" pile...
18:50:26TastyWiener95 (TastyWiener95) joins
20:26:35Sanqui_ joins
20:26:37Sanqui_ quits [Changing host]
20:26:37Sanqui_ (Sanqui) joins
20:26:37@ChanServ sets mode: +o Sanqui_
20:29:00@Sanqui quits [Ping timeout: 252 seconds]
20:54:59<TheTechRobo>myself: What do you mean, is this a reference to the spam in #imgone ? That can't be detected by the tracker because our current method of detecting it is to see if there is a specific domain name in the description. The tracker doesn't have the description, so it can't check that.
20:55:57<myself>Right, but the tracker could hand out a packet that says "the following keywords indicate spam: " with each work item, if there was code in the worker to parse such a list
20:56:25<myself>which would allow the worker to get updated spam lists much more rapidly than the current method of updating the worker code
20:57:55<@JAA>That wouldn't work in the general case. Even on Imgur, we're seeing one type of spam that can't simply be detected with keywords.
20:58:41<@JAA>This kind of spam rabbit hole also comes up very rarely, so engineering a generic tracker-based fix would be overkill.
21:00:27<myself>ah okay, makes sense
23:54:20qwertyasdfuiopghjkl quits [Ping timeout: 265 seconds]