Inside Freenet’s Attempt to Build Applications Nobody Owns
Open River in a browser and it looks, at first, like an unremarkable group-chat application. There is a room, a list of members, a message field, invitations, private conversations, and the familiar small rituals of online community. Nothing about the screen announces a revolution in distributed systems.
The important part is what is missing.
There is no River company operating a River database. There is no central River server through which every message must pass. The browser speaks to a Freenet peer running on the user’s own computer. The room’s code and shared state are distributed through a peer-to-peer network. Other participants’ computers help store, reconcile, and deliver it. If the original developer disappears, the room does not necessarily disappear with him. If a hosting company closes an account, there is no River hosting account to close.
This is the proposition behind the new Freenet: an application should be able to exist without belonging to a platform operator.
That proposition is more radical than simply encrypting a conventional service. Encryption can prevent an operator from reading a message, but the operator may still control the account, the software, the directory, the recommendation system, and the servers on which the service depends. Governments can pressure that operator. App stores can remove its software. Hosting providers can terminate it. A company can alter its rules, quietly suppress material, or vanish.
Freenet attempts to remove that center of control. It replaces the conventional application backend with a network of equal peers and replaces private server logic with public, cryptographically identified code. Its advocates describe this as “apps without platforms” or “services without servers.”
Both phrases need interpretation. Machines still store data and serve it to other machines. A peer performing those functions is, in the ordinary English sense, serving something. What Freenet eliminates is the dedicated application server and the central operator who owns it. Every participant’s computer can be both client and infrastructure. The backend is the network itself.
That design could make certain forms of censorship, coercion, and corporate control much harder. It does not make them impossible. Freenet cannot restore a country’s severed internet cable, prevent a government from blocking its traffic, conceal the identity of a careless user, or save a compromised computer. The software is in alpha, the live network is small, and several of its most difficult security and scaling problems remain open.
It is nevertheless one of the more serious contemporary attempts to ask what the web would look like if nobody possessed its master switch.
Two Freenets, One History
Before explaining the system, one confusion must be cleared away. There are now two projects in the world with a legitimate claim to the Freenet name.
Ian Clarke began the original Freenet as a student at the University of Edinburgh in 1999. The design became an influential anonymous, censorship-resistant system for publishing and retrieving information. Material inserted into the network was divided, encrypted, cached, and passed among nodes. A user asking for a document did not necessarily know where it was physically stored, and the node supplying it did not necessarily know who had originally requested it.
The original system was sometimes described as a decentralized hard drive. It was well suited to publishing information that should be difficult to erase, but much less suited to the constant mutation expected of modern interactive applications. A static document can be identified by its cryptographic hash. A chat room, collaborative document, or social feed changes from one moment to the next.
That original network still exists. In 2023 its maintainers renamed it Hyphanet. Hyphanet remains the project for readers interested in the original Freenet design, including its privacy-oriented publishing, caching, “opennet” operation, and friend-to-friend darknet mode.
The project now called Freenet is a different system. Clarke began developing it in 2019 under the working name Locutus. It was rewritten from the ground up in Rust and is not compatible with Hyphanet. In 2023, Locutus took the Freenet name while the older project became Hyphanet—a decision the present Freenet FAQ acknowledges was not supported by the old system’s maintainers.
The shared name indicates lineage, not continuity of software.
The distinction matters most in one area: anonymity. The original Freenet was designed around anonymous publishing and retrieval. The new Freenet is designed around decentralized applications. Its requests travel through chains of peers, so no single intermediate peer necessarily sees an entire route, but the project explicitly says that it is not an anonymity network and should not be relied upon as one. It is not a substitute for Tor or I2P. Applications may build additional privacy systems on top of it, but anonymity is not a guarantee supplied by the base network.
Calling the new Freenet “anonymous Freenet reborn” would therefore be dangerously wrong. It is an incompatible system pursuing a different ambition.
Control Follows the Server
The argument for Freenet begins with an architectural fact so ordinary that it is easy to overlook: nearly every online service has an owner.
A conventional application usually depends upon a company, domain name, cloud account, database, authentication service, content-distribution network, app-store listing, and administrative hierarchy. That arrangement is efficient. It also concentrates power.
Whoever controls the servers can suspend an account, inspect stored information, change a feed, delete a community, alter the software, or terminate the service. Even where the operator is principled, it sits inside a chain of intermediaries that may be less so. A registrar controls the domain. A cloud provider controls the tenancy. A mobile platform controls the application’s distribution. A payment provider controls its revenue. A government does not have to defeat the entire internet when it can identify the small number of organizations upon which a service depends.
This is not only a question of visible takedowns. Discovery has become a powerful control plane. A platform may leave a video or article technically available while adjusting search and recommendation systems so that few people encounter it. The public sees the content but not the ranking machinery around it. Suppression can become probabilistic, personalized, and almost impossible to prove.
Clarke’s July 2026 presentation placed Freenet within a climate of expanding online regulation and government pressure on platforms. Some of his examples were rhetorically broader than the underlying legal actions. The European Union’s €120 million fine against X, for example, concerned verification design, advertising transparency, and researcher access under the Digital Services Act—not a simple fine for “disinformation.” California’s AB 1043 establishes an age-signal framework beginning in 2027, but does not generally require every user to submit government identification. The French case against Telegram founder Pavel Durov involves allegations about cooperation and complicity in serious criminal activity, not merely responsibility for any statement a user posts.
Those distinctions matter. A system dedicated to resisting information control should not build its case on imprecise descriptions of the controls it opposes.
The architectural argument survives the corrections. Governments are increasingly willing to pressure services over speech, safety, crime, age assurance, data access, and recommendation systems. Corporations already possess enormous unilateral authority over accounts and visibility. Freenet’s answer is not a better platform policy. It is the removal of the platform operator as the obvious party to compel.
That does not make law or power disappear. It changes where they must be applied.
A Global Programmable Store
The simplest reasonably accurate description of Freenet is that it is a global programmable key-value store distributed across its users’ computers.
A conventional key-value store resembles an enormous cabinet. Give it a key and it returns the value filed under that key. In Freenet, however, the key is tied to a small program called a contract, compiled to WebAssembly. The value is the contract’s current state.
The contract does more than identify the data. It defines what valid state looks like, who may modify it, how proposed updates are evaluated, and how different copies are reconciled when they have changed independently.
Around that public state Freenet builds three main components.
Contracts hold the application’s shared, replicated information. Delegates run locally and hold private information such as signing keys. User interfaces are ordinary web frontends—HTML, JavaScript, and WebAssembly—delivered through Freenet and displayed in a browser. The interface communicates with the Freenet Core on the user’s computer, and the Core communicates with the wider peer network.
This division is the heart of the architecture: public state in contracts, private state in delegates, and human interaction in the browser.
Contracts: Rules That Travel With the Data
Consider a group-chat room. Its shared state may include the room’s membership, configuration, messages, invitations, and moderation actions. In a centralized service, these records sit in a database and private server code decides whether a new message is accepted.
In Freenet, the room contract contains public code capable of making that decision. It can require that a message carry a valid signature from a recognized member. It can reject malformed state or an unauthorized update. Every peer handling the contract can run the same validation logic.
A contract’s address is derived cryptographically from its exact WebAssembly code and fixed parameters. This is content addressing applied not merely to a document, but to the rules governing mutable state. If someone changes the code, the cryptographic identity changes. A malicious peer cannot quietly replace the contract’s validation rules while continuing to present the same address.
That property provides integrity, not magic. Software can contain bugs. A developer can write rules that are foolish, unfair, or exploitable. An application upgrade must also account for the fact that altered WebAssembly produces a new contract key. Freenet’s developer guidance describes patterns for anchoring an application to a stable owner identity and carrying state forward, but applications must be designed for that transition. The network makes the governing code inspectable and tamper-evident; it does not guarantee that the code is good.
The deeper problem is synchronization. In a peer network, different computers may receive updates in different orders. Two people can post while separated from one another. A temporarily disconnected peer may return with older state. Freenet does not solve this by forcing every node in the network to agree on a single global sequence.
Instead, each contract defines a merge operation. The operation must behave in three important ways. Combining A with B must produce the same result as combining B with A. Combining the same information twice must not change the result. Grouping several merges differently must still arrive at the same destination.
Computer scientists describe this in the language of idempotent commutative monoids, join-semilattices, and conflict-free replicated data types. The practical meaning is friendlier: updates can arrive late, out of order, or more than once, and honest replicas should still converge.
For a chat room, a simplified state might be the union of all properly signed messages. If Alice’s peer learns about one message and Bob’s peer learns about another, neither has to win. When their states meet, the contract keeps both.
This allows Freenet to avoid the cost of a blockchain’s universal consensus. Ethereum and related systems arrange transactions into an authoritative global order because money cannot tolerate two mutually exclusive spends being accepted simultaneously. A chat room does not need every message worldwide placed into one ledger. It needs its own replicas to agree on which valid messages exist.
The trade is equally important. Freenet’s merge model is well suited to chat, collaborative documents, directories, feeds, reputation records, and asynchronous mail-like systems. It is not naturally suited to a currency in which exactly one of two simultaneous attempts to spend the same balance must succeed. The project’s whitepaper states plainly that double-spend protection cannot be expressed cleanly in a single current Freenet contract without pushing conflict handling into application code or adding another consensus mechanism.
Freenet is not a blockchain without coins. It is making a different consistency bargain.
Delegates: Private Agents on the User’s Machine
Contracts are public. Any peer able to retrieve a contract may be able to read its state. That makes them the wrong place for a private signing key, confidential contact list, or mailbox decryption secret.
Freenet places such information in delegates. A delegate is another WebAssembly component, but it runs locally inside the user’s Freenet Core and does not appear on the network’s routing ring. Other components communicate with it through messages. They cannot simply read its internal state.
Suppose an application needs to sign a message. Instead of handing the private key to browser code, the application asks a delegate to sign a particular payload. The Freenet Core identifies the component making the request. The delegate can enforce a policy—allowing this application to sign this kind of message, for example—then return the signature without revealing the key.
The model resembles a small local cryptographic agent. It is conceptually similar to the security boundary of a password manager or software wallet: applications request operations rather than receive secrets.
That is valuable, but the boundary must be stated accurately. A malicious interface may still persuade a permissive delegate to authorize something the user did not intend. A compromised Freenet Core controls the environment in which delegates run. Malware with sufficient access to the host may defeat the entire local trust model. The design does not turn an ordinary laptop into trusted hardware, and the whitepaper says cross-device synchronization of delegate state remains only partially implemented.
The defensible claim is that delegates can prevent applications from extracting raw private keys through their normal interface. “Your secrets can never leave your device” is too absolute.
Finding Peers and Finding Data
Freenet organizes peers and contracts around a conceptual ring. Each contract is assigned a position derived from its cryptographic identity. Peers also occupy locations, and contract state is replicated among peers near the contract’s position.
Every peer knows nearby neighbors and maintains some longer-range connections. The result is a small-world network: dense local relationships combined with shortcuts across greater distances. A request moves from peer to peer toward the portion of the ring associated with the desired contract. No participant needs a complete directory of every peer and every object.
If the structure works as intended, the number of hops grows slowly as the network becomes larger. Freenet’s May 2026 whitepaper reported a live network of approximately 440 active peers and routing behavior consistent with logarithmic growth at that size. That is encouraging, but it is not proof that the same behavior will hold for hundreds of thousands or millions of users. The whitepaper itself calls proper scaling characterization an open problem.
Routing is adaptive. Peers observe which neighbors successfully deliver requests at different distances and how long those requests take. Current project material describes a system called Renegade, which uses learned nearest-neighbor prediction; the whitepaper describes per-neighbor models using isotonic regression. These are compatible descriptions at different levels: Renegade uses learned distance and regression techniques to decide which past observations best predict a useful route.
The important point is that routing is not merely a static instruction to choose the numerically closest neighbor. Peers learn from experience.
Connections use UDP, network-address-translation hole punching, an X25519 key exchange, and authenticated encryption. This helps peers behind ordinary home routers connect without manual port forwarding. It also means strict corporate networks that block the necessary UDP traffic may prevent Freenet from working.
Transport encryption is hop by hop. If a request travels from A through B and C to D, each neighboring connection is authenticated and encrypted, but B and C remain active participants in forwarding. An intermediate peer can drop, delay, reorder, or alter a payload. End-to-end integrity therefore comes from the application layer: signatures and the contract’s validity rules allow receiving peers to reject invalid state.
This difference between integrity and availability is fundamental. Cryptography can reveal that a malicious peer forged an update. It cannot force that peer to answer, forward a request, or provide the newest valid state.
How Freenet Resists Censorship
Freenet’s most powerful feature is not that it defeats every censor. It is that it removes one particularly cheap and effective censorship mechanism: control over the platform operator.
If a government pressures an ordinary social network, the company can remove a page. If it pressures a hosting provider, the provider can terminate a server. If it pressures an app store, the store can prevent new installations. If it seizes a domain, users lose the familiar route to the service. If it secretly pressures a platform to alter recommendations, information can become harder to find without being formally banned.
A properly decentralized Freenet application responds differently.
There may be no application company capable of deleting its contract. There is no single hosting account to close. Contract state is replicated, so losing one peer does not necessarily remove it. The application’s rules are content-addressed, making an undetected backend substitution difficult. A browser-based application can be distributed through Freenet without obtaining a separate app-store listing, although users still need the Freenet Core. Discovery systems can, in principle, allow users to choose among competing indexes and ranking policies rather than accept a proprietary universal feed.
The phrase “in principle” is doing work. Atlas, Freenet’s emerging discovery layer, has a live first version, but its repository describes that version as early and read-only. The broader design—open descriptors, reviews, publisher submissions, and competing indexes—is still taking shape. Freenet has demonstrated a direction for decentralized discovery; it has not finished solving the gatekeeper problem.
Nor is replicated data automatically permanent. Freenet peers operate within storage budgets and use caches. Material remains available while peers continue to host it, subscribe to it, retrieve it, or otherwise sustain demand. A publisher who wants reliable persistence should keep a subscribed peer online. “No central server” does not mean “infinite storage forever.”
A censor also has other tools.
An internet service provider or national firewall may block Freenet’s UDP traffic or recognizable bootstrap mechanisms. A government controlling the physical network can throttle it, isolate a region, or shut connectivity down. Initial installation and peer discovery create practical pressure points. Existing peers can continue forming connections after the original gateways disappear, according to the whitepaper, but new users still require software and a way into the network.
Freenet also does not protect an identified person from legal or physical coercion. It does not promise to hide IP addresses or social relationships. An application may encrypt message content while still exposing timing, approximate size, membership patterns, or the existence of a room. A user who publishes identifying details can still identify himself.
The most accurate formulation is therefore narrower than “uncensorable internet”:
Freenet removes the central platform operator as a single point of censorship. It does not remove control over the wire, the device, the user, or every peer surrounding a piece of data.
That is not a small achievement. It means a government or corporation may have to move from a cheap administrative order against one intermediary to more expensive technical blocking, broader surveillance, infiltration, or direct coercion. Architecture cannot abolish power, but it can change its cost.
Installing and Trying Freenet
There are two ways to encounter the current system, and they provide very different levels of decentralization.
The easiest is the hosted demonstration at freenet.org/try. It allows a visitor to enter a live River room through a browser without first installing the Freenet Core. The user’s local data is encrypted at rest with a key held in the browser, and the interface offers a path to export that data to the user’s own peer.
This is a demonstration bridge, not the final trust model. The JavaScript still arrives from infrastructure operated by the Freenet project. A malicious or compelled operator could theoretically serve altered code designed to capture the browser-held key. Clarke acknowledged this limitation directly in his July talk. The hosted version demonstrates the applications and lowers the barrier to entry; it does not eliminate the need to trust the party serving the code.
Running a peer is the more meaningful experience. Freenet currently provides desktop installation paths for Windows, macOS, and Linux. There is no mobile application.
Before installing, readers should put the project’s own warnings first. Freenet is under active development. Peers auto-update as the network evolves, and old versions may cease to interoperate. Diagnostic telemetry includes peer activity and general system information such as operating-system type. The project expressly says not to use alpha builds for anything sensitive.
Windows users can download and run the project’s installer. On macOS, the current application is distributed as a disk image and runs from the menu bar. The official Linux quickstart supplies this command:
curl -fsSL https://freenet.org/install.sh | sh
Piping a remote script directly into a shell is convenient, but it prevents meaningful inspection before execution. A more cautious Linux user can download the same script first:
curl -fsSL https://freenet.org/install.sh -o /tmp/freenet-install.sh
less /tmp/freenet-install.sh
sh /tmp/freenet-install.sh
This is not a complete code audit; the installer may download additional components. It at least gives the administrator an opportunity to inspect the initial actions and confirm that the address is correct.
The installer starts Freenet as a background service. Applications are then exposed through the local browser interface, ordinarily on 127.0.0.1 at port 7509. The official quickstart issues an invitation to the Freenet project’s River room. The first load can be slow while a new peer establishes itself and retrieves the required contracts. If the invitation opens River without completing the join, the documented troubleshooting step is:
freenet service restart
The user can then request a fresh invitation. River also offers a command-line client, riverctl, for terminal use and automation.
Removing a normal user installation is equally direct:
freenet uninstall
The command asks before deleting data, configuration, cache, and logs. The --keep-data option preserves them. A system-wide installation requires the corresponding elevated procedure; the project warns users not to add sudo casually to the ordinary per-user uninstall command because the binary may not be in root’s path.
This is alpha software. A prudent reader should test it on a noncritical machine or disposable user account, understand the telemetry, and avoid importing sensitive identities or conducting high-risk communications. Installation is participation in an experiment, not the deployment of mature protective infrastructure.
What Works Today
River is the most visible proof that Freenet can support real-time shared applications. It provides public and private rooms, invitations, moderation, direct messages, browser access, and a command-line client.
Private rooms encrypt their names, descriptions, member nicknames, and message bodies with AES-256-GCM. A room secret is distributed to members using X25519-based public-key encryption. The secret rotates every seven days, when an owner bans a member, or when an owner requests a manual rotation.
This is meaningful end-to-end content protection, but it is not Signal’s double ratchet or the Messaging Layer Security protocol. River uses a shared room key so that members can decrypt the room’s state and history without having been online for every message. The cost is coarser forward secrecy: compromise of a current room secret may expose material protected by that key until rotation. The room contract, activity timing, approximate message sizes, and relationships among participants may also reveal information even when message bodies remain unreadable.
River is a capable experimental application. It should not yet be described as a Signal replacement.
Delta is a decentralized publishing system. It allows an author to create pages and small sites from Markdown, images, and links, then distribute them as Freenet contract state. The familiar analogy is a very young WordPress or Squarespace without the hosting account. Its most important limitation is the network’s general persistence rule: a site survives while peers continue to host or request it. Authors seeking assured availability must help provide that availability.
Atlas addresses the question every alternative network eventually encounters: how does anyone find anything? The long-term design supports signed descriptions, crawlers, curators, reviews, indexes, and different ranking policies. Users could select which sources of discovery they trust instead of submitting to one global search authority. The first live version is a populated front door, not the completed pluralistic system.
Freenet-git publishes Git repositories directly into Freenet contracts. A standard Git remote helper allows clone, fetch, and push operations without GitHub, GitLab, federation, or a server operated by the repository owner. The repository state can be signed, and larger pack files can be divided among multiple contracts.
That decentralizes repository storage. It does not yet recreate everything surrounding a modern development forge. Issue tracking, pull requests, continuous integration, code review, project management, social discovery, and abuse response remain separate problems.
Other projects are earlier. Mail aims at encrypted asynchronous communication. Raven is a social-feed prototype. Harvest explores a decentralized marketplace. These projects show the intended breadth of the platform, but the existence of a repository or demonstration should not be mistaken for production maturity.
Ghost Keys and the Cost of Being Nobody
Decentralization creates an old problem in a particularly sharp form: if identities are free, an adversary can create thousands.
Centralized services fight disposable identities with phone verification, government identification, captchas, device fingerprinting, payment details, and behavioral surveillance. Those methods inconvenience attackers while collecting information from everyone else. Freenet needs a way to make abusive identities costly without requiring a universal real-name authority.
Ghost Keys are one experimental answer. A user donates at least one dollar to the Freenet nonprofit. The browser generates a cryptographic key and blinds the public portion before sending it to the donation service. The service confirms payment and signs the blinded key without learning the actual key it authorized. After the signature is unblinded, the user holds a verifiable credential proving that someone paid to create it, while the payment processor cannot directly link the credential to the donor.
Applications can require such a credential for posting, voting, or accumulating reputation. Creating a thousand disposable identities would then cost at least a thousand times more than creating one. The private key lives in a delegate called the Ghostkey Vault, which can sign for applications without exporting the raw key.
The compromise is deliberate. Issuance still relies on a central donation processor. Blind signatures protect the relationship between payment and issued key, but repeated use of one Ghost Key creates a persistent pseudonym. Messages signed by the same key can be correlated across time and, if reused, across applications. The project plans bundles of keys and is considering zero-knowledge techniques, but those stronger unlinkability mechanisms are not the present system.
Ghost Keys do not solve Sybil attacks for the whole network. They provide one application-level building block for making reputation and access expensive enough to matter.
Moderation Without Universal Deletion
Removing the platform operator does not eliminate harmful material, harassment, spam, fraud, or coordinated manipulation. It removes the person who could once be expected—or compelled—to address them globally.
Freenet’s emerging answer is decentralized filtering and reputation. A River room can restrict membership, require invitations, validate signed messages, and ban participants. An index can decline to list material. A user can choose different curators, block sources, or trust a reputation system. Communities can enforce their own rules cryptographically.
What they generally cannot do is erase valid information from every copy across the network.
This is the moral and operational trade at the center of censorship-resistant systems. Central administration makes universal removal possible, but also makes political capture efficient. Decentralization protects publication, but forces moderation to become local, plural, and sometimes incomplete.
It also changes the nature of censorship. An adversary need not delete a discussion if it can bury it under automated junk, poison discovery, impersonate participants, or exhaust the resources of those hosting it. In a network without a central admission authority, resistance to spam and Sybil identities is not peripheral housekeeping. It is part of the censorship problem itself.
How Freenet Differs
Freenet occupies a different layer from several projects with which it is easily confused.
Tor and I2P are primarily anonymity and routing systems. They help users reach services without exposing the whole path, but the destination may still be a conventional server with an identifiable operator. Freenet attempts to decentralize the service itself. A privacy-sensitive application could conceivably need both kinds of protection.
Hyphanet, the original Freenet, emphasizes anonymous, censorship-resistant storage and publishing. The new Freenet gives up built-in anonymity in pursuit of mutable, responsive applications.
IPFS provides content-addressed distributed storage, especially for immutable objects. Freenet places application-defined mutation, validation, reconciliation, and subscription at the center of its contract model.
Blockchains provide a globally ordered state machine secured through consensus. That is valuable where transactions must be authoritative and mutually exclusive. Freenet avoids global consensus, fees, and universal transaction ordering in favor of eventual convergence inside each contract.
Federated systems such as Matrix or Mastodon distribute control among many server operators. Federation is a substantial improvement over one company controlling everything, but users still depend on identifiable administrators who control accounts, policies, and infrastructure. Freenet attempts to replace the federation of servers with a network of peers.
Nostr, Secure Scuttlebutt, Hypercore, and related systems often revolve around signed events, feeds, relays, or append-only logs. Freenet’s distinctive claim is that each contract brings its own definition of valid state, its own merge algebra, and its own efficient synchronization rules.
None of these comparisons produces a universal winner. Each design protects a different boundary and accepts different costs.
The Unsolved Problems
The strongest argument for taking Freenet seriously is not that its developers claim to have solved decentralization. It is that the project’s whitepaper identifies the places where they have not.
The first problem is scale. A live network of roughly 440 peers can reveal implementation failures and provide meaningful routing data. It cannot establish that the same topology, storage model, and adaptive routing will support millions of people. The observed behavior is consistent with the desired scaling curve; it is not proof of it.
The second is Sybil resistance. Freenet assigns a peer’s ring position by hashing an externally observed network prefix—the IPv4 /24 or IPv6 /48 rather than every individual address. This makes it more expensive for an attacker to create many peers at chosen locations, because thousands of addresses in one subnet do not produce thousands of positions.
It remains a mitigation, not a defense. A well-resourced attacker can rent machines across many prefixes, use a botnet, obtain diverse cloud addresses, or cooperate with an internet provider. By concentrating hostile peers around the location of a targeted contract, the attacker may crowd out honest replicas, suppress writes, or return stale-but-valid state.
Contract signatures can expose outright forgery. They cannot prove freshness or compel delivery. The whitepaper candidly notes that safety-critical contracts may require geographic diversity, separated replicas, or out-of-band trust anchors the platform does not yet provide.
The third problem is coordinated denial of service. Freenet limits the bandwidth, storage, processor time, and memory one neighbor can consume. WebAssembly contracts run with fuel and memory bounds. A peer that exceeds its allowance can be disconnected. These controls contain one abusive neighbor; they do not stop a distributed flood from thousands of cheap identities, particularly if each remains just below individual limits.
Congestion control is also unfinished. The production default is a fixed-rate token bucket. More sophisticated LEDBAT++ and BBR-style approaches exist experimentally, but the project says neither has yet been adapted satisfactorily. Efficiently sharing heterogeneous home, mobile, and institutional links at large scale remains open work.
Contracts introduce their own failure mode. If a developer writes a merge operation that is not genuinely commutative, associative, and idempotent, honest replicas may diverge. The current platform can make that divergence observable but does not automatically repair it. A decentralized application moves responsibility out of a company’s private backend, but it does not remove the need for rigorous software engineering.
Availability is conditional. Peers have finite storage. Cold, abandoned, or unwanted data may disappear if nobody continues to host or request it. The absence of a central server means there may also be no service-level agreement, backup operator, recovery desk, or organization responsible for preserving an application after its community leaves.
Anonymity is not included. Encryption may protect content, while network addresses, timing, room participation, social relationships, and user behavior remain exposed at other layers. People facing serious personal danger should not treat Freenet’s decentralization as personal concealment.
Finally, the local computer is decisive. A delegate cannot protect a signing key from a Freenet Core or operating system that is already compromised. Browser interfaces remain software and can contain vulnerabilities. Auto-updating alpha code introduces a project-level trust relationship even if individual applications have no central operator. “Nobody runs the network” does not mean nobody writes the software on which its participants rely.
Censorship Resistance by Subtraction
Return to the River room.
The significant innovation is not its message field or encryption algorithm. It is the absence of the organization that would ordinarily stand behind them. The room exists as code, signatures, and replicated state across people who choose to participate. Its owner can govern membership, but there is no River corporation controlling a universal backend.
Freenet’s deepest proposition is that political pressure becomes harder to convert into technical disappearance when nobody possesses a master switch.
The missing switch has costs. There is no universal emergency stop, no effortless global moderation, no guaranteed permanence, and no central party promising to restore service. The same architecture that protects dissidents can protect fraudsters. The same freedom from a platform’s secret ranking can expose users to competing systems of manipulation. The same easy admission that helps a new community form helps an attacker manufacture peers.
Freenet has not built an invulnerable internet. It cannot presently promise anonymity, national-firewall evasion, mass scale, resistance to coordinated denial of service, or safe use by people whose liberty depends upon operational security. Its developers do not claim all of those things, even when the project’s more expansive slogans can sound as though they do.
What Freenet has built is a working argument: modern applications do not necessarily require a company-controlled backend. Contracts can carry public rules with public state. Delegates can hold private secrets locally. Peers can find one another, reconcile changes, and keep an application alive without asking a platform for permission.
That is already consequential. It moves the censorship question out of the terms-of-service department and into distributed-systems engineering, where the weaknesses can be identified, measured, tested, and attacked directly.
Whether the design can survive hostile governments, hostile peers, sudden mass adoption, ordinary users, and its own unfinished engineering is now the experiment.
Jonathan Lockhart is a cybersecurity researcher and investigative journalist at bordercybergroup.com.
If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — subscribe, comment, or buy us a coffee! Thanks.
Member discussion: