Why No Cloud?

I use cloud storage every day. Google Drive, iCloud, WhatsApp. They're great. This isn't an argument against any of that.

But sometimes uploading to a third-party server is overkill, or exactly what you don't want. Maybe you're sending a large video to a friend who's in the same room. Or you want to move something to your phone without it touching someone else's servers. Or you have a sensitive file and you'd rather not leave a copy on infrastructure you don't control.

That's what SpectrShare is for. A direct path from your browser to theirs.

When you share files on SpectrShare, here's what happens:

1. You drop files into the browser and click "Share."
2. The signaling server generates a share link and helps both browsers discover each other's network addresses.
3. A direct WebRTC connection is established between the two browsers.
4. Files flow directly from your browser to the recipient's browser, encrypted with DTLS.

The signaling server is the phone book, not the phone line. It coordinates the initial connection, then it's out of the picture - it never sees your file contents.

When both parties are on the same local network, the data may not even leave the room. WebRTC's ICE negotiation will find the most direct route (which could be a local IP address rather than a path through the internet) which makes it very fast for local transfers.

When you close the tab, the share is gone. No link to expire, no file to delete, no storage quota to worry about. The data existed in the browsers involved and nowhere else.

Most sharing tools work the other way. WeTransfer, Google Drive, Dropbox: they store your files on their servers, sometimes for days, sometimes forever. That's useful when you need it, but it also means your files exist somewhere you don't control.

With SpectrShare, you decide when the share ends. Keep it open for 30 seconds or 3 hours. Close the tab and it's gone.

The signaling server knows:

• That a share session was created
• How many people connected to it
• The IP addresses of participants (for WebRTC signaling)
• File metadata (names and sizes) for the room listing

The signaling server does not see:

• File contents (all data flows directly between browsers)
• Passwords (authentication uses challenge-response; the password is never transmitted)
• Anything after the WebRTC connection is established

If you enable TURN relay (for networks where direct connections fail, test yours here), the TURN server does forward the data packets, but they're encrypted with DTLS. The relay sees encrypted bytes and has no way to decrypt them.

You can set a password on your share. The recipient has to enter it before the data connection opens.

This uses a challenge-response protocol: the host sends a random salt, the recipient hashes the password with that salt, and the host verifies the hash. The password itself is never sent over the network - even someone monitoring the signaling channel can't recover the password from the exchanged messages.

Between ephemeral shares, DTLS encryption, and challenge-response passwords, you get decent privacy for casual sharing without certificate management or key exchange. For a practical walkthrough of how this works with video, see the guide to sharing a private video.

Cloud storage is great when you need persistence or collaboration. See our comparison of file sharing tools for when each approach fits best. If I'm working on a shared doc I use Google Drive like everyone else.

SpectrShare is for the other case: you need to get a file to someone who's online right now, and you don't want it hanging around on a server afterwards.