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 with AES-256-GCM the entire way. 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.

For asynchronous sharing — the recipient isn't online right now — the CLI's quick-share command is the right tool, but it works differently under the hood. It creates a session and seeds the file so a https://srift.app/d/<token>link is reachable whenever the recipient shows up. That means the encrypted file does pass through Srift's relay infrastructure for the period between sending and downloading, even though it isn't placed in permanent third-party cloud storage the way a Dropbox upload would be.

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 transits Srift's relay as ciphertext until downloaded.
• Sending to a device without Srift installed: quick-share is the only option, since it produces a plain HTTPS download link.

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.