Pidgn

Mission

Absolute digital privacy is a fundamental human right. Modern messaging platforms and web ecosystems have devolved into surveillance engines, designed to harvest, monitor, and monetize your intimate conversations and digital footprint. We reject this architecture of exploitation. Our mission is to engineer a sanctuary for human communication - an end-to-end encrypted environment that keeps your data exclusively yours, yours to read and yours to delete at will. We provide the infrastructure; you hold the keys. No ads, no telemetry, and no corporate oversight - just pure, untracked signal.

How it works, plainly

When you create an account, your browser - not our server - generates an RSA-OAEP-2048 keypair. Your public key gets uploaded so people can encrypt messages for you. Your private key is encrypted with a 256-bit AES-GCM key derived from your password (600,000 PBKDF2-SHA256 iterations + a random per-user salt), and only the encrypted form ever leaves your device.

Your password never leaves your browser. Pidgn uses SRP-6a (Secure Remote Password), a zero-knowledge proof protocol that lets you prove you know your password without ever transmitting it - not even encrypted. During registration, your browser computes a mathematical "verifier" from your password and sends only that. During login, client and server exchange cryptographic challenges that prove mutual knowledge of the password without either side revealing it. A compromised network, a malicious proxy, or even a rogue server operator cannot extract your password from the traffic.

What if I forget my password?

Because your password also encrypts your private key, the password can't simply be "reset" back to your data — anyone (including us) handing you the encrypted bytes still couldn't open them without it. That's the literal promise of end-to-end encryption. So instead, we hand you a recovery code at registration.

When you sign up, Pidgn shows you a one-time recovery code and asks you to save it (a password manager is ideal). It's a second, high-entropy key that unlocks the same private key your password does — and like your password, the server never sees it; it only stores the encrypted result. If you forget your password, the flow is:

Have your recovery code - prove control of your email, enter the code, set a new password, and all your messages are preserved. It's the same keypair, so nothing has to be re-encrypted or re-keyed. This is the recommended path.
Lost the code too - you can still reset with a fresh keypair, but the messages encrypted under the old one are mathematically gone. Your username, email, and contacts survive; your contacts re-encrypt to your new identity.
Delete my account entirely - wipes the row from our database; your username is released and contacts see you vanish.

The honest limit: if you lose both your password and your recovery code, your stored messages can't be recovered by anyone — that's not a gap we can close without breaking the encryption. So save the code.

The encryption stack

Different content types use the algorithm best suited for their size and audience:

Content	Algorithm	Key
Login authentication	SRP-6a (2048-bit)	Zero-knowledge proof - password never transmitted; server stores only a mathematical verifier
Your private key (at rest on our server)	AES-256-GCM	Derived from your password via PBKDF2-SHA256, 600k iterations, random salt
1:1 messages	RSA-OAEP-2048	Recipient's public key (and your own for your sent copy)
Group messages	AES-256-GCM	Random per-group key, wrapped per member with that member's RSA public key
Images / files	AES-256-GCM (body) + RSA-OAEP-2048 (key)	Fresh AES key per file; key wrapped into the recipient's normal message envelope
Voice / video calls	DTLS-SRTP (WebRTC)	Negotiated directly between participants; media is peer-to-peer (a mesh for group voice rooms). Neither the server nor our TURN relay can decrypt it.
Transport (browser ↔ server)	TLS 1.2+	Cloudflare-issued certificate; HTTPS enforced (HTTP requests auto-upgrade)

What we can't see

The contents of any message - text, image, or file
The audio or video of your calls - WebRTC encrypts call media end-to-end (DTLS-SRTP) directly between participants. If a call can't go peer-to-peer and falls back to our TURN relay, the relay only forwards encrypted packets it can't read
The AES keys used to decrypt your group messages, files, or stored private key
Your password - it never leaves your browser, not even briefly
Anything you've cleared via the ␡ history button (server data is hard-deleted, not flagged)

What we can see, and why we're honest about it

End-to-end encryption hides content, but not metadata. The server has to know where to deliver an encrypted message in order to deliver it. Here's the metadata we necessarily have:

