# Deferred ideas

Parked on purpose; nothing here is built.

## Cloudflare Worker as a YouTube fetch fallback (deferred 2026-10-01)

Idea: a free Cloudflare Worker (e.g. https://gist.github.com/hizkifw/ae229eb0c5ff809fc2a4a88735bfd604)
that fetches the watch page, decodes the signature cipher and streams a chosen
`itag`, so downloads come from somewhere other than the server's single IP.

Why it was not adopted yet (read from the gist, never deployed or tested):
- The fetch still happens from Cloudflare's datacenter egress, which YouTube
  often challenges or blocks; the IP is shared with every other Worker.
- It uses the old watch-page + cipher approach (ytdl-core). No PO tokens, no
  throttle handling, adaptive formats only, so it breaks as YouTube changes.
- Free tier CPU (~10 ms/request, check current limits) may not cover decoding
  the player script, and proxying large media may breach Cloudflare's terms.
- Stream URLs are bound to the fetching IP, so the Worker has to relay the
  bytes itself.

If revisited: deploy with `wrangler`, test ~10 real videos, and if it works add
it as the last tier behind an env var (`YT_WORKER_URL`): server cache → server
yt-dlp → Worker, with the result going through `validateMedia`. A newer Worker
could use the Android/iOS client endpoints (no cipher) but hits the same IP and
token blocks.

## Device-side download (Android app) (deferred 2026-10-01)

A web page cannot fetch googlevideo.com (CORS, PO tokens), and a yt-dlp WASM
build does not change that. The workable route is an Android app that runs
yt-dlp (or an equivalent extractor) on the phone's own IP, checks the server
cache first, then uploads the finished file in the background through the
device intake (`POST /api/p2p/intake`, `server/p2p-intake.js`). The server's
yt-dlp stays as the fallback when the device fails.

## Client-side video editing with ffmpeg.wasm (deferred 2026-10-02)

Skipped on purpose. ffmpeg.wasm is about 25–30 MB, and fast (multi-threaded)
use needs cross-origin isolation (COOP/COEP). That would break the YouTube
thumbnails and avatars unless every image host sends CORP headers, and we do not
control `i.ytimg.com` / `ggpht.com`. The server already trims video (edit & download
runs ffmpeg there), so the browser gains nothing it needs. Revisit only if offline
editing becomes a requirement; then load it lazily from a worker and measure the
isolation fallout first.