@Shree That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer; append -force if you really want to do that.
[ SmokeDetector | MS ] Bad keyword in body, blacklisted website in body, body starts with title and ends in url, link at end of body, pattern-matching product name in body, +3 more (591): Intensex** IntenseX Manly Enhancement by golikplop on superuser.com
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, pattern-matching product name in body, pattern-matching website in body, potentially bad ns for domain in body (393): Mydxadryl Male Enhancement CA by kdbdkass on apple.SE
@Magisch Lambda isn't even playing the same game wrt reliability concerns. Going to pull cost numbers, but reliance on me isn't always a bad thing. Only when my incompetence can get in the way, which it probably can't with Serverless stuff.
Somewhat doubt it'd be effective, but could be wrong
I tend to think that if there's a way to better harness the engagement we already have, it'd be best to put effort toward that rather than balancing a gamification thing.
@Undo If you post them as additional chat messages, please use URLs containing the MS post ID, not the site/SE post ID. For SE posts with multiple MS posts, the only way for the userscripts to guess at what MS post is actually intended is to match up the date/time of the chat message to when the MS post was created. If you're posting additional messages that don't correspond to the MS creation date, there's no way for the userscripts to accurately determine the MS post w/o the MS post ID.
I got a good start, but I gotta run. If y'all have time and want to poke, I'm leaving my stuff in a posts_redis branch. It needs some redis debugging, then the actually view-side stuff. cc @ArtOfCode @Undo
@ArtOfCode As to comments, is there a reason the /api/v2.0/comments/post/:id write route is Smokey-only? I haven't actually tried it (and actually implementing anything is a ways away), but I've wondered why that's restricted to SD. Currently, comments are only by replying to an SD post or entering it on MS. Neither are very convenient from a programmatic standpoint. Even a !!/comment msPostID comment command would help.
@Makyen That pattern looks like it's already caught by Potentially problematic ns configuration in answer and Potentially problematic ns configuration in body; append -force if you really want to do that.
@K.Dᴀᴠɪs So far (at least in this session), I've only gone through the last few hours worth of reports that haven't gotten enough response when they showed up in the room. There were about 40–50 more reviews in the queue than when I'd last looked several hours ago.
@Makyen Smokey-only because it lets you create comments as any user just by specifying their ID. I'd need to create another route that lets you use an access token.
@Undo Thoughts on doing traffic logging for MS? Thinking something like this, logging full details for 4xx and 5xx codes and just basic "this request happened" for everything else
