Video ingestion

Pasting a video link into the chat makes Tale fetch the video's transcript with yt-dlp. Video platforms — YouTube most aggressively — challenge requests from datacenter and server IPs with a "confirm you're not a bot" wall, so a fresh self-hosted deployment on a cloud VM can see ingestion fail where a laptop on a home connection would succeed. This page covers the three layers Tale ships to get past that, from the one that needs no configuration to the one that needs the most.

Layer 1 — the PO-token provider (default, no config)

The single most effective measure is a proof-of-origin (PO) token: a signed value that makes a request look like it came from a real browser session. Tale ships a token provider wired up out of the box — the yt-dlp plugin is baked into the image and a bgutil-provider sidecar serves the tokens over the internal network. No environment variable is required; a fresh docker compose up or tale deploy has it running.

You can point yt-dlp at a provider on a different host with VIDEO_INGEST_POT_PROVIDER_URL, or supply a manually-minted token with VIDEO_INGEST_PO_TOKEN — both are documented in the environment reference. The sidecar being down never breaks the stack: ingestion simply falls back to no token, exactly as if the layer were absent.

Layer 2 — an egress proxy

When the token alone is not enough — some IP ranges are flagged regardless — route the fetch through an egress proxy on an IP the platform trusts. Residential and ISP-hosted proxies work best; datacenter and commercial proxies are often flagged just like the server itself.

Set VIDEO_INGEST_PROXY_URL to the proxy URL. A socks5h:// scheme resolves DNS at the proxy (the safest choice); http, https, socks4, socks4a, socks5, and socks5h are all accepted. The value can carry credentials — Tale scrubs them from every log line.

VIDEO_INGEST_PROXY_URL=socks5h://user:pass@residential.example:1080

The proxy applies to every phase of a fetch — metadata, captions, and audio — so the whole ingest shares one trusted egress path.

Layer 3 — the pre-warmed browser-session pool

The strongest measure is to present cookies from a real browser session that has already cleared the bot check. Tale keeps a pool of these sessions, keyed by domain, and hands one to each fetch so the platform sees a returning visitor rather than a first-touch server.

Sessions are stored encrypted at rest (the cookie jar is sealed with the deployment's ENCRYPTION_SECRET_HEX) and are never exposed to agent-executed code — they live only in the server-side fetch layer. A session that starts getting blocked is cooled and then retired automatically, and expired sessions are swept on a schedule.

Populating the pool is an advanced, hands-on step: capture a Netscape cookie jar from a browser that has solved the challenge for the target platform, then import it through the importBrowserSession internal action. The same pool also backs the agent's web-fetch tool and crawler, so a session warmed for a domain benefits every server-side reach-out to it.

Which layer do I need?

An honest expectation

None of these layers can guarantee ingestion against a platform actively working to block automated access from arbitrary IPs. Together they make ingestion succeed wherever your egress is trusted, and every deployment has a supported path to escalate. If a platform hard-blocks your server, the transcript can still be brought in by hand — paste it into a Knowledge document.