Why your media should never touch a server

Most video sharing and casting works the same way: you pick a file, it gets uploaded to someone's servers, and the other device streams it back down. Somewhere in the middle, a company holds a copy of your video — a recording of your kid's birthday, your screen recording, a movie file you own. That copy sits on their disks, under their retention policy, accessible to their infrastructure and their legal obligations.

That is a strange default. Playing a video on another screen in your own home shouldn't require handing a copy of the file to a third party. This is the problem Chusko exists to remove: it casts local video files peer-to-peer, so the media never touches a server at all.

What actually happens when you upload to a cloud service

Uploading creates copies you can't control:

• An unencrypted or service-readable copy sits on their storage, even if the transfer itself was encrypted.
• Retention is their decision. You deleted your copy? Their backup or cache may keep one for months.
• Access is their decision. Terms change, features move behind paywalls, accounts get suspended — your file's availability follows their roadmap.

None of this is an accusation of malice. It's an architectural fact: anything you send to a server, a server can store, and anything a server can store, someone else controls.

Peer-to-peer: the file never leaves the devices

Peer-to-peer (P2P) casting flips the architecture. The projector device reads the file from its own storage and sends the bytes directly to the screen device over an encrypted peer-to-peer connection. No middle copy exists, because no middle exists.

In Chusko's case the only server in the picture is a signaling relay that sets up the connection — and it carries nothing but a few kilobytes of WebRTC handshake. It never sees the video, never stores the video, and has no way to. The video bytes travel from one device you own to another device you own, encrypted end to end (DTLS-SRTP).

What about the fallback path?

Sometimes two devices can't connect directly (both behind strict NATs, for example). The standard fix is a TURN relay that forwards packets. In Chusko, even that path only forwards encrypted bytes — the relay cannot read them. The handshake relay and any TURN relay are pure packet plumbing, never a content store.

What this means in practice

• No upload step. You don't wait for a file to climb to a datacenter before playback starts — playback can begin while the projector streams the file.
• No account, no retention policy. Chusko has no accounts and no server-side files, so there's no profile, no storage quota, and nothing for a terms-of-service change to take away.
• Your files are your files. The bytes live in the browsers on your devices — the projector's storage and the screen's on-device cache — and nowhere else.

When you don't need a server

Watching your own files on your own screens is the clearest case. The projector has the file; the screen is reachable over the internet; the only missing piece was connection setup, which is exactly what Chusko's relay provides and nothing more. There is no reason for your movie to spend time on a stranger's disk in between.

Curious how the pieces fit together? See how Chusko casts video peer-to-peer, or jump to the FAQ for the short answers.