Direct when possible
When two people can reach each other, dmsg prefers a peer-to-peer path instead of forcing every message through one central chat server.
INDIA-BORN · PEER-TO-PEER MESSAGING
Messaging without the middleman.
dmsg is a privacy-first messenger designed so people can communicate device to device whenever possible — with encrypted, resilient fallback delivery when a contact is offline.
Direct P2P
End-to-end encrypted
No permanent central chat database
encrypted session
direct peer path
THE SIMPLE VERSION
Your chat should not need a company sitting permanently in the middle.
Most familiar messengers are built around large central systems that receive, route and temporarily store communication.
dmsg changes the route. Devices try to find each other, establish an authenticated encrypted session and communicate directly. Infrastructure remains useful for discovery, waking devices and offline delivery — but it is not designed to own the conversation.
WHY DMSG
Privacy built into the architecture.
Instead of asking you to trust a privacy promise alone, dmsg is being designed to reduce how much central infrastructure needs to be involved at all.
Encrypted end to end
Message content is encrypted before it leaves your device and decrypted by the intended recipient.
Identity you control
Your identity is cryptographic and portable, rather than existing only as a row inside a central account database.
Offline-aware delivery
If a contact is offline, encrypted payloads can be temporarily staged and fetched when that person comes back.
Distributed discovery
DHT-assisted discovery helps peers find one another across real networks without a classic central routing directory.
Less data in the middle
Infrastructure helps with discovery, wake-ups and offline delivery, but is not designed to be the permanent home of your conversations.
THE PRODUCTPrivate technology.
Private technology.
Familiar experience.
The protocol can be complex underneath, but the app should feel like a messenger people already understand.
01No phonebook-first identity model
Contacts can be tied to a public cryptographic address instead of relying only on a centralized account identity.
02Share your identity directly
QR and public-address sharing make it clear what identity you are actually exchanging.
03Recovery without plaintext custody
Encrypted recovery and user-controlled credentials are designed around restoring access without exposing message content.
Share your contact by QR or public address.
Recovery contribution and privacy controls live inside the product.
Encrypted backup and recovery are explicit, not hidden magic.
HOW A MESSAGE TRAVELS
From your phone to theirs.
No jargon required. Here is the journey in plain English.
1
You press send
The message is prepared and encrypted on your device.
2
dmsg finds the best route
If your contact is reachable, the system prefers a direct peer path.
3
They receive it
The recipient verifies the session and decrypts the message locally.
Your phoneencrypts locally
DIRECT ENCRYPTED P2P
Their phonedecrypts locally
Sender
Encrypted
temporary store
temporary store
Offline peer
WHEN SOMEONE IS OFFLINE
P2P does not mean messages vanish when a phone is unavailable.
Direct delivery is preferred, but real phones go offline. dmsg can temporarily stage encrypted messages or attachments across its delivery infrastructure. When the recipient returns, content is fetched and acknowledged.
The goal is infrastructure that helps availability without becoming a permanent central conversation archive.
UNDER THE HOODSimple outside.
Simple outside.
Protocol-heavy inside.
For technical users, dmsg combines cryptographic identity, distributed discovery, authenticated sessions, peer transport and resilient offline delivery into one mobile-first messaging flow.
01
Identity
A device owns a cryptographic identity used to recognize trusted contacts.
02
Discover
Distributed discovery and known-peer information are used to locate a path.
03
Handshake
Devices establish and authenticate a secure session.
04
Talk direct
When reachable, messages and attachments move over the peer path.
05
Bridge offline
When a peer is unavailable, encrypted temporary storage bridges the gap.
06
Recover
Local state and encrypted recovery mechanisms are designed to keep conversations resilient.
session keysAES-GCMDHT discoverypeer identitystore-and-forwarddurable outboxdelivery ACKsencrypted attachments
THE DIFFERENCENot “no infrastructure.”
Not “no infrastructure.”
Less dependence on infrastructure.
A serious mobile P2P messenger still needs help with discovery, NAT-heavy networks, background wake-ups and offline users. The difference is what that infrastructure is trusted to do.
Typical cloud messenger
dmsg
Provider infrastructure is normally in every delivery path
Direct P2P path is preferred when peers are reachable
A central account is usually the primary identity
Cryptographic identity is controlled by the user/device
Provider routing is always central to delivery
Infrastructure assists discovery and offline delivery
Central message storage is a core dependency
Permanent central chat storage is not the design goal
BUILT FOR THE REAL INTERNET
Wi-Fi. Mobile data. NAT. Offline peers. App restarts.
P2P messaging is easy in a lab and difficult on real phones. dmsg is being engineered around the messy parts: changing networks, intermittent reachability, mobile background restrictions, delivery recovery and large encrypted attachments.
Cross-network peer connectivity
Distributed peer discovery
Authenticated encrypted sessions
Fast reconnect and delivery recovery
dmsg
Peer A
Peer B
DHT
Offline store
DMSG
The conversation should belong to the people having it.
We are building a peer-to-peer messenger from India for a more private, resilient and user-controlled way to communicate.