Freenet as an Anonymity Substrate

Responding to this talk from Ian at Freenet.

Ian’s talk arrives at an important conclusion: asking whether Freenet is “anonymous” is too imprecise to be useful. The meaningful question is always: anonymous against whom, possessing what capabilities, and observing which parts of the system?

That distinction becomes especially important when we imagine a journalist, dissident, whistleblower, or aid worker operating in hostile territory. Such a person may need to communicate internationally, exchange documents, and maintain a private relationship with a source. Exposure might mean surveillance, imprisonment, torture, or death. “The messages are encrypted” is therefore nowhere near sufficient. An adversary may not be able to read the messages, but may still learn who is communicating, when they communicate, how much data they exchange, and which machines appear to be connected.

The question is whether an independent developer could build an application on Freenet that addresses those problems more seriously than ordinary Freenet usage does.

The answer is yes—but only if we understand exactly what Freenet contributes, what the application must add, and where the boundary between the two remains.

Freenet is a substrate, not a finished anonymity system

Freenet supplies a decentralized environment in which applications can publish, retrieve, update, and subscribe to replicated state. Its current architecture describes contracts as application-controlled state machines synchronized through summaries and deltas, with a delegate model for private state. It does not describe contracts as conventional servers or unrestricted distributed-computation workers.

A Freenet contract can validate whether an update is authorized. It can reject malformed or replayed state transitions. It can preserve an append-only history. It can ensure that independent participants reconstruct the same state. It can provide a decentralized mailbox, rendezvous object, game ledger, document index, or encrypted message history.

But the contract does not automatically conceal the existence of the communication. It does not automatically conceal the timing of updates. It does not automatically prevent observers from identifying recurring participants. It does not automatically make relay operators trustworthy or independent.

The contract protects the integrity and logic of the application. The surrounding client and network overlay must provide confidentiality and anonymity.

That division is consistent with what we have already learned through the Backgammon project. Our application’s authenticated identities, signed actions, deterministic replay, stale-action rejection, cross-node convergence, and reconnection logic establish whether a game state is valid. They do not make the players anonymous. The same architectural separation would apply to a private communications system.

The contract would protect correctness. The application would protect the content. An additional overlay would attempt to protect the relationship between the communicating parties.

The adversary determines the answer

A random Freenet peer may see only traffic adjacent to itself. It may know that it forwarded a request, but not whether the immediately preceding peer originated that request. It may not know the eventual destination or the complete route.

That is useful, but it is not the same as protection against a national intelligence service.

A hostile peer positioned along a route might observe the contract being accessed, approximate request size, timing, and neighboring network activity. Several cooperating peers might compare what they observe. An adversary capable of observing traffic at multiple Internet exchange points, national gateways, or ISP networks may be able to correlate activity entering and leaving the system.

This is why encryption and anonymity must not be confused. Encryption protects the message. Anonymity attempts to obscure the social and temporal relationship surrounding the message.

What an independent developer can add

The first and most practical layer would be a private communications application using Freenet contracts as encrypted mailboxes and rendezvous points.

The application could use long-term signing keys to authenticate participants, separate encryption keys to protect messages, ephemeral session keys to limit the damage of key compromise, and authenticated message envelopes to prevent replay or substitution. Messages could be padded to standard sizes, attachments could be encrypted before publication, and local plaintext could be removed after successful processing.

Such an application could provide excellent confidentiality and integrity even if every contract update were visible to the network as opaque ciphertext.

It would not, by itself, provide strong anonymity.

To approach that goal, the application would have to minimize the metadata surrounding the encrypted communication. It could avoid public names, use opaque identifiers, separate discovery identities from messaging identities, rotate mailbox contracts, use one-time invitations, and keep the contact graph exclusively in encrypted local storage. It could avoid direct indicators such as “online,” “typing,” or “delivered immediately.” It could use fixed-size records and scheduled polling rather than visibly reacting to every message.

Those measures would make the traffic less informative. They would not make it invisible.

The Freenet anonymity overlay

The more ambitious design would add a routing overlay above Freenet itself.

