c7ae89fc37
melonstube.com started fronting itself with Cloudflare bot management (a real Turnstile challenge) since this provider was written, so the shared Requester's Firefox151 emulation got blocked on every path and the provider returned 0 items. A/B-probed several browser TLS fingerprints live: Chrome120/124 pass the plain listing pages but still 403 on /category/* and the /searching/by-form search POST, while Safari18 passes everywhere. Listing/search fetches now try a dedicated Safari18-emulated client first and fall back to the shared Requester if Cloudflare's rules change again (same pattern as lulustream.rs/doodstream.rs). Also fixes get_videos ignoring perPage entirely (always returned the full ~120-card page); it now truncates to the requested size. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QTqf6orbHZ9rFFpVpcgzcR
Hottub Docs
This folder is the fastest handoff path for anyone adding or repairing a channel.
Start here:
- Read
architecture.mdfor the server flow, request lifecycle, and core types. - 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. - Use
provider-catalog.mdto find the closest existing implementation to copy. - Use
docs/hottubapp/*.htmlwhen you need the client-facing API contract for status, videos, or uploaders. - 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
ntexserver with providers undersrc/providers/. build.rscontrols compile-time provider registration./api/videosis 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, andvjav. - Uploader IDs should be namespaced like
<channel>:<site-local-id>so/api/uploaderscan route directly.