@Makyen when logging into Metasmoke via SO to receive my FIRE token, it redirects to the dashboard and not the FIRE auth page like it used to. Was the returnurl parameter lost?
@Ollie If you have autoflag conditions set that are relatively close to the 99.75% threshold, just one or two autoflag FPs could change the accuracy of them to be below the minimum, which means that they're no longer accurate enough to be allowed to remain active by Charcoal's standards. We want our autoflag conditions to, based on previous autoflagged posts, be specific enough that your flags will be cast only when the post has a 99.75% chance of being TP.
Or higher, of course.
Some users set their conditions to be as "loose" as possible so their flags will be used in cases where other users' flags aren't.
You can have a bunch of conditions set. If any of them are true, a flag will be cast (I think, anyway?) I personally have two conditions, one is just for SO and one is for the rest of the network. My SO ones are more strict (higher weight required) because of how many crazy FPs we get on SO.
@Spevacus Yes, that's correct: If any of them match, then you are in the pool of people from which users to autoflag will be selected.
I agree, if you are wanting to have autoflag conditions set to lower criteria, then it's a good idea to have separate conditions for SO, because SO has a lot of posts detected with both more detection reasons and higher weights than tends to be the case on other sites. On most/all sites other than SO, you can get similar %TP numbers using substantially lower criteria than what is needed on SO.
@Ollie Specifically, this is sent to chat when metasmoke tests all of your flagging conditions together against all existing post records and finds that the overall combination does not meet the 99.75% TP requirement. This check is expensive, so it's not run all that often (e.g. not when you're editing your flagging conditions).
It's run on a schedule for everyone, once per day, at some times when MS considers it likely that things might have changed (e.g. when there's an autoflagged FP; which users are checked may be limited to those likely to be affected), or when manually triggered for a specific user by an MS admin.
@Makyen RE your edit to meta.stackexchange.com/a/126857/377214: I made some edits to simplify your added text and split it off into another section. What do you think?
@Mast API tokens are definitely private information. However, API keys are not generally considered private. While they are not something which is gratuitously shared, they are commonly included in public code. For example, all of our userscripts which use the MS API include an MS API key in the code, which are publicly viewable. If you'd like an MS API key for you own use, we're happy to provide you with one.
@gparyani Thanks for telling me. I had seen your edit. Unfortunately, I haven't had the time to actually re-read the whole thing. I did skim it when I saw that there had been an edit. When I did, I didn't see any glaring issues.
@Mast Yes. It would be, at best, very inconvenient if you had to keep them private. For many APIs (including the MS API and SE API), the API key is used to identify the application which is making the access. Having such keys allows the API provider to keep statistics of what accesses are being made, etc.
Such keys also allow the API provider to disable access by that application, which is quite beneficial if the application has a bug which results in using too many resources such that it affects other users of the API.
If something that's actually private, or otherwise required authorization (e.g. writing/changing/performing actions like flagging or providing feedback), then a token is required.
Such a token is obtained on a per-user basis through an action flow in which the user provides authorization. For the SE API the flow of actions that's used is the OAuth2 flow. For the MS API, it's very similar. The token is then held privately by the application instance that is owned by the user who obtained the token.
Such tokens should definitely not be shared, as the possession of the token allows all the access which the user has granted to the token (usually access to private data and/or writing/making changes/actions on the part of the user).