Ian’s idea is conceptually straightforward. Instead of submitting a request directly to the ordinary Freenet routing system, the client first sends it through a series of relay contracts. Each relay receives an encrypted layer containing only the information required for its part of the route. The request eventually emerges from the overlay and enters Freenet as an ordinary request.

The return path can be protected in the same way.

In a properly designed protocol, the first relay would not know the final destination. The last relay would not know the original sender. Neither would know the plaintext. No single relay would possess the entire route.

This resembles onion routing, but resemblance is not proof. The difficult questions concern relay selection, malicious relays, collusion, timing, traffic volume, and the possibility that an attacker can influence the topology of the overlay.

A system that simply chooses three relays at random could easily select three machines operated by one adversary. A system that relies on an uncontrolled public relay pool could be vulnerable to Sybil attacks, in which one actor creates large numbers of apparently independent relays.

Relay selection would therefore become one of the central security problems. The application would need to consider administrative independence, geographic diversity, identity age, observed behavior, relay concentration, and path rotation. It would need to avoid assuming that different cryptographic identities represent different human operators.

Why contracts alone are not sufficient as real-time relays

There is also a practical architectural difficulty.

A Freenet contract is primarily a replicated state machine. A relay, by contrast, must receive traffic, process it, and forward it. A contract can represent relay state, but the actual forwarding may require a client or node hosting that state to observe changes and perform another operation.

That makes relay contracts potentially slow and conspicuous. They may accumulate state, attract subscriptions, require active participants, and become vulnerable to update flooding. A contract-based relay layer may be entirely appropriate for low-volume correspondence and document exchange, but it is much less obviously suitable for continuous real-time chat, voice, or video.

The strongest design for a journalist would therefore probably not imitate ordinary instant messaging. It would resemble an asynchronous encrypted postal system.

A source would deposit a message into an encrypted mailbox. The journalist’s application would retrieve it according to a schedule or through a privacy-preserving relay path. Replies would be deposited separately. Delivery might take minutes or hours rather than seconds. That delay would be a feature, not a defect, because immediacy creates correlation.

Timing is the great enemy

Suppose a journalist sends a message at 14:02:11. An observer sees activity from the journalist’s network connection, then activity through several relays, then a corresponding change near a suspected recipient. If this happens repeatedly, the observer may eventually infer the relationship even without reading a single byte.

The application would need to make genuine messages resemble other traffic.

That could involve fixed-size encrypted cells, scheduled polling, batching, randomized delays, dummy retrievals, decoy messages, and cover traffic. It might transmit at regular intervals whether or not the user has anything to say. It might intentionally delay a response so that the timing relationship between sender and recipient becomes less precise.

But every one of these protections imposes costs. Cover traffic consumes bandwidth. Padding increases storage requirements. Delays make conversations less convenient. Fixed schedules make the application less responsive. Mix-style routing turns a modern chat application into something closer to electronic correspondence.

The choice is not between perfect privacy and imperfect privacy. It is between different combinations of speed, convenience, bandwidth, and resistance to observation.

Configurable privacy levels

An independent developer could make the client itself a privacy-policy engine. Rather than displaying a vague “private” label, it could offer modes with clearly defined behavior.

The application could enforce the selected policy rather than merely recommend it.

In High-risk mode, for example, it could refuse to publish a plaintext file, refuse to use a public display name, refuse to subscribe directly to a known target contract, refuse to send an immediate acknowledgement, and warn the user when the current relay set is too concentrated.

It could also inspect documents and images before transmission. It could remove EXIF data, normalize filenames, warn about embedded author information, and identify metadata that might reveal a location or device. Network anonymity cannot compensate for a photograph that contains the photographer’s exact GPS coordinates.

The journalist’s system should be asynchronous

For a journalist whose source faces imprisonment or death, “private chat” should not initially mean a low-latency chat window.

A safer system would establish an authenticated relationship through an out-of-band invitation. Each participant would have a local identity, but the identity would not necessarily contain a public name. The application would create opaque mailboxes and use them as encrypted submission points. Messages would be padded, delayed, and retrieved through multiple possible paths. The participants would not receive an obvious online indicator or an instantaneous delivery receipt.

The public contract state might look like meaningless, regularly sized ciphertext. The application would know how to interpret it, but an outside observer would not see a readable conversation, recognizable usernames, or an obvious journalist-source relationship.

