@SmokeDetector same IP address ass dosepharmacy.com and friends but they seem to have moved to a different IP address now (they resolve to 35.197.227.153 for me)
@JeffSchaller That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
The quota_remaining property was not in the API response. Error: no method found with this name at 14:55:58 UTC. Backing off on requests for the next 12 seconds. Previous URL: https://api.stackexchange.com/2.2/questions?site=stackoverflow.com
@tripleee It could, but it, currently, only handles a single SE site, with no provision for getting data for multiple sites within a single chat page. FIRE would probably be a better choice, as it does already handle multiple sites, just not efficiently, and it's already a userscript which is generally run for Charcoal (and some code that might be adapted may exist, depending on what you want to have happen). However, what to do will really depend on what you're wanting the script to accomplish.
It is possible for scripts to, mostly, determine when responses to a report are "complete", and I have code in the development version of FIRE that, mostly, does that. It currently isn't fully accurate, mostly because people use tpu on posts which shouldn't actually be deleted, and determining which of those with a tpu shouldn't be deleted is less reliable.
In addition, I'm working towards having the MS recent posts page be able to display/not display if a report is "complete", which is intended to include deleted status, but currently doesn't.
@tripleee np. It's a non-trivial problem. At least for the watch/blacklist and seeing what is/isn't watched/blacklisted, it seems like the better solution would be to have things highlighted within the display of the post, rather than change the why data. Doing that would be substantially easier if the display of the post is the raw text, rather than a rendered view of the HTML (which often needs to be changed in order for it to display properly, due to SD irreversibly preprocessing the HTML text which is then stored on MS). I've considered adding tabs to FIRE in order to display the raw post text with highlighting (and potentially a few/several other tabs), but haven't done so, yet.
@Mast I'm not really sure what you're asking about. However, for the things which I think you might be asking about, no, it's not a performance issue. Do you mean the highlighting of the rendered HTML? The reconstructing of renderable HTML from the preprocessed HTML which is stored on MS (FIRE already does this for every post it displays)? The selection of what and how to format the why data such that it's easier to pick out the information which some particular person is looking for (most of the time)?
@Makyen "At least for the watch/blacklist and seeing what is/isn't watched/blacklisted"
"The selection of what and how to format the why data such that it's easier to pick out the information which some particular person is looking for (most of the time)"
I do not know what does and doesn't tax the current resources. I know running large lookups against MS can potentially hurt. I do not know whether userscripts like FIRE put strain on it as well.
The formatting is all done locally, ofcourse, but the data has to come from somewhere.
@Mast Well, part of what was requested would put a strain on MS, but that's the part about wanting to know the counts for prior number of matches within MS, because those would effectively require performing searches, which would then be being done by everyone, all the time, every time they view a post, which would be a substantial additional load on MS.
The primary difficulty with highlighting the rendered HTML from what's in the why data is that what is matched may include, partially or completely, the HTML tags themselves and/or cross boundaries into or out of different HTML tags, and/or be detecting attributes within the HTML tag (e.g. the value of the href attribute in an <a> tag). If what was desired to be highlighted was just text that was actually displayed, then that's relatively easy (been there, done that, multiple times).
That's why I said that it's substantially easier if what was being highlighted was the raw HTML text, rather than the rendered text. Because if what's being displayed is the raw HTML text, then there's no concern at all as to relationship between the the thing that is desired to be highlighted and the HTML tags.
[ SmokeDetector | MS ] Bad keyword in link text in body, link at beginning of body, potentially bad ns for domain in body, potentially bad keyword in body, potentially bad keyword in title (114): where to buy handguns online? by Benaquack 12 on skeptics.SE
[ SmokeDetector | MS ] Bad keyword in link text in answer, link at beginning of answer, potentially bad ns for domain in answer, potentially bad keyword in answer (118): where to buy handguns online? by Benaquack 12 on skeptics.SE
