All cryptographic keys are generated and stored exclusively on your device. They are never transmitted. Your identity is mathematically derived from your public key, eliminating any need for a centralized account.
If you choose to save it, your identity is encrypted on your device with a key derived from your password. Physical access to the device is not enough to compromise your keys, and brute-force attacks are rendered ineffective.
For maximum privacy, iCanText allows the creation of "ephemeral" identities that exist only in memory for the duration of the session. This is the default mode, leaving no trace on your device.
Each identity has a unique "fingerprint." You can compare these fingerprints with your contacts via an external channel (e.g., in person) to guard against identity spoofing and ensure you are talking to the right person.
The first user to create a workspace becomes its "root of trust." They self-issue a cryptographic "WORKSPACE_ADMIN" certificate, which serves as the starting point for all authority delegation.
Any permission (becoming an admin, creating a channel, accessing a channel) is granted via a digital certificate signed by an existing authority (the founder or another admin). These certificates are tamper-proof.
When an admin grants a permission, they attach their own "proof chain": the sequence of certificates that leads back to the founder and proves their authority. Each network member can thus independently verify the validity of every permission.
Each user locally maintains a "wallet" containing all the valid certificates they have observed. This local database allows them to instantly decide if a user is authorized to perform an action, without ever consulting a server.
The default mode. Anyone who knows the workspace ID can join. Security then relies on the permissions of internal channels.
Access is conditional on a password. The verification process is done via a cryptographic challenge-response between the newcomer and a network member, without the password ever being transmitted in plaintext.
An administrator generates a single-use invitation link. This link contains a signed, temporary access certificate. When a new user uses it, the network verifies the certificate's validity and "burns" it to prevent reuse.
Private conversations are protected by end-to-end encryption. Only you and your correspondent can read the messages. No intermediate node relaying the message can decipher its content.
Each channel uses a shared session key. To enhance security, iCanText implements a "ratchet" mechanism: each message is encrypted with a unique, ephemeral key, mathematically derived from the session key and a counter. Thus, a future compromise of the session key would not allow past messages to be decrypted, ensuring persistent confidentiality (Forward Secrecy).
Each message is digitally signed by its sender. Upon receipt, this signature is verified. This ensures that the sender is who they claim to be and that the message has not been altered in transit. Any modified message is automatically rejected.
iCanText does not use a central server to manage identities, contacts, or messages. This eliminates the single point of failure and the most obvious target for surveillance. A minimalist service is used only for initial discovery, without ever seeing your data.
Private messages are encapsulated in multiple layers of encryption. Each intermediate node can only decrypt its own layer, which reveals only the next hop. No one along the path knows both the original sender and the final recipient.
Public messages and network announcements are broadcast across the P2P mesh. To prevent saturation, each message has a limited time-to-live (TTL), and nodes intelligently discard messages they have already seen to avoid loops and overload.
The P2P network is constantly evolving. If a node disconnects, other participants dynamically recalculate the best routes to bypass the failure. The network "heals" itself to maintain connectivity without any intervention.
Conversation history is not stored on a central server but is distributed among participants. As long as at least one member of a channel is online, that channel's history remains accessible and can be synchronized by newcomers.
iCanText runs entirely in a modern web browser. There is nothing to download or install, which reduces the attack surface and ensures you are always using the most up-to-date and secure version of the application.
In ephemeral mode, your identity and messages exist only in memory. When the tab is closed, everything vanishes. The application is designed to leave no trace in the browser cache or your local usage history.
To maintain an up-to-date network map, nodes exchange information about the best routes. To avoid "routing loops" (where a message would circle endlessly), iCanText uses the "Poison Reverse" technique: a node tells its neighbor that a route through it has an infinite cost, preventing the neighbor from sending it back. This stabilizes the network and ensures efficient message delivery.
All messages and content displayed in the interface are systematically sanitized. This process neutralizes any potentially malicious code (e.g., JavaScript) that an attacker might try to inject into a message, thereby protecting your browser and your data.
iCanText implements a "frame-busting" mechanism. It prevents the application from being loaded invisibly inside another website. This protects you from "clickjacking" attacks, where an attacker tricks you into clicking buttons in the application without your knowledge.
| Threat / Attack | Description | Mitigation in iCanText |
|---|---|---|
| Identity Spoofing (MitM) | An attacker impersonates another user to intercept or alter communications. | E2EE & Signatures: Content is unreadable and unmodifiable. Fingerprint Verification: Out-of-band comparison of cryptographic fingerprints allows detection of the attack. |
| Sybil Attack | An attacker creates a multitude of fake identities to gain disproportionate influence over the network. | Decentralized Governance: The election of important nodes (Gatekeepers) is based on a performance score (stability, connectivity), making the attack costly. Fake identities have no authority without being validated by trusted members. |
| Eclipse Attack | An attacker isolates a node from the rest of the network by controlling all its direct neighbors. | Dynamic Topology: Self-healing and shortcut-finding mechanisms encourage diverse connectivity, making the complete isolation of a node very difficult. |
| Traffic Analysis | An observer analyzes data flows to deduce who is communicating with whom. | Sealed Routing: Conceals the origin and final destination of private messages from intermediate nodes that only relay encrypted data. |
| Replay Attack | An attacker intercepts a valid message and resends it later to disrupt the system. | Unique Message IDs: Each message has a unique identifier. Nodes maintain a cache of recent IDs and systematically reject any message already seen. |
| Denial of Service (DDoS) | An attacker floods the network or a node with a large volume of messages. | Decentralization: The absence of a central server makes a classic DDoS attack ineffective. TTL & Blocking: Message lifetime is limited, and users can block malicious nodes, isolating them from the network. |
| Feature | iCanText | Signal | Tox / Jami | Briar | WhatsApp / Messenger | Telegram |
|---|---|---|---|---|---|---|
| Architecture | P2P (Dynamic Partial Mesh) | Centralized | P2P (DHT) | P2P (Friend Network + Tor) | Centralized | Centralized |
| E2EE Encryption | ✓ Yes (default) | ✓ Yes (default) | ✓ Yes (default) | ✓ Yes (default) | ✓ Yes (default) | ⚠️ Optional |
| Metadata Protection | ✓ High (Sealed Routing) | ✗ Limited | ⚠️ Partial | ✓ Very High (via Tor) | ✗ None | ✗ None |
| Identity Anonymity | ✓ Total (crypto key-based) | ✗ No (Phone No.) | ✓ High | ✓ High | ✗ No (Phone No. / Profile) | ✗ No (Phone No.) |
| Scalability | ✓ High (Optimized Routing) | ✓ Very High | ⚠️ Limited (DHT) | ✗ Low (small groups) | ✓ Very High | ✓ Very High |
| Message Storage | ✓ In-memory (default) | ⚠️ On device | ⚠️ On device | ⚠️ On device | ⚠️ On device + Cloud (backup) | ✗ On server (default) |
| Works without Internet | ✗ No | ✗ No | ✗ No | ✓ Yes (offline) | ✗ No | ✗ No |
| No Installation Required | ✓ Yes (Web App) | ✗ No (App) | ✗ No (App) | ✗ No (App) | ✗ No (App) | ✗ No (App) |
| Network Failure Resilience | ✓ Very High (self-healing) | ✗ None (central point) | ⚠️ Medium | ✓ Very High | ✗ None (central point) | ✗ None (central point) |
| Advanced Access Control | ✓ Yes (Passwords, Invites) | ⚠️ Simple private groups | ✗ No | ✗ No (based on direct contact) | ⚠️ Simple private groups | ⚠️ Private/public groups |
To achieve absolute sovereignty, iCanText gives you the ability to self-host the only centralized component: the signaling service. The code for this service is completely open source.
This means you can create a completely independent communication universe, where even we, the creators of iCanText, have no technical visibility into the existence of your network. It's the ultimate privacy guarantee for the most demanding organizations and communities.