Signal
A local Freenet peer connected to the public network. Five healthy peers showed up. NAT traversal worked. The node subscribed to contracts for Atlas and River.
Then both apps returned HTTP 500.
The network had fetched the requested state, but the local node could not retrieve that state from its own store. The peer was connected. The application was unusable.
This split gives us a clean look at a larger problem. When a service removes its central server, reliability and accountability have to land somewhere else.
What changed
Freenet released version 0.2.115 on July 29. The project describes Freenet as a peer-to-peer application platform that needs no central server once a user installs a local peer. Shared application state and update rules are encoded in public WebAssembly contracts. Private state and cryptographic keys stay in local delegates on the user's device.
The current application set includes River, a group-chat tool, and Atlas, a discovery and search layer. A July FUTO talk by Freenet founder Ian Clarke describes a wider set of applications and prototypes built around the same model.
That architecture creates an important boundary in the onboarding path. Freenet's browser demo runs on the project's server. It is a centralized trial. Installing a peer is the step that removes that server from the middle.
A bounded test of the installed path reached the network successfully but could not load Atlas or River. The error matched open issue #5001 in the Freenet core repository: a GET request succeeds on the wire, followed by a failed local-store lookup. The issue author reported the same behavior across multiple contracts and two earlier versions. A project collaborator confirmed that the current code contains the path producing that exact error, while questioning one detail in the issue's logging diagnosis.
The result gives us a failure report, not a verdict on the whole network. The useful evidence is narrower. Healthy peer connectivity can coexist with a broken application boundary.
Why it matters
A central server gives power to the organization that runs it. That organization can change access, rank content, collect data, shut off an account, or disappear. Freenet tries to move some of that power into shared contracts and user-run peers.
But power still exists. It changes address.
Contract authors shape the rules for shared state. Client distributors control the software and update path. Key holders govern access to private rooms. Atlas crawler and labeler maintainers influence what people discover. Defaults matter because most people will not inspect WebAssembly or assemble a trust stack from scratch.
And when something breaks, users need a repair path. Who explains why a contract failed? Who helps recover local state? Who handles abuse, impersonation, malware, or a disputed default? A network with no company in the middle can still require humans who accept responsibility for those moments.
That same tension applies to transparency. Public code can be inspected. Most people cannot read the code well enough to judge whether it is safe. Asking a language model to explain a contract may help with orientation, but that answer is not a security audit. It can also produce false confidence with impressive speed.
Freenet's design makes this accountability shift visible. Atlas is meant to let users choose crawlers, labelers, and recommendation logic. That could open a route away from one platform's opaque feed. It also creates a new question: which defaults become popular enough to function like institutions, and who checks them?
River carries a similar trade-off. The project says private-room content is encrypted, while some metadata remains visible and key rotation is weaker than Signal's double ratchet. Freenet does not claim anonymity. Those limits belong beside the promise of user control.
What this does not prove
This remains early-stage software. The hosted Atlas and River demos worked during the same evaluation. The local failure may be repaired in a later release, and the available evidence does not show that every peer or operating environment fails.
The test also says little about mass adoption, performance at scale, resistance to determined attack, or long-term governance. No completed independent security audit was verified for this review. Project language such as “can't be taken down” remains a project claim until broader evidence supports it.
This failure should not be generalized to every decentralized system. Different networks make different choices about storage, consensus, software distribution, moderation, recovery, and identity.
This card offers public-interest technical orientation. Security, privacy, legal, operational, and procurement decisions require qualified review.
What to watch
Start with issue #5001. A later release should be tested on a fresh peer to see whether Atlas and River survive the full trip from network retrieval to local application delivery.
And then watch the human layer. Look for clear recovery documentation, abuse and dispute processes, independent security review, contract-reputation signals, and an explanation of how client updates are governed. Atlas will also need evidence that user-selected discovery works without quietly hardening into another set of defaults people cannot meaningfully inspect.
The server may leave the center. The complaint desk still needs an address.