Files

Simon c244461d0b Resolve melonstube's top-20 destination hosts into direct formats

melonstube is a meta-search aggregator that redirects out to ~120
third-party hosts. A live crawl of /new, /popular, and /rating
(~3,350 out-links) found the previous "assume yt-dlp can resolve it"
fallback was hiding real failures on the highest-traffic hosts:

- eporner.com is ~34% of all melonstube traffic by itself, and like
  the eporner channel (fixed earlier), serves a restricted preview
  clip without its hash/xhr dance.
- fapcat.com/momvids.com 403 a plain fetch (Cloudflare).
- Several others just needed real extraction instead of a guess.

Per-card enrichment now dispatches by destination host to:
- Eporner: reuses eporner's own hash/xhr + Referer resolution, moved
  to src/util/eporner_resolve.rs so both providers' single-provider
  builds still compile (HOT_TUB_PROVIDER=<id> only compiles the one
  selected provider module; src/util/* always compiles).
- Kvs (pornfreenow, analdin, babepump, w1mp, fetishshrine, pervclips,
  xozilla, ok.xxx, ebonypeek, xgroovy): a shared get_file extractor,
  the same KVS backend several other Hot Tub providers already scrape.
- KvsCfGated (fapcat, momvids): same extractor via the Safari18
  bypass client melonstube.com itself already needs.
- XhamsterMirror (xh.partners): a genuine xHamster mirror instance,
  Referer built from the actual resolved host.
- SomePorn: HLS playlist URL built from the page's video id directly.
- Pornone: direct <source> tag extraction.

flirt4free.com (a live-cam page, not a VOD) moved into the dropped-
host bucket alongside the existing junk/join.* hosts.

Enrichment is bounded (concurrency, a 10s per-card timeout, and
capped to the requested perPage rather than the full ~240-card page)
so a slow or rate-limited destination can't stall the response.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-22 08:28:05 +00:00

hottubapp

docs

2026-04-03 17:20:11 +00:00

architecture.md

docs and prompt

2026-04-10 22:57:27 +00:00

provider-catalog.md

Resolve melonstube's top-20 destination hosts into direct formats

2026-09-22 08:28:05 +00:00

provider-playbook.md

more providers

2026-09-07 15:25:03 +00:00

README.md

more providers

2026-09-07 15:25:03 +00:00

README.md

Hottub Docs

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

Start here:

Read architecture.md for 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.md to find the closest existing implementation to copy.
Use docs/hottubapp/*.html when 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 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.