Back to browse
EncroGram – Messaging When You Assume Everything Will Be Looked At

EncroGram – Messaging When You Assume Everything Will Be Looked At

by truthleaks·Feb 12, 2026·1 point·0 comments

AI Analysis

●●SolidNiche GemBold Bet
The Take

Starts from a strict threat model — password-only identities, no contact sync, ephemeral relays, and an emergency "0000" wipe all push toward leaving as little recoverable metadata as possible. Those are useful, concrete tradeoffs, but sweeping claims like 'technically impossible to spy' need a public audit and the Apple-only restriction limits reach and threat-model assumptions.

Category
Target Audience

Activists, journalists, privacy-conscious individuals, security-minded communicators

Post Description

Hi HN,

I’m not using EncroGram because I like clean UI or new apps. I’m using it because I assume that sooner or later, anything I touch might be examined — devices, servers, logs, timelines.

Most messaging apps focus on encrypting content. That’s table stakes now. What matters in practice is everything around the content: identifiers, metadata, backups, correlations, and the quiet assumptions built into the system.

EncroGram caught my attention because it seems to start from a different premise: reduce what exists in the first place. No accounts tied to phone numbers or emails. No analytics. No long-term server-side message storage by design. Fewer moving parts, fewer promises, fewer things to trust.

I’m not under the illusion that this makes communication safe or anonymous. Devices get seized. Networks get monitored. People make mistakes. Nothing here changes that. What it changes, at least in theory, is how much residual data is created by default, and how much of that data lives outside the endpoint.

From my point of view, that’s the real question: not “is it secure?”, but “what’s left behind when things go wrong?”

This doesn’t feel like a mainstream product, and it probably shouldn’t be. It feels more like an experiment in being explicit about trade-offs and threat models instead of hiding them behind UX polish and legal language.

I’m posting this because I’m interested in technical criticism and discussion. Where does a low-retention or stateless approach actually help, and where does it fail? What assumptions does it still rely on that users like me might underestimate?

Not here to promote it — just interested in informed perspectives on the design choices.

Similar Projects