Как работают модерация, поиск и репутация на Kaspa Marketplace

Модерация Kaspa Marketplace — это трёхуровневая система: модерация контента на базе ИИ, срабатывающая до публикации любого объявления, полнотекстовый поиск на SQLite FTS5 для удобства покупателей и добровольная репутация продавцов, формируемая по результатам on-chain эскроу, а не по внутренним оценкам платформы. Ключевой архитектурный принцип: метаданные маркетплейса (заголовки, описания, фотографии, решения модерации) никогда не управляют средствами в эскроу. Объявление — это запись на доске объявлений; средства хранятся в отдельном on-chain ковенант-контракте. В этой статье мы разберём каждый уровень, их взаимосвязи и текущие ограничения.

SSR-рендеринг и поиск FTS5

Когда покупатель открывает маркетплейс, сервер рендерит объявления на стороне сервера. Эндпоинт GET /api/safe/market/share генерирует страницы с Open Graph-тегами — основа любого SEO-подхода для криптомаркетплейса, поскольку поисковые системы и превью в соцсетях видят реальный контент, а не JavaScript-оболочку.

Поиск работает на расширении FTS5 для SQLite. Таблица listings_fts индексирует title и description с использованием токенизатора unicode61 без диакритических знаков, поддерживая как латиницу, так и кириллицу. При поступлении запроса с непустым параметром q сервер направляет его через алгоритм ранжирования bm25 от FTS5 с двойным весом для поля заголовка. Префиксное сопоставление работает для обоих алфавитов: ввод «camer» находит «Camera», ввод «СЕРВ» находит «сервис». Пользовательский синтаксис FTS удаляется на этапе токенизации — покупатели не могут внедрять операторы FTS5 напрямую.

Если FTS5 по какой-то причине не работает — повреждение данных, ошибка токенизатора — система молча переключается на поиск по подстроке. Явная сортировка по цене сохраняется даже при поиске, поэтому покупатель, сортирующий по возрастанию цены, получит именно этот порядок независимо от релевантности.

Просмотр ограничен на уровне базы данных: limit всегда от 1 до 100 (по умолчанию 100), и вся фильтрация — категория, диапазон цен, регистронезависимая подстрока Unicode, сортировка, смещение, количество — выполняется внутри SQLite. Rust-сервер получает только страницу результатов.

Конвейер модерации на базе ИИ

Каждое создание или редактирование объявления переводит его в статус pending_moderation и немедленно возвращает управление продавцу. Устойчивый фоновый процесс (run_moderation_worker в listings.rs) обрабатывает все записи без вердикта, включая те, что остались после перезагрузки сервера.

Процесс отправляет текст объявления в совместимый с OpenAI эндпоинт /chat/completions с температурой 0 и системным промптом (MODERATION_SOUL), в котором явно перечислены категории для отклонения: спам, порнография, вредоносное ПО, фишинг, кража учётных данных, украденные аккаунты, пиратский контент и инструменты обхода доступа. Обфускация оценивается по смыслу, а не по ключевым словам. Спорные случаи получают вердикт needs_review вместо одобрения.

Для объявлений с фотографиями запрос направляется в специальный канал компьютерного зрения. Нечитаемые изображения понижают вердикт approved до needs_review. Все входные данные — текст объявления, EXIF/метаданные и текст, распознанный с изображений через OCR, — рассматриваются как ненадёжные. Промпт-инъекция не может изменить политику модерации или схему JSON-ответа.

Вердикт записывается одним защищённым SQL-обновлением:

approved  → status becomes `published`
rejected  → status becomes `rejected`
anything  → status stays `pending_moderation`

Третий вариант — отказоустойчивость: объявление молча не публикуется. Запоздалый ответ модели никогда не перезаписывает ручное решение человека. needs_review запускает уведомление в Telegram-бот арбитра.

Сбои транспорта, конфигурации или парсера запускают устойчивый механизм экспоненциальных задержек (по умолчанию 3 попытки с интервалами 15 и 30 секунд). После исчерпания попыток объявление остаётся неопубликованным и однократно помечается для ручной проверки.

Панели администратора

Две панели администратора используют единый авторизационный шлюз (admin_ok): веб-панель для десктопа за nginx basic-auth и Telegram Mini App внутри приватного бота арбитра. Шлюз принимает либо токен администратора, либо HMAC-верифицированный Telegram initData-пейлоад, привязанный к chat ID арбитра, с 24-часовой защитой от повторного использования.

Администраторы могут одобрить объявление — переопубликовав его с новым 30-дневным окном — или удалить его, стерев фотографии и установив статус deleted. Отклонённые объявления, не одобренные вручную в течение настраиваемого TTL (по умолчанию 24 часа), удаляются фоновым циклом безвозвратно.

Репутация продавцов: результаты on-chain, а не оценки платформы

Репутация продавцов в Kaspa является добровольной и по умолчанию отключена. Маркетплейс анонимен по своей архитектуре — каждое объявление использует свежие ключи, поэтому между объявлениями продавца нет внутренней связи, если он не подключится к системе репутации.

Подключение работает через протокол запрос-ответ. Desk выводит ключевую пару репутации из мастер-сида (домен kaspaforge/v1/reputation/0, индекс 0), запрашивает nonce у сервера и возвращает подпись BIP340. Эта ключевая пара криптографически отделена от идентичности Desk Sync — другой домен вывода, никакой корреляции.

