ytplayer/docs/deferred-ideas.md

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.