Проверьте, являются ли домен(ы) в сообщении действительными, предпочтительно перед публикацией. Если проверка домена не пройдена, пометьте сообщение для рассмотрения модератором.
Это не проверка ссылок.
Это не проверка адресов электронной почты.
Недавно было опубликовано сообщение, содержащее адрес электронной почты. По мере появления ответов факты, изложенные автором оригинального сообщения (OP), перестали сходиться. При проверке доменного имени не удалось найти зарегистрированный домен, например, через поиск в ICANN.
В связи с этим сообщение было скрыто из общего доступа.
Это может иметь очень узкое применение, но есть и законные причины указывать недопустимые доменные имена в публикациях.
Например, при обмене конфигурациями здесь, на Meta, вы можете не желать публично раскрывать адрес своего экземпляра. Также довольно часто приводят примеры структуры URL с использованием общих или несуществующих доменов.
Звучит как очень специфический набор обстоятельств. Не могли бы вы привести ещё какие-либо примеры?
Однако это плохая практика. Эти домены могут существовать и быть чем-то другим — или, что ещё хуже, могут появиться в будущем. В примерах следует использовать example.com, example.org или example.net. Это реальные домены, которые разрешаются и предназначены именно для таких целей.
Суть лучших практик в том, что новички с ними не знакомы. Создание препятствий при публикации в контексте вышеизложенного граничит с оторванностью от реальности. Помните, что стандартная установка настолько проста, что иногда установка Discourse может стать первой задачей пользователя, напоминающей работу системного администратора.
Мы не можем проверять владение доменом перед тем, как кто-то опубликует ссылку. Если пользователь делится конфигурацией с недопустимым доменом, как нам отличить опечатку от некорректно настроенного DNS или домена, который ещё не успел реплицироваться?
Если вы имеете в виду, как модератор может проверить это вручную: если поиск в ICANN не удался, отправьте личное сообщение человеку, задавшему вопрос, с просьбой предоставить детали. Именно так я и поступаю.
Похоже, что автор темы (OP) покинул сайт сразу после последнего сообщения, когда тема была скрыта. Большинство пользователей, чьи темы скрывают, обычно отвечают гораздо раньше, чем позже.
Пользователь зарегистрировался за несколько часов до публикации и также получил несколько предупреждений в этот период.
Не могли бы вы немного подробнее объяснить, как проверка домена помогла бы в теме, на которую вы ссылаетесь выше?
Автор оригинального поста не указал домен, только адрес электронной почты. Именно в вашем ответе в сообщении №11 упоминается домен .com, который, кстати, является зарегистрированным и активным доменом — он припаркован на Sedo. Если бы пользователь указал его, а проверка домена была бы проведена, система вернула бы корректную информацию WHOIS.
Мне не совсем понятно, как предложенное вами решение могло бы снизить нагрузку на модерацию в теме, на которую вы ссылаетесь.
Я понял свою ошибку; спасибо, что заставили меня применить отладку по уточнению.
Как человек, я распознал plausibleai как домен, но на самом деле это часть имени пользователя. Тем не менее, проверка домена была бы полезна, так как пользователи всё ещё пытаются передать недостоверные домены.
Честно говоря, это всё кажется мне больше проблемой XY, чем RDD.
Никто не хочет разбираться с последствиями злонамеренного поведения; попытка заманить пользователей вне сайта вполне может указывать на это. У Discourse есть много защитных механизмов против массовых действий спам-ботов, но такие точечные атаки всё ещё остаются на совести флагов сообщества и оперативных модераторов.
Если бы это была детерминированная задача, то проблема XY имела бы смысл, однако с LLM и обучением стоит попробовать. Возможно, это должно быть предложением Discourse AI, а не предложением новой функции.
Тем не менее, много спама всё ещё проходит. Детектор спама в основном ловит новых пользователей, которые пишут слишком быстро — это своего рода спам.
Поскольку это уходит от темы, я остановлюсь здесь.