Привязка сделок работает только вперёд. При создании объявления Desk прикрепляет аттестацию, привязывающую публичный ключ репутации к ключу продавца. Сервер проверяет это перед созданием сделки и записывает связь в таблицу rep_links. Ретроспективная привязка невозможна — это предотвращает выборочное подключение только к удачным сделкам.

Классификация результатов из блокчейна

Сервер не знает, каким образом был закрыт эскроу. Арбитр выносит решение офлайн; вердикт ИИ-медиатора носит справочный характер. После закрытия сделки эскроу наблюдатель считывает транзакцию расходования из индексера и извлекает селектор пути ковенанта из скрипта подписи:

0 = release       1 = refund        2 = mutual
3 = dispute       4 = autoRelease
5 = arb→buyer     6 = arb→seller    7 = arb→split
8 = timeout       9 = timeout

Перекрёстная проверка структуры выходов формирует outcome_kind, pct и src в таблице сделок. Сервер повторяет попытки в течение 48 часов; если результат не удаётся определить, он помечается как unknown. Это работает только в основной сети.

Агрегированные метрики — успешные сделки, возвраты, споры с разбивкой, общее количество сделок, дата подключения — кэшируются с TTL 60 секунд. Промахи кэша для одного и того же rep_pk объединяются в один запрос, чтобы избежать лавинного обращения. Ограниченный кэш вытесняет самые старые записи без полной очистки.

Продавцы управляют репутацией через Desk → Settings → Seller rating: включить, приостановить (значок скрыт, история накапливается) или удалить (необратимо, целиком — нельзя выборочно стереть споры). Продавец, удаливший и заново подключившийся с той же ключевой парой, начинает с нуля.

Почему метаданные маркетплейса никогда не касаются средств в эскроу

Это важнейший архитектурный принцип системы.

При создании объявления сервер создаёт черновую сделку эскроу через тот же путь Deals::create_deal, что используется автономным Kaspa Escrow — параллельной логики работы с деньгами нет. Случайный 12-символьный join_code связывает объявление со сделкой.

Когда покупатель оформляет заказ (POST /api/safe/listings/:id/checkout), сервер создаёт отдельную сделку с новым request_id и записывает идемпотентную связь в listing_orders. Повторные запросы с тем же request_id возвращают тот же join_code.

Редактирование объявления атомарно отзывает старый join_code и все неиспользованные возможности заказа покупателя, переносит ссылки на фотографии и возвращает объявление в pending_moderation. Старые условия невозможно приобрести по скопированной ссылке. Любой профинансированный заказ покупателя или профинансированная каноническая сделка полностью блокирует редактирование — проверка выполняется в рамках той же транзакции SQLite.

Для повторяемых (repeatable) объявлений наблюдатель автоматически переиздаёт объявление на новой сделке после каждого финансирования. Для одноразовых объявлений финансирование переводит статус в reserved, а завершение сделки закрывает объявление.

Если сервер маркетплейса выходит из строя, незавершённые сделки эскроу сохраняются в блокчейне. Пути ковенанта — освобождение, возврат, спор, тайм-аут — обеспечивается консенсусным слоем Kaspa (вики Kaspa), а не маркетплейсом. Это гарантия некастодиальности: модерация маркетплейса может отклонить объявление, но не может заморозить, перенаправить или конфисковать KAS в эскроу.

Компромиссы и честные ограничения

• Модерация на ИИ — это фильтр, а не гарантия. Система выявляет очевидные нарушения правил и помечает спорные случаи для ручной проверки, но настойчивый нарушитель может составить объявление, прошедшее автоматическую проверку. Именно для этого существует уровень ручного арбитража. Область цифровой политики намеренно узкая: допускаются только легальные цифровые продукты.

• Добровольная репутация означает, что отсутствие значка ≠ плохой продавец. Система намеренно не наказывает анонимность. Свежие ключи для каждого объявления — это функция приватности, а не недостаток. Покупателю стоит оценивать объявление, условия эскроу и окно спора — а не только значок.

• Поиск FTS5 — одиночный экземпляр. Он быстр на текущем масштабе, но это не распределённая поисковая система. Молчаливый откат к поиску по подстроке гарантирует, что поиск никогда не сломается полностью, ценой потери ранжирования по релевантности.

• Объявления истекают через 30 дней — фильтрацией при просмотре, а не изменением статуса. join_code умирает вместе с объявлением — истёкшее объявление возвращает 404 на get_listing. Продавцы могут продлить из статуса published, а Desk предупреждает за три дня до истечения.

• Перекодировка фотографий удаляет все метаданные — EXIF, IPTC, XMP, включая GPS и модель камеры — и ограничивает длинную сторону 2400 пикселями. Это защищает приватность продавца, но означает, что оригинальное качество не сохраняется. Контентно-адресуемое хранилище (photo_id = sha256 нормализованного JPEG) обеспечивает дедупликацию и неизменяемое кэширование с Cache-Control: public, max-age=31536000, immutable.

• Счётчики просмотров — внутренние. GET listings/:id увеличивает счётчик views, но это поле не возвращается публично и не изменяет updated_at. Только владелец объявления видит количество просмотров через GET listings/mine.