The Internet has become a global communication infrastructure, but Chat has evolved as a collection of separate, closed messaging networks. People can communicate easily when they use the same chat service, but communication becomes fragmented when contacts use different platforms, countries, organizations, or business ecosystems. Users may need multiple chat applications and multiple accounts simply to stay connected with family and friends, international contacts, colleagues, customers, suppliers, and business partners.
At the same time, the Internet already has a global communication network that was designed to connect people across these boundaries: email. Email provides a global addressing model, interconnectable delivery, user-controlled mailboxes, existing email clients, and communication that does not depend on one global service provider.
That led to a straightforward product question at ZTmail: if global email already provides the interconnectable communication infrastructure, why does Chat need a separate network? ZTmail App is already an S/MIME client that automates certificate-based email encryption, adding a Chat Mode could use that existing foundation to address several problems that have remained separate in traditional Chat services.
The first big problem is interconnection. ZTmail does not need to create another global messaging network because the global email network already exists. With Chat Mode inside the ZTmail App, the same underlying communication infrastructure can support two experiences: Mail Mode for traditional email communication and Chat Mode for conversational communication.
The interface changes, but the underlying infrastructure does not. The same global email addressing and delivery model, S/MIME encryption, S/MIME certificates, private keys, and mailbox can support the conversation. Users can move freely between Chat and Mail whenever they need.
This is not about making email look like a chat application. It is about using an existing interconnectable communication infrastructure to provide a chat experience without creating another isolated chat network.
The second problem is trusted identity. Interconnection solves only one part of the problem. Secure Chat also needs a way to establish who is communicating with whom. Traditional chat services can display a name, username, phone number, avatar, or profile, but those identifiers do not necessarily establish an independently validated identity.
S/MIME provides a different cryptographic foundation. A digital signature allows recipients to establish who sent a message and whether the signed content has been altered. A S/MIME certificate can also carry information about the level of identity validation associated with the sender. This makes trusted identity visible in the communication experience instead of leaving users to infer trust from an application profile.
For ZTmail, this distinction is important because encryption and identity solve different problems. Encryption protects the confidentiality of the conversation. A digital signature and certificate-backed identity provide information that helps the recipient establish who sent the message. Bringing the two together creates a secure Chat experience in which confidentiality and trusted identity can work as part of the same communication flow.
This provides a foundation for addressing a long-standing problem in digital communication: a conversation can be encrypted while the recipient still has to ask, “Who is really sending this message?” By making validated identity visible at the message level, ZTmail Chat can provide users with information that ordinary application profiles do not necessarily provide.
ZTmail makes identity presentation a choice rather than a single fixed profile. Different conversations can require different levels of identity information.
In Chat Mode, these identity levels become part of the conversation interface. A user can see whether the communication is associated with a validated mailbox, an individually validated identity, an organization, or both an individual and an organization.
The third problem is where chat conversations are stored. ZTmail takes a different approach by keeping the Chat conversation as an encrypted email underneath. The message is protected by the user's S/MIME keys and stored encrypted in the user's own mailbox.
This means the Chat experience does not require a separate chat message store to hold the conversation. The mailbox, the S/MIME keys, and the encrypted message remain part of the communication infrastructure the user already uses for email.
For users, this provides a clearer sense of control over where their conversations reside. The chat experience can be convenient and conversational while the underlying messages remain encrypted in the user's own mailbox rather than becoming a separate category of chat data that must be managed independently by the chat provider.
This is an important privacy-oriented design choice: the user can have Chat without giving up the familiar concept of having their own mailbox and their own cryptographic keys, and keep the encrypted chat messages by themselves.
The fourth problem is the gap between Chat and Email. In conventional workflows, a user may need to copy a conversation from a Chat application, switch to an email client, paste the content, and then reconstruct the message. Moving in the other direction can require the same manual process.
Because ZTmail Chat is built directly into the S/MIME email client, the two experiences can be connected at the interface level. While chatting, users can move to email without leaving the conversation.
The reverse direction is equally important. An email can become a conversation in Chat Mode without requiring the user to copy and paste its contents into another application. Email and Chat can therefore become two interaction modes over the same encrypted communication flow.
Move freely between Chat and Mail whenever you need.
The fifth problem is adoption. A chat service works when both sides use the same chat application. That requirement creates another barrier: every new chat experience asks the other person to install an app, create an account, and join another messaging network.
ZTmail Chat does not require that. The person on the other side can continue using the email client they already have. They do not need to install ZTmail App, create a new Chat account, or stay online at the same time.
When the other person replies through their existing email client, the message travels through the global email infrastructure and can be brought back into the ZTmail Chat experience. ZTmail uses IMAP IDLE to receive notification that new mail has arrived and then retrieve the message, providing the near-real-time responsiveness expected from a chat-oriented interface.
In other words: you use ZTmail, they use email, and you can still chat. The point is not simply that the other person does not need ZTmail App. It is that communication can remain interconnectable even when the two sides use different email client and communication experiences.
These capabilities point to a different model for Chat. Instead of treating Chat as a network that must be created and controlled separately by each provider, Chat can become an experience built on top of global email infrastructure and common cryptographic foundations.
Multiple chat providers can build different Chat experiences while using interconnectable email infrastructure underneath. Certificate authorities can provide S/MIME certificates, cryptographic application automation providers can automate certificate lifecycle management services, security vendors can contribute security capabilities, cloud providers can provide infrastructure, and AI providers can contribute intelligence.
The important idea is not that every provider must build the same Chat application. It is that different services can participate in a communication model that is already global and interconnected. ZTmail is demonstrating one implementation of that model by bringing Chat Mode into an S/MIME client.
For the global communications industry, this offers a different way to think about Chat: it should not remain isolated between all Chat providers, but should interconnect each user, a conversational experience that can be built on email infrastructure the Internet already uses.
This practice was ultimately about solving several problems with one existing foundation. Global email provides interconnection. S/MIME provides encryption, digital signatures, and certificate-backed identity. The mailbox provides a place for users to keep their encrypted messages. The S/MIME client provides the cryptographic and email capabilities needed to connect these pieces.
Adding Chat Mode turns those capabilities into a different communication experience. It gives users a way to chat across the global email network, see certificate-backed identity, keep conversations encrypted in their own mailbox, move between Chat and Mail without copying and pasting, and communicate with people who continue to use their existing email clients.
We did not start by asking how to build another Chat network. We started with infrastructure that already works globally and asked what a modern Chat experience could look like if it were built on top of it.
One Infrastructure. Two Experiences. Mail ▪ Chat.
Click here to read PDF edition (digital signature and timestamp with global trust and global legal effect, all rights reserved, plagiarism is prohibited! Please indicate when reprinting: Reprinted from ZoTrus CEO Blog)