Anonymous Uzerz: The Darknet’s First, Local-First, Downloadable Encrypted Messenger(Launching Soon)

Fair point. That’s exactly why the project is being built with maximum transparency. I plan to publicly release the client-side code and relevant server scripts so users don’t have to trust the app they can verify it themselves. Open code, reproducible builds, and clear documentation are the goal. Even if it’s not for everyone, building tools like this still has value.

That’s a fair question — and for a lot of users, XMPP with OMEMO is the right choice. I’m not claiming this replaces it or that it’s cryptographically “stronger” in every dimension.

The difference is more about threat model and usability, not trying to beat OMEMO at its own game.

This project is aimed at users who want:

A fully local, offline-by-default application instead of a persistent chat account tied to a federated network

No long-lived identity (JID, server account, contact roster living on third-party infrastructure)

A simpler mental model: direct PGP key exchange, local encryption, dumb relay — nothing else

OMEMO’s double ratchet is excellent, but it also comes with tradeoffs: device syncing complexity, server-side metadata exposure, and reliance on an always-on XMPP ecosystem. Some users are fine with that; others aren’t.

This app is intentionally opinionated: fewer moving parts, minimal metadata, Tor-only transport, and no trust in servers beyond basic message delivery. It’s not trying to replace mature protocols — it’s offering a different tool for a narrower use case.

If someone’s threat model already fits XMPP/OMEMO, they probably shouldn’t switch. This exists for people whose doesn’t.

That’s a completely fair concern and it’s exactly why verification matters more than claims.

Right now, you can’t independently verify it the same way you can with XMPP/OMEMO, and I don’t expect anyone to blindly trust a new project because of a description in a post. Mature, widely audited software should always be the default choice for most people.

The plan is to address that gap directly: public release of the client-side code, documentation of the cryptographic design, and reproducible builds so people can confirm the binaries match the source. Until that happens, skepticism is reasonable.

This isn’t meant to compete with or replace battle-tested projects it’s an experimental tool aimed at a different threat model. If someone values long-term audits and ecosystem maturity above all else, they probably shouldn’t use this at launch.

Double ratchet exists for a reason, I agree but the risk profile here isn’t being ignored, it’s being constrained.

All cryptographic operations are client-side, and private keys are never stored in plaintext. Even if someone gains filesystem access, the key material is encrypted at rest and gated behind a passphrase that’s required at runtime. There is no server-side key storage, no server-side decryption, and no way to pull usable key material remotely.

In practical terms, the only realistic failure case is a fully compromised endpoint while unlocked or with the passphrase captured which is a universal limitation across secure messaging tools, including double-ratchet systems.

This design prioritizes local control, minimal infrastructure trust, and reduced metadata over protocol complexity. It’s not pretending to eliminate all risk; it’s choosing where the risk lives and making that surface explicit.

If someone’s threat model assumes persistent endpoint compromise, no messaging protocol meaningfully saves them anyway.

That’s fair and it’s exactly why I’m not asking anyone to blindly trust the project.

If the code isn’t published, no one should use it.

And even if it is published, most users won’t audit it themselves, which is why transparency is only one part of the solution.

The goal is to make verification as accessible as possible:

public source code

reproducible builds

clear documentation

third-party audits or community reviews over time

For most people, trust will come from reputation and third-party validation, not personal code review same as any other security tool. The difference is that at least with open source, verification is possible instead of being a black box.

If someone isn’t comfortable using it at launch, they shouldn’t. That’s a reasonable stance. But it’s not a reason to dismiss the concept outright just a reminder that security tools need time, review, and community validation to become trustworthy.

That’s a smart stance. If you don’t have a way to verify it, you shouldn’t trust it that’s basic OPSEC.

The whole point of this project is to move toward a more verifiable setup, not to replace PGP or claim it’s magically safer. All encryption and decryption happens locally on your device, and private keys never leave your machine. The server only relays encrypted data it never sees plaintext or keys.

The app will be open-source, and the goal is to allow community review and reproducible builds so people can confirm the binary matches the source.

If you want to use manual PGP today, that’s the safest option for you especially if you’re already comfortable with it.

This app is for people who want a more user-friendly workflow without giving up the ability to verify the system, and who are willing to wait for community validation before trusting it.

Lol okay but you’re doing the exact same thing you’re accusing them of: acting like you’re the only one who knows what’s real.

People can have legitimate questions without being “15-year-olds running to ChatGPT.”

If you don’t like the project, fine just don’t pretend you’re somehow above it.

He is not above it, but on top of it, anally raping it. /u/valor98 supremacy

I do like it like that, but I do have a couple of videos coming out soon ill make in a later post showcasing it in the alpha, and how it works specifically. He one day will be a user of my Darknet app.

You just gave him existential crises :)