Files
Simon 534ee4b5ad Add ripnsfw provider (Doodstream/Lulustream leak aggregator)
ripnsfw.com serves its entire catalogue as a published-Google-Sheet CSV
with no native pagination/search API, so the provider fetches and
parses that CSV once (cached 180s) and does feed/search/pagination/sort
in memory. Each row's Doodstream/Lulustream embed links resolve to
formats[] via the existing (previously unused) doodstream/lulustream
redirect proxies.

Also fixes check.py's follow_proxy_redirect, which used HEAD even
though these redirect-proxy routes only accept GET/POST, so it never
actually resolved the redirect; extends the CF-protected host list
(suffix matching + ripnsfw.com's client-only-SPA 404 page, dood.video,
tnmr.org) so known sandbox/CDN-IP-reputation failures are reported as
warnings instead of errors.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QTqf6orbHZ9rFFpVpcgzcR
2026-09-18 19:22:49 +00:00
..
2026-04-03 17:20:11 +00:00
2026-04-10 22:57:27 +00:00
2026-09-07 15:25:03 +00:00
2026-09-07 15:25:03 +00:00

Hottub Docs

This folder is the fastest handoff path for anyone adding or repairing a channel.

Start here:

  1. Read architecture.md for the server flow, request lifecycle, and core types.
  2. Read provider-playbook.md — its top "Best Practices (Living)" section is the cross-cutting rule set to internalize first, then follow the rest of the playbook for the exact process to add a new provider or proxy.
  3. Use provider-catalog.md to find the closest existing implementation to copy.
  4. Use docs/hottubapp/*.html when you need the client-facing API contract for status, videos, or uploaders.
  5. Only then touch prompts/new-channel.md; it assumes the docs above exist.

Recommended local workflow:

cargo check -q
HOT_TUB_PROVIDER=<channel_id> cargo check -q
HOT_TUB_PROVIDER=<channel_id> cargo run --features debug

Useful runtime baseline:

DATABASE_URL=hottub.db
RUST_LOG=info
PROXY=0
BURP_URL=http://127.0.0.1:8081
FLARE_URL=http://127.0.0.1:8191/v1
DOMAIN=127.0.0.1:18080
DISCORD_WEBHOOK=

Key facts:

  • Hottub is a Rust ntex server with providers under src/providers/.
  • build.rs controls compile-time provider registration.
  • /api/videos is the main provider execution path.
  • /proxy/... exists for sites whose direct media or thumbnails need a redirect/proxy layer.
  • Only three providers currently implement /api/uploaders: hsex, omgxxx, and vjav.
  • Uploader IDs should be namespaced like <channel>:<site-local-id> so /api/uploaders can route directly.