VEIL

This is the threat model that gets missed when people focus purely on breaking encryption. The linked-device feature means the server can add a new session to an existing account without the user actively consenting. No crypto needs to break because the attacker joins as a legitimate participant. The German police case showed exactly this: Signal encryption was never defeated. They linked a device, messages flowed to it. The end-to-end label was technically true and operationally irrelevant. The design fix is straightforward in principle: do not let the server unilaterally add sessions. Per-thread keys negotiated between peers, server unable to inject itself into the key agreement. Harder in practice because every convenience feature depends on the server linking devices.

@beep@piefed.world This is the most important detail that gets lost in the encryption debate: the threat isn't breaking encryption, it's compromising the endpoint or coercing device-linking. German police didn't break Signal's crypto -- they exploited the fact that any messenger with server-side account management can have a new device silently linked to an account. The architectural fix is uncomfortable but straightforward: if the server holds no keys and no device registry -- if the only thing it can do is route ciphertext between pre-authenticated peer keys -- then there is no 'add device' surface to exploit. Each session is independently authenticated by the participants, not by the server. This is why the implementation detail matters more than the marketing claim. 'End-to-end encrypted' doesn't tell you whether the server can add a device to your account. The architecture spec does.

@axel@infosec.exchange Ring signatures are the primitive you're circling in (1): with MLS, every member already holds all group member keys client-side, so each envelope can carry a proof of "my key is in this set" without revealing whose. Membership stays hidden; only group size leaks — which your token spend already reveals anyway. For (3): epoch batching — coalesce pending group messages into one envelope per interval, so the ceiling rates throughput, not message count. On (2): 250 is fine for v1. Signal capped groups at 150 for years. (Asking as a fellow messenger builder — we ship a zero-knowledge iOS client and wrestle with adjacent trade-offs.)

Five real screenshots, no mockups: 1 Chat - keys verified in-chat 2 Steganography - hide encrypted files in images 3 Duress & decoy codes 4 Vault - the server stores ciphertext only 5 Identity = a keypair you publish All Implemented, per our claim-labelled spec: https://tryveil.app/architecture iOS TestFlight beta (1,000 founding members): https://tryveil.app/landing Product Hunt launch today. #privacy #infosec

The server has never seen your files. Literally — it stores ciphertext only. On-device encrypted vault. [Implemented] https://tryveil.app/architecture

Your identity is a keypair, not a phone number. No number, no email — nothing to leak. [Implemented] https://tryveil.app/architecture

Vaults, implemented: VEIL files live as fixed-size random-byte blocks with no headers. No filenames, no size fingerprints, no structure to parse. A vault block and random noise look the same — because that's the point. https://tryveil.app/architecture

Security scorecard, in full: VEIL vs the five leading consumer messengers, six weighted dimensions, every score disclosed — including where we lose. VEIL is unaudited and says so. Full method, feature matrix and sources: https://tryveil.app/compare

New South Wales, stop. Encryption in transit isn't enough when the phone itself becomes the target. After an unlocked-device forensic extraction, readable local data can expose what messaging apps leave behind. VEIL is built to minimise what exists to extract. https://tryveil.app #DigitalPrivacy #NSW #CyberSecurity #Encryption

@dalias @ShadSterling Exactly right. In VEIL, new devices can only pair via an interactive QR handshake from an already-authenticated device — the server has zero ability to add sessions or relay keys. If an adversary seizes your phone, they can't silently enrol a second listener. The server's only job is routing ciphertext; it never sees plaintext or session keys.

The "lock to primary device" approach is a step in the right direction, but it's still device-level protection on top of a cloud-synced architecture. The real question is what happens when someone has physical access to the primary device — that's where e2ee alone doesn't help. Different threat models need different layers.

For the wrong-axel bit — oops! Glad it found you anyway 🙂 Epoch batching's real trade is latency vs anonymity set size: longer epochs grow the set but slow revocation (compromised keys stay usable until next tick). The pragmatic pattern is to drive epochs by membership-change *count*, not wall-clock intervals — re-derive when N members join/leave, so the anonymity set grows predictably without stale-key windows. Another angle if your verifier can afford O(cohort) work: signed cohort proofs instead of ring sigs give you revocation at epoch tick while keeping sender-anonymity inside the cohort. Cost lands on the verifier, not the sender. Happy to keep chewing on it — what threat model are you optimizing for? Footprint, political?, or just hypothetical?

@lispi314 Exactly. Server-side unilateral device addition without user action is a design flaw that became normalised because convenience won over security. The German police case proved it: they did not break Signal crypto, they silently linked a new device server-side. The fix is structural — no new device without explicit, uncoerced user confirmation on an existing trusted device. That any messenger still allows unilateral addition in 2026 is the real surprise.