Video summary

Freenet - Services Without Servers

Main summary

Key takeaways

News and Commentary

Overview: “The internet’s honeymoon is over”

The speaker argues that the “internet’s honeymoon is over,” and that even Western democracies are increasingly applying legal pressure, fines, and enforcement to control online speech and influence platforms. This creates a “chilling effect” for operators of social and chat services.

They cite examples such as:

  • Arrests for offensive posts on X (UK)
  • Charges against Telegram’s founder (France)
  • An EU fine of X for “disinformation”
  • New US/California-style moves toward identity/age verification

The speaker also warns that governments can manipulate what users see not only through direct censorship, but also via more subtle mechanisms—especially by altering recommendation and re-ranking algorithms.

Freenet as a partial solution

The speaker presents Freenet as a partial solution aimed at reducing central points of control. Freenet is described as a:

  • Decentralized
  • Serverless-style network
  • Built on peer-to-peer participation rather than centrally managed data centers

Why it matters

Because there is no single operator to pressure, it’s harder for governments or corporations to coerce one party into:

  • Removing content
  • Manipulating behavior across the network

The speaker emphasizes that Freenet is self-organizing:

  • No single peer is essential
  • Disabling nodes should not stop the network

How Freenet is framed relative to the current web

Traditional web

  • Browsers communicate with centralized servers over HTTPS/websockets.

Freenet model

  • A browser connects to a local Freenet peer
  • That peer participates in the broader peer-to-peer Freenet network
  • Data is distributed across peers

“Drop-in” replacement positioning

Freenet is positioned as a browser-based, web-like replacement, while also supporting native/CLI tools.

What’s built so far (status update)

Since an earlier February talk, the project has been developing several apps:

  • River: a group chat app (actively usable)

    • Supports private rooms
    • Supports private messages
    • Uses encryption with weekly key rotation
      • Rotation can also occur upon bans
    • The speaker clarifies:
      • What is protected (e.g., message content, some metadata)
      • What may leak due to design choices (e.g., room existence, approximate timing/message size, membership count)

  • Delta: a decentralized “Squarespace”-like builder

    • Creates Markdown-based pages/blogs
    • Includes a CLI for automation

  • Freenet Git / conduit for git: publishing and using Git repos on Freenet

    • Intended as a stepping stone toward decentralized software forges

  • Atlas: decentralized discovery/search

    • Intended to counter government/corporate manipulation of recommendation systems (e.g., YouTube-style issues)
    • Uses a default crawler
    • Can use LLMs for neutral descriptions
    • Allows users to choose trusted crawlers/labelers

  • Additional/early concepts:

    • Mail (pre-alpha email-like system)
    • Raven (social feed / decentralized Facebook-or-X prototype)
    • Harvest (decentralized marketplace like Etsy)

Onboarding and privacy approach

Getting started

  • Desktop installers for easy setup
  • A browser-based “try” experience: freenet.org/try
    • Lets users use River before installing software

Moving to your own node

After trying, users can quickly “move to my peer” by transferring private data from the centralized trial service to their own Freenet node.

Trial-server encryption

  • Private data on the trial server is encrypted at rest
  • The speaker claims the service cannot decrypt data when the user isn’t actively using it
  • Reason: a private key is created and held in the user’s browser

Transparency and verifiability

A major theme is transparency:

  • Freenet’s shared data and the “business logic” governing it are in public contracts
  • These contracts can be read/audited by anyone

The speaker contrasts this with centralized services:

  • Centralized recommendation algorithms are often opaque
  • Users can’t verify what code is running or whether it has been altered under pressure

They claim Freenet users can:

  • Decompile contract code to WebAssembly
  • Have others (including an LLM) vet the logic

Security model components

  • Contracts

    • Define shared network state and update rules

  • Delegates

    • Handle private data via WebAssembly code
    • Instead of exposing private keys, the delegate performs cryptographic operations after authorization checks
    • Example: trusting calls from the correct UI

Performance and learning

The speaker describes Freenet’s peer routing/contract discovery as a machine-learning-based process using an open-source supervised learning approach:

  • Renegade: described as a learned metric k-nearest neighbors method
  • It learns which neighbor can find contracts fastest
  • It adapts to changing network conditions

Q&A highlights

  • River before Mail

    • Group chat can be useful even with small numbers of users
    • Email requires wider adoption to be effective

  • Contract access control

    • Contracts can encode authorization logic
    • Private-room behavior is achieved primarily through encryption, not by hiding contract existence

  • Developer community

    • One full-time lead (Ian)
    • Two part-time developers in Spain
    • Volunteers
    • The speaker reports growing interest
    • Mentions AI tooling (e.g., “Claude Code”) can help people build Freenet apps without mastering Rust

  • Marketplace payments (Harvest)

    • The system is designed to be payment-mechanism agnostic
    • The speaker expects payments would mostly use cryptocurrency via third-party integrations
      • e.g., vendors provide a Bitcoin address

Presenters / Contributors

  • Ian (speaker; also referenced in Q&A as the project lead)
  • Jack (audience member in Q&A)
  • Fudo (host/organizer of the talk; referenced as providing hosting/support)

Original video