Support hour-long uploads and videos: raise body limit, stream uploads to disk, cache up to 3 h, add deferred-ideas note

docs/deferred-ideas.md

@@ -0,0 +1,34 @@
+# 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.