# Messaging Messaging is the core function of Sealed. It is the process of creating, encrypting, sending, detecting, and reading a message without using a central messaging server. In a traditional messenger, messages usually pass through infrastructure controlled by the company that operates the app. In Sealed, the message flow is built around the user’s local device, encryption, and Algorand smart contracts. The goal is to make the user experience feel simple: write a message, send it, and let the recipient read it. The technical complexity stays under the hood. ### Local message creation When a user writes a message in Sealed, the message is first created locally inside the application. At this stage, the content exists only on the sender’s device. Sealed does not send the plain text message to a server for processing, routing, moderation, or storage. This is an important architectural rule: the readable version of the message should never leave the user’s device. Before any network interaction happens, the app prepares the message for encryption and delivery. ### Message encryption Before a message is sent, Sealed encrypts it on the sender’s device using the recipient’s wallet address. This means that the content is converted into unreadable data before it reaches any external infrastructure, and only the intended recipient should be able to decrypt it inside their own application. The blockchain does not receive a readable message. RPC infrastructure does not receive a readable message. Sealed as a project does not receive a readable message. For the user, this simply means that the message is protected automatically before it is delivered. ### Smart contract delivery Sealed does not send messages directly from one wallet to another by default. Instead, encrypted messages are sent through the Sealed smart contract on Algorand. This is a key part of the messaging architecture because direct wallet-to-wallet messaging could make it easier to see who is communicating with whom. By using a shared smart contract function, many users interact with the same public mechanism, which makes the delivery flow harder to interpret from the outside. The smart contract becomes the coordination layer for encrypted message delivery, not a server that can read or control the conversation. ### Message detection After a message is sent through the smart contract, the recipient’s application needs to detect that a message belongs to them. From the user’s perspective, this should feel like receiving a normal message. Under the hood, the app scans the relevant blockchain data and identifies encrypted messages that the user is able to open. The recipient’s device recognizes a message intended for it through an encrypted hint generated from the recipient’s wallet. This allows the recipient to detect their message without requiring the message to be addressed in a simple public way that exposes the recipient by default. Outside observers only see encrypted data moving through the public system. ### Message reading When the recipient’s app detects a message intended for them, the message is decrypted locally on the recipient’s device. This mirrors the sender side of the process: readable content stays inside the user’s application and is not exposed to external infrastructure. The recipient does not read the message from a Sealed server. They read it after their own device has successfully decrypted it. This keeps the message lifecycle consistent: plain text exists only on user devices, while everything outside the devices handles encrypted data. ### Message privacy Sealed messaging is designed to protect both content and context. Encryption protects the message content, while smart contract-based delivery helps avoid simple direct links between sender and recipient wallets. Every wallet uses the same smart contract function to send messages, which means that message delivery happens inside one shared flow rather than through visible direct wallet-to-wallet communication. As transaction volume grows, more users interact with the same function, making it increasingly difficult to reconstruct who communicated with whom and when. Message padding can also be used to reduce how much information is revealed by message size. In addition, when the sender uploads a message or the recipient retrieves messages, the devices use the official Algorand RPC with built-in OHTTP encryption. This masks the IP addresses of both devices from the RPC layer, so sending and receiving activity is not directly tied to the users’ network identity. These layers do not make every form of analysis impossible, but they make the communication model stronger than a simple encrypted message sent through a central server or directly between two visible wallets. ### Messaging architecture summary Messaging in Sealed starts on the sender’s device, where the message is created and encrypted locally. The encrypted message is then delivered through the Sealed smart contract on Algorand instead of a central messaging server or direct wallet-to-wallet transfer. The recipient’s app detects the message using an encrypted hint, decrypts it locally, and displays it to the user. This architecture keeps readable content on user devices, removes the need for a central message server, masks device IP addresses through OHTTP-protected RPC access, and makes message delivery harder to link from the outside. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sealed.channel/architecture/messaging.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.