A more compartmentalized system could use several different contract roles: an opaque rendezvous state, an encrypted submission mailbox, and a separate encrypted response mailbox. Key material could be published independently from the conversation itself.

No single contract would reveal the entire social relationship.

Can one individual make their own Freenet usage more private?

Yes, but with an important limitation.

An individual can build an application that applies privacy rules to all traffic generated by that application. The application can route its own requests through relays, use separate identities, pad messages, schedule retrievals, and avoid direct public subscriptions.

It cannot automatically make every other program using the same Freenet node anonymous.

A browser application, a game, a document downloader, and a private journalist client may all generate different traffic patterns. Unless the Freenet node itself is modified or provides a supported global routing layer, a user-space application cannot force unrelated activity through its privacy overlay.

The application can control its own behavior. It cannot control the operating system, the network operator, the recipient, or every Freenet peer.

The division of responsibilities

The client should handle the parts of the system that depend on secrets, timing, and user policy. That includes encryption keys, onion wrapping, relay selection, path rotation, message padding, cover traffic, local storage, identity separation, and warnings.

The contract should handle deterministic state. That includes authorization, replay rejection, message ordering, mailbox consistency, quotas, expiration rules, and conflict resolution.

This is exactly the kind of division we established in the Backgammon project. The contract validates the state transition. The client creates and authenticates the action. The network transports the state but cannot be trusted to preserve availability or privacy by itself.

The project has already demonstrated authenticated identities, durable append-only histories, independent state reconstruction, cross-node convergence, and recovery after interruption. Those are valuable foundations for encrypted mailboxes. The new work would center on key exchange, private state, mailbox addressing, traffic shaping, relay selection, and operational security.

What the application cannot promise

Even a carefully designed system cannot guarantee that a hostile government will be unable to identify its users.

It cannot guarantee that a national-scale observer will be unable to correlate traffic. It cannot guarantee that a relay operator will not collude with another relay. It cannot guarantee that a user’s device has not been compromised. It cannot guarantee that a recipient will not reveal the conversation. It cannot guarantee that a document’s contents will not identify its author.

It cannot guarantee availability either. Peers may disappear. Traffic may be delayed. Contracts may become temporarily unreachable. A government may block Freenet connections. Cryptography can establish authenticity and confidentiality, but it cannot force a hostile network to deliver a message.

For a high-risk journalist, the application should therefore state its limitations directly:

This system provides layered end-to-end confidentiality, authenticated state, metadata minimization, and configurable resistance to traffic analysis over Freenet. Its protection depends on the selected threat model, relay independence, network observation capabilities, endpoint security, and user discipline. It is not a guarantee of anonymity or physical safety.

That is not a disappointing conclusion. It is the beginning of a serious one.

The deeper opportunity

Freenet’s most interesting contribution may be that it allows anonymity to become an application-level choice.

A public news reader may need little more than ordinary Freenet retrieval. A private discussion application may add end-to-end encryption and opaque identities. A confidential document exchange system may add padded mailboxes and delayed delivery. A journalist-facing system may add relay indirection, mix delays, cover traffic, identity separation, and strict local-security policies.

The entire network does not have to adopt one universal anonymity mechanism. Different applications can make different tradeoffs according to the danger their users face.

Ian is describing the architectural opening. An independent developer could turn that opening into a real system.

The task would not be to claim that Freenet is magically anonymous. It would be to construct a carefully specified privacy layer above Freenet, measure what it protects, test it against explicit adversaries, and ensure that the application never promises more than its architecture can deliver.

For ordinary private communication, that could be a practical and valuable application.

For hostile-territory journalism, it could become a serious research project—but it would need to be designed as a delayed, compartmentalized, traffic-aware communications system rather than simply “encrypted chat on Freenet.”

Jonathan Brown writes independent, decision-focused analysis on cybersecurity, infrastructure resilience, and operational risk, with an emphasis on primary-source verification and explicit uncertainty.

Support this work by sharing the briefing with operators who can act on it. Corrections supported by primary evidence are welcomed; material errors should be amended transparently. Feel free to subscribe, comment, or buy us a coffee! Thanks.

© 2026 Border Cyber Group. All rights reserved.