REQUEST DUMP

[4clsd]

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

[4clsd]

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❤️

[4clsd]

@therealaleph

[4clsd]

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]}

[4clsd]

Also, 8 recently tried out mhr-cfw project, and it is Meaningfully faster than mhrv, like by a LONG SHOT

I th8nk the way they relay YouTube might be different? But it's much faster and better, sadly it has no mobile port, maybe you could port the python project to mobile, but as a fork so backend remains mostly unchanged, but with a python mobile frontend, would be very sick

[therealaleph]

Reviewed via Anthropic Claude.

@Enqvy — speed gap with mhr-cfw closed significantly in v1.9.15+:

• v1.9.15 (PR feat: HTTP/2 multiplexing on relay leg with idempotency-safe h1 fallback #799): HTTP/2 multiplexing on the ALPN-supporting Apps Script edge — single TLS conn carries N concurrent streams instead of opening N TCP/TLS handshakes per request.
• v1.9.16: tunnel-node batch budget fix (updating steam on full mode #863) — eliminates 50 MiB truncation + restart cost on big downloads.
• v1.9.17: CORS response header injection (idea from ThisIsDara/mhr-cfw-go) — fixes YouTube comments / restricted-mode that was making YouTube appear slower because requests were hard-failing in the browser.

mhr-cfw uses Cloudflare Workers as the relay backend (much closer edge than Apps Script + no daily quota), so on raw throughput per request it's structurally faster. mhrv-rs has different design tradeoffs — Apps Script is free + survives YouTube/X DPI better than CFW edges that some Iranian ISPs flag.

Set in your config to maximize:

{
  "parallel_relay": 2,
  "enable_batching": true,
  "force_http1": false,
  "block_doh": true,
  "block_quic": true
}

…with multiple script_ids for round-robin.

Closing as expected (different relay backend, different speed ceiling). If you hit specific slow paths in v1.9.17, file with RUST_LOG=debug log + URL pattern — those are addressable.