41 lines
1.5 KiB
Markdown
41 lines
1.5 KiB
Markdown
# 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:
|
|
|
|
```bash
|
|
cargo check -q
|
|
HOT_TUB_PROVIDER=<channel_id> cargo check -q
|
|
HOT_TUB_PROVIDER=<channel_id> cargo run --features debug
|
|
```
|
|
|
|
Useful runtime baseline:
|
|
|
|
```dotenv
|
|
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.
|