Anonymous Edit

[pryrt]

Re: Challenge: Ricochet Robots was an anonymous post that was recently edited (emptied) with no janitation history. But Anonymous Monk cannot edit his own posts. After some back and forth in the CB, the best guess is that the post ran afoul of anti-spam AM-posts-with-links auto-cleaning. Which is fine... but it would be nice to be sure.

More importantly than this specific instance: should there be some sort of indication on such posts, whether in the janitation history or in the body of the emptied post, to indicate that it was auto-cleaned for potential spam? This would give people a chance to weigh in with a consideration-to-edit/restore: "no, I saw the content and followed the link before it was purged: it was a link to a A* algorithm implementation of this problem in another language, which doesn't seem like spam given the conversation". (It's obviously been fixed in this case, but I'm using my reaction to this case to explain the general idea)

[jdporter]

There is no auto-cleaning of node content, as far as I am aware. If the content runs afoul of our filters, the node cannot be posted. Of course, for logged-in users, they could post a clean node and then dirty it up in a subsequent edit; but AnonyMonk cannot do this, of course.

As for that node - I don't know; it has content now. Could it have been a server glitch?

[haukex]

I can confirm that the node looked completely empty to me as well. I even went into the XML view, and aside from the normal XML structure there, no content was included in that output either. Could this behavior be unintentionally linked to the recent change that the content of low-reputation nodes is hidden to non-logged-in users?

[LanX]

I doubt this, but I've noticed divine magic happening in the past. ;-)

[pryrt]

Could it have been a server glitch?

If it was, it was pretty long-lasting server glitch -- long enough for the cb conversation to confirm it was empty, etc. But if the filters block posting, and don't delete content, then that obviously wasn't the culprit -- and if the deletion-process doesn't exist, then we obviously don't need the deletion-process fixed. ;-)

Anyway, thanks for looking into it.