Repository navigation
REQUEST DUMP #553
Description
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
Activity
4clsd commentedon Apr 30, 2026
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 commentedon Apr 30, 2026
@therealaleph
4clsd commentedon Apr 30, 2026
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
[-]important requests[/-][+]REQUEST DUMP[/+]therealaleph commentedon May 1, 2026
@Enqvy — fair feedback. Walking through:
The selective YouTube domain routing investigation is reasonable in principle, and the v1.9.0
fronting_groups+passthrough_hostsinfra 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 cliffgooglevideo.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.comis on the self-loop block list, can't tunnels.youtube.com/yt4.ggpht.com(assets) — sameSo the only piece that goes through Apps Script is the bare
youtube.comHTML+JS. Everything load-relevant (video stream + API + avatars + thumbnails) is on a *.google.com domain that UrlFetchApp can't reach.The
youtube_via_relay: falsetoggle 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.mdso 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 commentedon May 5, 2026
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 commentedon May 7, 2026
Reviewed via Anthropic Claude.
@Enqvy — speed gap with mhr-cfw closed significantly in v1.9.15+:
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=debuglog + URL pattern — those are addressable.