Amnesia: What If a Messenger Was Designed to Forget?

Created by Jin Park Most secure messengers protect a persistent account. Amnesia asks whether a private conversation can exist without leaving one behind. Research disclosure: Amnesia is an unaudited concept and early prototype direction. It is not production-ready and should not be trusted with sensitive communication. A modern messenger is an archivist with separation anxiety. It remembers your account, devices, contacts, sessions, recovery methods, and enough historical state to welcome you back after you drop your phone into a canal. This is useful. It is also a great deal of memory for an application whose central job is supposedly moving a sentence from one person to another. End-to-end encryption has made that sentence much harder for the service provider to read. Good. Necessary. Long overdue. But encryption is not forgetting. A service may still retain account state and observe that two users communicated. A phone may preserve a local database, notification text, caches, crash reports, session tokens, or cloud backups. An application can delete a conversation from its interface while the operating system and storage hardware continue quietly pursuing their second career in archaeology. Most secure messengers are designed to provide secure, reliable, persistent communication . They are not failing because they remember. Remembering is part of the product. I have been thinking about the opposite design brief. What would a messenger look like if forgetting were not an optional timer attached to a permanent account, but the primary architectural principle? That is the idea behind Amnesia . Its central question is deliberately narrow: Can two people establish a useful private conversation without creating a permanent account, durable identity, recoverable session, or intentional message archive? The answer may be “not without unacceptable trade-offs.” That would still be useful to learn. Security research is allowed to end in disappointment. Most engineering already does; it simply receives better branding. Encryption Protects Content. Systems Preserve Everything Around It. Modern secure messengers have achieved important things: end-to-end encryption, forward secrecy, ratcheting keys, and device verification. These protect message content and limit some forms of compromise. They do not automatically erase the communications lifecycle around that content. A typical messenger still needs to know who the user is, which devices belong to the account, which contacts and groups exist, which sessions remain active, how recovery works, and what state must survive disconnection. Every answer creates state. State creates continuity. Continuity creates something that can later be recovered, correlated, stolen, compelled, copied, or simply forgotten by everyone except the computer. Amnesia explores a different point in the design space: Temporary communication with minimum durable state. This is not an argument that persistence is inherently bad. Persistence is convenient, and human beings become remarkably attached to convenience once it has been given a rounded icon. It is an argument that some conversations justify a different bargain. The Opposite Design Brief The first Amnesia prototype should be small enough to understand and strict enough to disappoint anyone arriving with a feature roadmap. No permanent account A conventional messenger begins with enrollment. Phone number. Email address. Username. Password. Recovery method. Device registration. Contact discovery. A small administrative nation is founded before anyone has said hello. Amnesia would begin with a temporary session. One participant creates a one-time invitation, probably as a QR code. The other scans it. The devices establish a temporary authenticated relationship using fresh cryptographic material. No global username is required. No phone number or email address is attached. No permanent directory waits in the background. When the session ends, the relationship ends with it. One session, one identity epoch Each session should generate fresh identity and signing keys. Relay capabilities, mailbox identifiers, message keys, counters, and authorization proofs should be bound to that temporary epoch. A credential copied yesterday should not authorize anything today. This matters because account compromise does not always require stealing a password. An attacker may steal an active session token and present it elsewhere. The server sees a valid bearer credential and, with the weary professionalism of a hotel receptionist at 3 a.m., hands over the room key. Amnesia should require proof that the client still holds the session’s private key. Privileged requests should be signed and bound to their action, destination, ciphertext or body hash, nonce, counter, and expiration window. A copied identifier may reveal that something existed. It should not be enough to become it. No intentional archive or conventional recovery In strict mode, Amnesia would not maintain conversation history. Messages would exist only while the session is active and only as long as needed for delivery and display. There would be no search, cloud restoration, or scrollback through six months of increasingly poor judgment. There would also be no support-assisted reset, SMS recovery, recovery email, or service-held master key. If the session disappears, it is gone. That is harsh. It is also what “the service cannot recover this” looks like when written as architecture rather than advertising. The First Prototype The first version does not need group chats, stickers, voice calls, public channels, bots, animated reactions, or an assistant eager to summarize the conversation nobody asked it to read. It needs to prove one lifecycle: One user starts a temporary session. The application creates a fresh identity. A one-time QR invitation carries temporary handshake information. A second device scans it. Both devices complete an authenticated key agreement. The users compare a short verification code. They exchange encrypted text through a minimal relay. Either participant presses End and Forget . The clients destroy application-controlled identity keys, message keys, relay capabilities, counters, and conversation state. Restarting either application does not restore the relationship. To speak again, the participants create a new invitation and a new identity epoch. No profile survives to reassure them that the software remembers who they are. The software does not know who they are. This is the point, although it may be the first product feature in history to sound faintly insulting. A Relay With Almost Nothing to Say The prototype still needs a relay. Direct peer-to-peer communication is unreliable across mobile networks, NAT, device sleep, and temporary disconnection. But the relay does not need to understand accounts, profiles, contact graphs, or long-term history. It should understand only a few temporary operations: open a one-time rendezvous; accept an encrypted envelope; return an encrypted envelope; expire the rendezvous. The relay should never receive plaintext or message keys. For the first prototype, rendezvous state and undelivered envelopes could live in memory. If the relay restarts, undelivered messages disappear. By ordinary messaging standards, this is poor reliability. By Amnesia’s standards, it is an intentional failure mode. The relay would still observe some metadata: network addresses, connection timing, message sizes, and temporary identifiers. A single relay would remain a point of observation and disruption. Those are real limitations. Later research could explore fixed-size encrypted cells, batching, cover traffic, one-time mailboxes, multiple relays, and censorship-resistant transports. Later. A prototype should not arrive wearing the feature list of a system that does not exist. Software already contains enough fiction. Information Starvation, Not Secret Design Amnesia should not depend on hiding its protocol. Applications can be reverse-engineered. Traffic can be recorded. Clients can be instrumented. An attacker can learn how the system works, often before the developer has finished explaining it in the README. The design should remain defensible when the adversary understands it. The objective is therefore not obscurity. It is information starvation . Even with complete knowledge of the protocol, an attacker should encounter as little durable material as practical: no permanent account identifier; no long-lived social graph maintained by the service; no reusable bearer credential; no intentional plaintext archive; no provider-controlled recovery path; short-lived relay state; rapidly expiring capabilities; cryptographic separation between identity epochs. This does not make participants invisible. It attempts to reduce what can be recovered later. That distinction matters because “anonymous,” “untraceable,” and “forensically impossible” are excellent words for attracting attention and terrible words for describing real systems. RAM-Only Is Not a Magic Spell It is tempting to say that keeping everything in memory means nothing can survive. This is the point where a design document should be struck gently with a rolled-up threat model. Applications do not control the entire device. The operating system may produce crash reports. Memory may be paged or captured. Notifications may expose content. A keyboard may learn entered text. Screenshots may be taken. Malware may observe the screen. A recipient may preserve a message with another camera because the analogue world continues to sabotage our finest abstractions. Flash storage creates another problem: wear levelling means an application generally cannot guarantee that overwriting a logical block erased every historical physical copy. The defensible approach is narrower: never intentionally persist plaintext; avoid databases, drafts, previews, caches, analytics, and backups; keep secret material alive for the shortest practical time; encrypt unavoidable temporary storage with a fresh session key; destroy that key when the session ends; continuously test for accidental persistence. Amnesia should aim for strong forensic resistance within the application’s control , not forensic impossibility. It cannot protect an already compromised endpoint, and it cannot stop a recipient from preserving what they receive. Its principal target is later compromise: someone gains access to a device or relay after the session and finds less useful history waiting for them. Less is not none. Security writing becomes healthier once those words are allowed in the room. Testing Whether “Forget” Means Anything The most valuable part of Amnesia may turn out to be its persistence test harness. “Disappearing” is easy to print on a button. It is harder to demonstrate after the application, operating system, logging framework, and helpful crash reporter have all had their turn. A test session can generate unique markers: AMNESIA_TEST_MESSAGE_7D39A2 AMNESIA_TEST_CONTACT_B19F44 AMNESIA_TEST_KEY_82C0E1 An emulator or test device is snapshotted before the session. The automated test then creates a relationship, exchanges marked messages, ends the session, terminates the application, captures writable state afterward, and searches files, preferences, logs, databases, caches, crash data, and temporary storage for those markers. The test fails if controlled sensitive material remains. The harness should also inspect file-system changes, serialized state, key-store aliases, known storage locations, and unexpected writes. Repeated tests should cover crashes, forced termination, interrupted cleanup, upgrades, and device reboot. This cannot prove that no physical artifact exists anywhere in the hardware. It can provide repeatable evidence that the application did not intentionally preserve the tested state and did not leave obvious recoverable copies in the areas being measured. That is a smaller claim than “nothing remains.” It is also a claim one can test, which gives it the unusual advantage of meaning something. This Is Civil Technology Privacy technology is routinely pushed into a childish moral binary. Either everyone accepts persistent identification and monitoring, or anyone resisting it is presumed to be hiding something dreadful. That is not a serious foundation for a free society. Governments seek broader surveillance capabilities. Companies retain behavioral history because data has commercial value. Platforms normalize permanent identity, contact discovery, cloud retention, and cross-device synchronization because continuity improves engagement. The result is not one totalitarian control room with an enormous red button. It is something more ordinary: records, identifiers, relationships, locations, sessions, and behavioral traces distributed across states, platforms, telecom networks, vendors, and personal devices. A bureaucratic Big Brother. Many databases. Several dashboards. Probably a procurement framework. Amnesia is not conceived as technology for crime. It is conceived as civil technology : open infrastructure that reduces how much power a communication system accumulates over the people using it. Private communication matters to families, journalists, lawyers, researchers, businesses, abuse survivors, whistleblowers, political opposition, organizers, and citizens who have done nothing more sinister than prefer not to manufacture a permanent record of every human relationship. The stakes become sharper under censorship and political repression. Across history, people living behind iron curtains, under military dictatorships, or inside states hostile to independent contact have faced serious risks for speaking to outsiders, organizing, reporting abuse, or accessing independent information. The specific regimes change. The mechanism does not. Control communication. Preserve relationships. Search devices. Identify networks. Punish contact. A secure messenger cannot eliminate those dangers. Possession of the application may itself be incriminating. Networks may be blocked. Phones may be searched while unlocked. Contacts may be coerced. Devices may contain spyware. Traffic patterns may still reveal that communication occurred. It would be irresponsible to promise that Amnesia could make someone safe in such an environment. But reducing recoverable identity, history, credentials, and social graphs can still matter. In some situations, leaving less behind may reduce the evidence available after device seizure, border search, arrest, domestic intrusion, or later compromise. In the most serious cases, that may reduce risks that become life-threatening. Not because the software is magical. Because information that was never retained is harder to extract later. That is the humanitarian premise. The Longer-Term Idea: AmnesiaOS A messenger installed on an ordinary smartphone inherits the environment around it: vendor services, cloud integration, third-party applications, persistent identifiers, a baseband modem, and a long history of trying to be helpful in ways the user did not request. The longer-term concept is therefore larger than an application. A future AmnesiaOS could combine hardened mobile security, disposable runtime sessions, verified immutable system images, and strict compartmentalization. It would have no general app store, browser, cloud account, third-party keyboard, or persistent user profile. Identity, contacts, relay capabilities, messages, and keys would exist only inside a temporary communications environment created at boot. It would be closer to a phone-shaped encrypted terminal. When the device shuts down, the identity epoch ends. This is ambitious, expensive, hardware-dependent work. It is not the current project. The messenger must first prove its lifecycle before anyone designs a heroic operating system and discovers, several years later, that Bluetooth has opinions. What Exists Today Today, Amnesia is an architectural direction and an early prototype project. It is not audited. It is not production-ready. It should not be used for sensitive communication. The current milestone is deliberately modest: Two disposable clients establish a temporary encrypted relationship, exchange text through a minimal relay, terminate the session, and become unable to recover the previous application-controlled identity or conversation state. Before custom operating systems, anonymity networks, post-quantum group protocols, or high-risk deployment, the project must prove that lifecycle. Create. Connect. Communicate. Forget. Four verbs. An unreasonable amount of work. Why Build It in Public? The protocol, source code, threat model, test vectors, limitations, persistence results, and failed assumptions should be public. If learning how Amnesia works is enough to defeat it, Amnesia does not work. Public development gives cryptographers, privacy engineers, mobile-security researchers, usability specialists, and affected communities an opportunity to challenge the design before marketing discovers it and begins using the phrase “military-grade.” The project does not need confidence theatre. It needs scrutiny. Most communication systems ask: How can we securely preserve the user’s account, relationships, and messages? Amnesia asks: How little can we preserve while still allowing two people to communicate? The result may be less convenient, less reliable, and less familiar than existing messengers. It may remain a specialist tool. It may fail as a product while still producing useful research. That would be enough to justify the experiment. We have spent years teaching software to remember us: more devices, more history, more synchronization, more recovery, more continuity. Perhaps one system should be taught the opposite skill. Not secrecy. Not magic. Just the discipline to let go. Amnesia is an independent, intended-to-be-open-source research project. Readers who want to support prototype hardware, relay hosting, persistence testing, and continued development can do so through Ko-fi .