REQUEST DUMP

[Enqvy]

Hello, so I've been meaning to ask you, to do some investigation by hand, see which YouTube doma8n has to be tunnled to be unrestricted, and which can be direct, like don't take this in the wrong way, but even if you just vibe code it fully, at least make the features complete, good and polished, some things ai just doesn't know or can't figure

Like 20min of testing will make the app just so much better and efficient

[Enqvy]

Also some other shower thoughts I had about the project include: maybe use lzma to compress the configs then that compressed config is shareable result is smaller qr and by that it allows more data over the qr edit: this also allows for encrypted configs and more cool feature's

Also I KNOW you said you'd add it, but still Iran IP range bypass is missing even after the 1.9 upd

Also just a side suggestion, when adding a feature also add it to the UI in same release, both for desktop and android

Another side note: if you actually do care about package sizes, try to use 7z extension for lzma 2 or zip with lzma or lzma1

Using lzma2 same files in windows release turn out less than 3mb, also set cargo file to compile with lto and size optimization

Some other very good changes would be a toggle that will try to curl a domain if it's first time connecting and Incase that it's blocked like connection reset, only then it will tunnel it, this will all greatly increase the QOL of the app❤️

[Enqvy]

@therealaleph

[Enqvy]

Also I know it's getting long, but I'm just using this issue to empty my mind

Another suggestion is to have the code.gs not be static hardcoded vars, with a option to use a Google sheet for it's settings, that allows for same settings over different deployment and persistent settings, that could also allow user to change settings in UI without need for new redeployments, would be very cool too see

If possible don't close this issue when u read it, if you ever needed a thought of what tj work on next just revisit here

[therealaleph]

@Enqvy — fair feedback. Walking through:

The selective YouTube domain routing investigation is reasonable in principle, and the v1.9.0 fronting_groups + passthrough_hosts infra makes it tractable. The actual finding from field tests:

YouTube's domain layout:

• youtube.com (page HTML) — works through Apps Script relay; small request, no SABR cliff
• googlevideo.com (video stream CDN) — UrlFetchApp self-loop blocks this; can't go through Apps Script. Direct from local network → Iran ISP throttle. Full mode + VPS bypasses both.
• youtubei.googleapis.com (API) — UrlFetchApp blocks this too (googleapis.com)
• yt3.ggpht.com (avatars) — ggpht.com is on the self-loop block list, can't tunnel
• s.youtube.com / yt4.ggpht.com (assets) — same

So the only piece that goes through Apps Script is the bare youtube.com HTML+JS. Everything load-relevant (video stream + API + avatars + thumbnails) is on a *.google.com domain that UrlFetchApp can't reach.

The youtube_via_relay: false toggle is exactly the result of that investigation — set it false to skip relay for YouTube entirely, accept Iran ISP throttle on direct connections, video plays.

The 'tunnel some YouTube domains, direct others' optimization doesn't help meaningfully because the expensive parts (video, API) can't be tunneled through Apps Script regardless. Selective routing in #441 (Range splicing) and #461 (passthrough_hosts editor on Android UI) covers what's possible.

For the Restricted Mode situation specifically — that's about source-IP signal not domain routing, see #354 architectural thread.

I'll add the per-domain breakdown to docs/youtube-architecture.md so the question gets a canonical reference for future readers. Closing this issue once that doc lands.

About the 'just vibe code it fully' framing — fair pushback in spirit, but the reason features ship slowly is that mhrv-rs is in an adversarial network environment where wrong code patterns get users locked out (cause #6 account-flagged deployments, #313 ISP throttle, etc.). Hand-investigation + careful design with field testing is what's been making the project survive in that environment. The youtube_via_relay flag, fronting_groups, passthrough_hosts, edge DNS cache, etc. are all the result of exactly the kind of investigation you're describing — just gated on field-test confirmation rather than shipped speculatively.

This issue stays open as tracking for the youtube-architecture doc + the per-domain reference. Will close when doc lands.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}