✨ Add rule to resolve appeal on removed record #739
Conversation
adds a spam label to accounts that are under 24 hours doing this, otherwise just reports. maybe too hasty on the label, can adjust. (note our client really doesn't make it easy to make an identical post multiple times in a row like this, where even failures will usually close the composer anyway, so its likely to be intentional). same could probably be applied for same author but with a maybe higher limit
- [x] remove footer - [x] fix double-rendered error page - [x] fix unknown lexicons not listing - [ ] link-ify AT-URIs in JSON - [ ] better table aesthetics - [ ] better aesthetics generally
|
I'm nervous about the volume of requests we'll need to make to ozone: a request on every post deletion would be a lot. One way to reduce the volume would be to track appeals with a flag (using automod flagstore, based on redis), or a counter, and then do a check in the rule, and only update in those cases. This would, of course, only work for new appeals, not any backlog of appeals. I think we should basically always add mod actions for both accounts and records at the same time, so should have "resolve appeal" on account in addition to record in this PR, even if we only use the record version. I'm adding metadata population of appeal status to account metadata in a parallel PR, so we'll be able to check that at runtime if ever needed (eg, on account deletion). |
Little hack to make `goat` work better with generic record data, aka when we don't know the Lexicon. In this context, just dumping the JSON to stdout (pretty printed). Sharing b/c we might want to do this generally, at least for API endpoints: `json.RawMessage` instead of `lexutil.LexiconTypeDecoder` when we encounter `unknown` schema type. Note that this won't work for records, and the schema rules do allow `unknown` in records, it just hasn't happened yet. Another place we encounter this is DID documents, which don't even have `$type` in the JSON.
…743) This ensures that only one larger allocation is done instead of multiple small ones, reducing pressure on the garbage collector.
at least in datadog, the structured logging 'host' field clobbers host metadata for the log line. this might not impact loko, but seems reasonable to just avoid the naming collision generally.
No description provided.