Tkabber Wiki

MUC Ignore
Login

MUC Ignore

Материал из Tkabber Wiki

Содержание

Вступление

Kostix 03:32, 15 декабря 2006 (MSK)

Это нечто вроде Request For Comments на реализацию "MUC Ignoring" в Ткаббере.

Реализация оказалась не настолько простой, как я изначально предполагал: есть некоторые проблемы "теоретического" характера, которые и предлагается обсудить желающим. Выдвигайте варианты.

Минимум теории

Комнаты в XMPP делятся на три группы по "видимости" реальных JID'ов участников для остальных участников:

Сообщения в комнату node@server от юзера с ником nick приходят от джида node@server/nick, то есть это полный джид.

В соответствующих типах комнат те участники, которым разрешено видеть реальные джиды других участников, вместе с присутствием "доступен" от участника комнаты получают и его реальный джид.

Реализация

Идея (в формулировке Teo):

Ткаббер умеет прекрасно просекать смену ника участником в комнате, то есть смены ника не мешают обоим игнорам, т. к. механизм игноров отслеживает их.

Требуется хранить правила игнора между сеансами работы Ткаббера. Предполагается хранить правила (логически) в таком виде:

! "SESSION_JID" это "наш" джид подключения.

Идея такая, что для игнорируемого участника хранится реальный джид, если он доступен, в противном случае -- ник.

Обоснование: реальный джид намного "стабильнее", чем ник; несмотря на то, что ник может быть зарегистрирован, никакого способа узнать об этом факте, по-видимому, не существует; как минимум, — в Ткаббере.

Проблемы

Ненадёжность (нестабильность) ников

Засранец легко может генерить ники вида "freak01 ", "freak02", "freak03" и реально игнор будет полезен только пока засранец не покинул комнату. После этого смысл хранить забаненным ник "freak03" в такой-то комнате представляется сомнительным — при следующем сеансе работы этот ник в этой комнате может не иметь никакого смысла.

С другой стороны, если в комнате есть, скажем, просто очень скучная персона, флудер и т.п., с постоянным ником, хранение подобного правила имеет смысл.

В Customize есть опция "transient_rules" — если она включена, правила не сохраняются.

Также: какой ник сохранять в правилах, если недоступен реальный джид, — тот, который заигнорили, или тот, который засранец имел при выходе из комнаты/нашем от неё отключении?

Если сохранять "первый" ник, то нужно либо сразу флашить правила в базу данных Customize, либо запоминать этот первый ник, если база сбрасывается в какой-то другой момент (см. ниже про UID).

Текущая реализация: запоминаем текущий ник или реальный джид, если доступен; флашим базу Customize.

"Запачканные" ники

Kostix 03:00, 17 декабря 2006 (MSK) обновление реализации:

"Сокрытие" сообщений от засранца в комнате делается заключением всего сообщения в тэг вида

IGNORED-$id

с -elide 1, где $id -- некий уникальный в пределах сессии идентификатор засранца; при переименовании засранца его идентификатор не меняется.

Остаётся проблема: если за время пребывания в комнате засранец сменил несколько ников, то если мы перезайдём в комнату, нам прилетит история, в которой могут быть сообщения с этих ников; при этом игнорированы будут только сообщения, пришедшие с текущего ника игнорируемого, если он в данный момент находится в комнате.

Бороться с этим злом, видимо, нельзя, т.к. с сообщениями истории реальные джиды не передаются, даже если они доступны. Хранить историю смены ников — глупо, т. к. опять встаёт проблема "запачканных" ников: что если в комнате появится нормальная персона, взявшая себе один из таких ников?

C'est la vie.

Переконфигурации комнаты

Уровень анонимности комнаты может меняться; текущая версия ёжика не умеет генерить уведомления об этом, а ткаббер не умеет их просекать, так что проблема "рантайма" нас (пока) не интересует. Интересует проблема соотношения сохранённых правил и новой конфигурации комнаты.

Интересны 2 случая:

Прямолинейный подход — хранить и комнатный, и реальный джиды, если возможно, — страдает от той же проблемы: связь между этими джидами можно проверить только при наличии доступа к реальным джидам. Кроме того, это затрудняет хранение правил.

Текущая реализация: храним либо реальный джид, либо -- ник; первый имеет преимущество. На проблемы с переконфигурацией плюём, руководствуясь принципами бритвы "brAun Occam". :) Кроме того, скорее всего будет приделан диалог формального редактирования правил, при помощи которого можно будет обороть такие проблемы.

Вопрос: не следует ли хранить вместе с джидом комнаты статус её анонимности и каким-либо образом пердуперждать пользователя, если он изменился с момента последнего сохранения правил? (Выглядит разумным компромиссом.) Собственно, не мудрствуя лукаво: факт доступности реального джида во время обработки присутствия от первого же присутствующего позволяет узнать изменился ли статус анонимности комнаты.

Archimed 17:06, 18 декабря 2006 (MSK)

Хранить статус комнаты вместе с её JID - мне кажется хорошим решением. Может вместо формального диалога редактирования правил сделать просто ещё одну группу «Игнор», вдобавок к «Модераторы» и «Участники» в списке участников конференции? И добавить возможность перетаскивать ники в/из этой группы.