Материал из Tkabber Wiki
Содержание
Вступление
Kostix 03:32, 15 декабря 2006 (MSK)
Это нечто вроде Request For Comments на реализацию "MUC Ignoring" в Ткаббере.
Реализация оказалась не настолько простой, как я изначально предполагал: есть некоторые проблемы "теоретического" характера, которые и предлагается обсудить желающим. Выдвигайте варианты.
Минимум теории
Комнаты в XMPP делятся на три группы по "видимости" реальных JID'ов участников для остальных участников:
- полностью анонимные — реальные джиды не видны никому;
- полуанонимные — (дефолтный тип комнаты в "ёжике") — все модераторы (role == moderator), в том числе и временные, видят джиды всех участников; единственное отличие временных от постоянных в том, что они видят джиды лишь тех, кто вошёл в комнату в течение времени, пока они у "руля");
- неанонимные — все видят реальные джиды всех.
Сообщения в комнату node@server от юзера с ником nick приходят от джида node@server/nick, то есть это полный джид.
В соответствующих типах комнат те участники, которым разрешено видеть реальные джиды других участников, вместе с присутствием "доступен" от участника комнаты получают и его реальный джид.
Реализация
Идея (в формулировке Teo):
- Раздельный игнор сообщений в комнату и приват:
- Сообщения в комнату от игнорируемого участника помещаются, но скрываются; снятие игнора "показывает" сообщения, и наоборот;
- Сообщения в приват от игнорируемого участника молча удушаются.
Ткаббер умеет прекрасно просекать смену ника участником в комнате, то есть смены ника не мешают обоим игнорам, т. к. механизм игноров отслеживает их.
Требуется хранить правила игнора между сеансами работы Ткаббера. Предполагается хранить правила (логически) в таком виде:
SESSION_JID1
- ROOM_JID1 (комната анонимная)
- NICK1
- NICK2
...
- ROOM_JID2 (комната анонимная)
- NICK1
... - NICKN
...
- NICK1
- ROOM_JID1 (комната анонимная)
SESSION_JID2
- ROOM_JID1 (комната неанонимная)
- REAL_JID1
... - REAL_JIDN
...
- REAL_JID1
- ROOM_JID1 (комната неанонимная)
! "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 - мне кажется хорошим решением. Может вместо формального диалога редактирования правил сделать просто ещё одну группу «Игнор», вдобавок к «Модераторы» и «Участники» в списке участников конференции? И добавить возможность перетаскивать ники в/из этой группы.