Надёжность трейдов SkinsArena: анализ расширений + план «лучшее из обоих»

Подготовлено по задаче Александра (22.06.2026): разобрать их расширение (cs-skins.pro), наше расширение и всю серверную работу со Steam — и дать чёткий план, как объединить лучшее.

0. Главный вывод (если коротко)

Наше расширение по возможностям уже мощнее их: оно и опрашивает Steam в браузере, и САМО создаёт трейд продавца, и биндит токен на сервер для подстраховки. Их расширение проще — только опрашивает и шлёт изменения по сокету, а трейд создаёт их сервер.

Наши реальные проблемы не в «у них есть что-то, чего нет у нас», а в надёжности: серверный токен протухает когда юзер офлайн; обновление по сокету заменено на опрос раз в 1.5 мин; service worker засыпает; refresh-токен часто пустой. Плюс была денежная дыра в отмене по таймауту — уже исправлена.

План ниже = взять у них надёжность (свежий токен + реалтайм по сокету), оставить наши преимущества (двойной детект клиент+сервер, авто-создание трейда), и закрыть офлайн-кейс «вырубился свет».

1. Как устроено ИХ расширение (cs-skins.pro «Trading Assistant v2»)

2. Как устроено НАШЕ расширение

3. Наша серверная работа со Steam (как есть)

МеханизмКлючВидит P2P?Что делает
seller-steam:poll-trades (раз/мин)токен продавцаДАвидит принятие → ставит на 7-дн холд (PlaceDealOnEscrowHold)
deals:poll-steam-trades (раз/5 мин)платформенный STEAM_API_KEYНЕТпринят→холд, мёртв→отмена, таймаут (тут была дыра)
deals:cancel-unsent (раз/мин)отменяет «оплачено» без оффера через 15 мин
deals:settle-escrow-holds (раз/час)токен продавца (осн.) / ключ (fallback)после холда: подтверждённо доставлено→выплата продавцу; мёртв→отмена; неясно→ждём
seller-steam:refresh-tokens (раз/сутки)refresh_tokenобновляет access_token (GenerateAccessTokenForApp). Падает если refresh пустой/протух (401)

Жизненный цикл сделки: created → paid → trade_sent → trade_accepted (холд 7д) → completed (или cancelled). Деньги покупателя висят в hold до завершения; продавцу выплачиваются только после подтверждённого холда. Сервер трейд не создаёт — только записывает trade_offer_id и валидирует, что оффер реально соответствует сделке.

4. Сильные и слабые стороны

ИхНаше
Свежесть токенавсегда свежий (из cookie каждый опрос)серверный протухает офлайн; refresh часто пустой
Скорость детектареалтайм (websocket, ~сек)опрос 1.5 мин (+SW засыпает)
Двойной детект (клиент+сервер)только клиенти клиент, и сервер
Авто-создание трейдасервер (нет кнопки)расширение (createTradeOfferFromSession)
Работа при офлайн-юзерезавязано на онлайн-браузерсервер может, но токен протухает
Денежные дыры?блайнд-отмена + гонка закрыты 22.06

5. Что уже сделано (22.06, в проде)

6. План «лучшее из обоих» (по фазам)

Фаза 1 Реалтайм вместо опроса (быстро, низкий риск)

Фаза 2 Свежий токен + офлайн-подстраховка (главное на надёжность)

Фаза 3 Авто-создание трейда без кнопки (решение принято)

Решение Александра (22.06): сервер сам создаёт и шлёт трейд по сессии продавца (кнопка «передать» уходит), а продавцу падает уведомление/алерт — «подтверди обмен в Steam Guard (в мобильном приложении)». Мобильное подтверждение делает продавец руками, мы его об этом уведомляем.

Что делаем:

  1. Сервер по сессии продавца (cookies steamLoginSecure + sessionid, которые отдаёт расширение) формирует и постит трейд-оффер покупателю — автоматически после оплаты.
  2. Если Steam требует подтверждения (флаг needs_confirmation / state=9) — сервер ставит сделке статус «ждёт подтверждения продавца» и шлёт алерт продавцу: в карточке сделки + угловой тост по сокету + (опц.) уведомление расширения. Текст: «Подтверди обмен в Steam Guard на телефоне».
  3. Продавец подтверждает в мобильном Guard → дальше детект принятия покупателем по Фазам 1–2.

Остаётся учесть бан-риск Steam (серверная отправка трейдов от имени игроков): лимиты на аккаунт, «человеческие» паузы между офферами, бэкофф при ошибках Steam. Заложим в реализацию.

Фаза 4 Чистка серверных проверок

7. Приоритеты

  1. Сделано: закрыта денежная дыра (блайнд-отмена + гонка).
  2. Фаза 1 (реалтайм по сокету) — быстрый и заметный выигрыш, низкий риск.
  3. Фаза 2 (свежий токен + офлайн-подстраховка) — закрывает «вырубился свет», главный по надёжности.
  4. Фаза 4 (чистка проверок) — параллельно/после.
  5. Фаза 3 (сервер создаёт трейд без кнопки + алерт «подтверди в Steam Guard») — решение принято; делаем с учётом бан-риска (лимиты/паузы).