No phone numbers. No accounts. No central database. Tin Can is the digital equivalent of a tin can telephone — your voice travels directly from one device to another, with nothing in between.
Your identity is a cryptographic key generated locally. No SIM, no email, no username. You add contacts by scanning a QR code in person.
Padded payloads, anonymous delivery tokens, and jittered timing mean the server cannot tell who is talking to whom — or when.
When both users are online, messages route device-to-device via WebRTC. The "server" is just a blind mailbox for offline drops.
Three core mechanisms that make zero-trust messaging possible.
When both devices are online, messages, photos, and files travel directly from your device to theirs using WebRTC data channels. No servers listening in — just a direct, encrypted line between two cans.
If your friend is offline, your encrypted message is dropped into a random UUID slot. The server holds the blob but cannot link the slot to any recipient, sender, or conversation.
Add contacts by scanning a QR code in person or sharing a one-time connection link. This exchange bootstraps your encrypted channel and pre-shares anonymous delivery tokens.
Every feature is designed to minimize trust and maximize privacy.
Every message is sealed with TweetNaCl secretboxes before it leaves your device. Keys are derived client-side; the server is cryptographically blind.
Crystal-clear WebRTC calls that route directly between devices. Media streams never touch a tincan unless NAT traversal absolutely requires it.
Set timers for messages to self-destruct locally on both devices. No ghost copies remain on any server because no server ever held them.
Group state is managed purely between peers. A shared symmetric sender key is distributed via 1-on-1 encrypted channels — no group metadata on the server.
Send photos, videos, and large files peer-to-peer. Fixed-size padding ensures a thumbnail and a 4K video look identical on the wire.
Online status updates only in 5-minute buckets. Prevents stalkers from building behavioral profiles of your exact sleep and wake patterns.
The exact stack and cryptography powering Tin Can.
Tin Can uses TweetNaCl for all cryptographic operations. Pairwise chats use crypto_box (Curve25519 + XSalsa20 + Poly1305). Group chats use a Signal-like Sender Key model where a symmetric group key is encrypted individually for each member via their pairwise channel, then used for efficient symmetric broadcast.
When a recipient is offline, the sender uploads an encrypted blob to a random slotId (UUIDv4). The backend stores the blob but does not link the slot to any deviceId. To retrieve, the recipient polls a set of slots derived from their delivery tokens. The server sees downloads but cannot correlate them to uploads due to delay pools and batching.
During the initial QR-code handshake, peers exchange a 256-bit random deliveryToken. When uploading to a mailbox slot, the client sends this token in a header. The backend hashes it and looks up the recipient, but never learns which deviceId owns the token. Tokens rotate every 100 messages via HKDF for forward security.
Before encryption, every plaintext JSON payload is padded to the next standard bucket: 256B, 1KB, 4KB, 16KB, 64KB. A short "hello" and a compressed photo thumbnail both encrypt to exactly 4KB. The MAC and nonce overhead is constant, so ciphertext sizes are identical for identical buckets.
Private RFC1918 IPs (10.x, 192.168.x, 172.16.x) are stripped from ICE candidates before they reach the signaling server. Public NAT IPs are still visible to peers during direct P2P, but mDNS .local candidates are preferred where available. TURN is used only as a fallback for symmetric NAT.
Tin Can is built with React Native (Expo) for cross-platform mobile, Node.js/Express for the blind mailbox backend, Redis for rate-limiting and token caching, and WebRTC for peer-to-peer media and data channels. The local database is SQLite via expo-sqlite, with row-level encryption for all message content.
Content-secure like Signal. Server-blind like Briar. Lightweight like nothing else.
| Feature | Tin Can | Signal | Telegram | |
|---|---|---|---|---|
| End-to-End Encryption | ✓ TweetNaCl | ✓ Signal Protocol | ✓ Signal Protocol | ⚠ Secret Chats only |
| No Phone Number Required | ✓ Device ID only | ✗ Required | ✗ Required | ✗ Required |
| Server Cannot Read Messages | ✓ Blind router | ✓ Technically | ✓ Sealed sender | ✗ Cloud chats stored |
| No Central User Directory | ✓ No directory | ✗ Meta directory | ⚠ Phone registry | ✗ Phone registry |
| Anonymous Delivery Tokens | ✓ Built-in | ✗ None | ✓ Sealed sender | ✗ None |
| P2P Video / Voice | ✓ Direct WebRTC | ✗ Tin Caned | ✗ Tin Caned | ✗ Tin Caned |
| Server Cost Per User | ✓ ~$0 | ✗ $Billions | ✗ $Millions | ✗ $Millions |
| Open Source Client | ✓ Planned | ✗ Closed | ✓ Open | ⚠ Partial |
The client is fully auditable. Security researchers can verify that we genuinely cannot read your messages, cannot access your keys, and cannot map your social graph.