Who you message - the contacts table records username pairs
When - server-side timestamps on every stored message
How much - message and file sizes (ciphertext bytes)
Call setup and voice-room presence - to connect a call the server relays the setup handshake (so it sees who's calling whom, and when); for a group voice room it tracks who's currently in the room to show the live roster. It never receives the call audio itself
Your email address - required for account recovery, new-device approval, and a one-time check that you control it before you can message
Your device's push token - only if you turn on notifications in the mobile app, so we can wake it when a message arrives. The push itself is content-free: a generic "new message" nudge with no text, sender, or group name
Your avatar - stored unencrypted; treated as a semi-public identifier like your username
Emoji reactions - stored as plaintext glyphs. Encrypting them for an 8-emoji set buys very little privacy at meaningful complexity cost, so we made it an explicit exception

What we don't do with this metadata is sell it, aggregate it, profile you, or share it with anyone - see below.

Third parties in the path

Running a real service means a handful of infrastructure providers necessarily handle traffic on its way to us. They see metadata, never message content - that's encrypted before it reaches any of them. In the spirit of the honesty above, here's who and what:

Cloudflare - the network edge in front of the service (TLS termination and bot protection at signup). It can see connection metadata - your IP address, timing, the hostname you reached - but no message content. As the proxy, it also derives aggregate traffic analytics from that metadata; we run no analytics script of our own in your browser.
Hetzner - rents us the server the encrypted data sits on. They hold the disks; what's on them is ciphertext the server itself can't read, plus the metadata listed above.
Resend - delivers our account emails (verification, password reset). It sees your email address and those specific emails - never your messages.
Apple (APNs) / Google (FCM) - if you enable notifications in the mobile app, they relay the wake-up push to your device, so they learn "this device received a push at this time." The push carries no content, sender, or group name. This is unavoidable with any mobile push - disabling notifications is the only way to opt out of it entirely.

We chose these providers deliberately, but the honest bottom line is unchanged: the real guarantee is the encryption, and none of them can read what you say.

What we promise NOT to do

No advertising network code on this page or anywhere else
No third-party analytics, telemetry, or user-behavior trackers
No selling, sharing, or "partnering" with anyone over your data
No tracking cookies - only a small localStorage device token (proves a browser was approved, not a credential) and a few local preference values (your noise-suppression, push-to-talk, and audio-device choices, plus which sidebar sections are collapsed - none of them credentials, none sent to us), alongside a short-lived sessionStorage blob (your encrypted private key, cleared when you close the tab)
No reading your messages to "improve the model" or any other euphemism

Threat model - what we protect, what we don't

✓ Pidgn protects against

Server breach reading your message content (everything's encrypted at rest)
Network eavesdropping on cellular, public Wi-Fi, ISP, etc. (TLS in transit + SRP means even a compromised TLS connection can't learn your password)
Casual snoops who don't have your password
Login from an unknown browser without an email approval click (device verification)
Cross-conversation data leakage (each conversation has its own keys)
A removed group member reading future messages — removing someone rotates the group's key, so the copy they kept only opens the history they were already part of, never anything sent after they're gone

✗ Pidgn cannot protect against

Anyone who knows your password - they get everything you have
Forgetting your password - we can recover account access via the email-gated reset, but the stored messages encrypted with the lost password are mathematically gone
Physical access to your unlocked device
A malicious browser extension with permission to read this page's DOM
A targeted nation-state attack with unlimited time and resources
The fact that the server can see who messages whom and when (metadata above)
The recipient of a message screenshotting it, copying it, or sharing it
A server that hands your browser tampered code. Pidgn is a web app, so the JavaScript that does the encryption is delivered fresh each visit — in principle a compromised server could ship a backdoored build. We narrow this with a strict Content-Security-Policy (the page runs no inline scripts and no third-party code beyond the sign-up bot check) and by keeping the crypto verifiable in the source you can read, but a browser-delivered app ultimately asks you to trust the code it loads. A signed native build would close the gap further
Recovery of your past 1:1 messages if someone later steals your encrypted private key and cracks your password. One-to-one messages are sealed to your long-lived RSA key, so that path has no per-message forward secrecy (group keys, by contrast, rotate on membership change). Both secrets are required — and your private key only ever exists encrypted under your password

Verify it yourself

Every privacy claim above is verifiable entirely from the client-side code served alongside this page - no access to server internals required. Open the page source and look at /crypto.js for srpGenerateVerifier, srpClientSession, generateRSAKeyPair, encryptPrivateKey, decryptPrivateKey, encryptMsg, generateGroupKey, and downloadAndDecryptFile. These are the functions where every promise either holds or breaks.

The page is also served under a strict Content-Security-Policy you can read in the response headers: scripts load only from Pidgn itself - no inline scripts, no third-party code beyond the sign-up bot-check widget - so even a content-injection bug can't run code against your keys. object-src is off, framing is denied, and the referrer is suppressed. It's defence in depth behind the real guarantee: the server only ever holds ciphertext it can't read.

The server code is not published. That doesn't change what it can see - it stores ciphertext it cannot read, and your password never reaches it at all. The server's role is delivery and storage of opaque bytes, and the client-side code you can read is sufficient to confirm that. Anti-abuse and operational logic are kept private to avoid handing a roadmap to bad actors.

If you find a place where we're not living up to this, please tell us. Privacy claims are worth exactly what they can be verified against.

Feed the birds 🍞

Pidgn is funded directly - no ads and no data-for-money pipeline. Hosting costs are covered by the people who use the service, not by what they say in it. If Pidgn grows beyond what voluntary support can sustain, any future funding model will follow the same principle: revenue comes from users, not from their conversations.

If you'd like to help keep the lights on, a few dollars goes a long way. Donations are entirely optional and anonymous where the provider allows.

🍞 Feed the birds

Pidgn - Privacy & Mission