Share Files Without Uploading Them to the Cloud

Cloud storage services made file sharing convenient by giving files a permanent address — you upload once, and anyone with the link can download at any time afterward. The trade-off is that the file genuinely lives on a third party's servers for as long as it's there, subject to that provider's retention policy, breach exposure, and legal obligations.

For a lot of sharing, though, that permanence isn't actually needed — you just want to get a file from your device to someone else's device, once, without adding a third copy on a server neither of you control.

When you open /create-session, SRIFT doesn't ask you to pick a file to upload anywhere. Instead, it generates a session ID and QR code. Once the recipient joins from /join-session, the two browsers negotiate a WebRTC data channel and the file streams directly between them, encrypted end to end by WebRTC's DTLS (or sealed with AES-256-GCM if it has to go through the relay). There's no step where the full file sits on a server waiting to be pulled down.

Where a server is still involved

To be precise about this: a lightweight signaling server is still needed to help the two browsers find each other and negotiate the connection (this is how WebRTC works in general, not specific to SRIFT). If a direct connection can't be established, SRIFT falls back to a WebSocket relay that forwards encrypted ciphertext — meaningfully different from a cloud storage upload, since the relay doesn't retain a readable copy of the file, but it's worth being upfront that a server is briefly in the data path in that fallback case.

When the recipient can't join a live session, the CLI's quick-share command gives you a https://srift.app/d/<token> link instead. It works differently under the hood: there is still no upload, but when someone opens the link, the file streams from your machine through SRIFT's relay, which forwards the bytes on the fly and stores nothing. Two consequences follow. The link only works while your machine and its CLI process are running, and the relay handles the bytes in transit — so add --encrypt for anything sensitive: the file is then end-to-end encrypted and the key stays in the part of the link after #, which is never sent to a server. Without it, the link is protected by TLS in transit.

A photographer handing a client 40 RAW files right after a shoot doesn't need those images sitting on a third-party server indefinitely — a live session gets them there directly and nothing is left behind afterward. A support engineer troubleshooting on a screen-share doesn't want to pause to upload a diagnostic log bundle to a cloud drop and wait for the customer to find the link buried in an email — a direct session hands it over in seconds. Two people in the same video call trading a large design file back and forth benefit the same way: no repeated upload/download cycles through a middleman.

• Both online now, want zero server in the data path: use a live session (/create-session + /join-session).
• Recipient isn't online yet, need an async link: use srift quick-share <file>, understanding that the file streams through SRIFT's relay while it's downloaded (ciphertext with --encrypt, otherwise TLS-protected).
• Recipient has nothing installed: quick-share link (a live session also only needs a browser).

One side effect of the no-upload model is worth calling out directly: because live P2P transfers aren't written to a storage bucket, they don't count against any quota, and there's no cleanup step of deleting old files from a dashboard later. This is a structural consequence of the architecture rather than a deliberate feature — there's simply no bucket to fill up in the first place.