The new Freenet has been up and running since December along with some early applications like River[1], our decentralized group chat and Delta - a decentralized CMS. Users have already started to build their own apps on Freenet including games, and we have some interesting apps in development like Atlas, a search/recommendation engine.
Architecturally, this new Freenet is a global, decentralized key-value store where keys are webassembly contracts which define what values (aka "state") are valid for that key, how or when the values can be mutated, and how the state can be efficiently synchronized between peers.
We've developed a unique (AFAIK) solution to the consistency problem, every contract must define a "merge" operation for the contract's associated state. This operation must be commutative, meaning that you can merge multiple states in any order and you'll get the same end result.
This approach allows state updates to spread through the network like a virus[2], which typically achieves consistent global state in a few seconds or less.
Like the world wide web, Freenet applications can be downloaded from the network itself and run in a web browser - similar to single-page apps on the normal web. However, rather than connecting back to an API running in a datacenter, the webapp connects locally to the Freenet peer and interacts with Freenet contracts and delegates over a local websocket connection.
If you'd like to try Freenet we have convenient installers for the major desktop OSs but not yet mobile, and you can be chatting with other users on River within seconds[3]. Happy to answer any questions, you're also welcome to read our FAQ[4], or watch a talk I gave back in March[5].
[1] https://github.com/freenet/river
[2] https://freenet.org/about/news/summary-delta-sync/
in favor of a rewrite from different developers, without asking anyone on the original team.
It was an ivory tower decision which was announced on the mailing list without prior discussion.
The old team did not agree, yet it was forced through by a decision of the "board".
The "board" was a group of people which had not been active on the project for over a decade.
https://www.mail-archive.com/devl@freenetproject.org/msg5526...
The funding of the existing, original "Freenet" was repurposed for the new one of course.
The new "Freenet" does not have anonymity as a design goal anymore,
while the old one continues to exist and is maintained under its new name "Hyphanet" at:
Perhaps.
Though reusing the name for an entirely different project with a different codebase is disingenuous to say the least.
That won't do his reputation any good, especially in a field where reputation matters.
This is a false narrative, from the Freenet FAQ[1]:
Why was Freenet rearchitected and rebranded?
In 2019, Ian began developing a successor to the original Freenet, internally named “Locutus.” This redesign was a ground-up reimagining, incorporating lessons learned from the original Freenet and addressing modern challenges. The original Freenet, although groundbreaking, was built for an earlier era.
This isn’t the first time Freenet has undergone significant changes. Around 2005, we transitioned from version 0.5 to 0.7, which was a complete rewrite introducing “friend-to-friend” networking.
In March 2023, the original Freenet (developed from 2005 onwards) was spun off into an independent project called “Hyphanet” under its existing maintainers. Concurrently, “Locutus” was rebranded as “Freenet,” also known as “Freenet 2023,” to signal this new direction and focus. The rearchitected Freenet is faster, more flexible, and better equipped to offer a robust, decentralized alternative to the increasingly centralized web.
To ease the transition the old freenetproject.org domain was redirected to hyphanet’s website, while the recently acquired freenet.org domain was used for the new architecture.
It is important to note that the maintainers of the original Freenet did not agree with the decision to rearchitect and rebrand. However, as the architect of the Freenet Project, and after over a year of debate, Ian felt this was the necessary path forward to ensure the project’s continued relevance and success in a world far different than when he designed the previous architecture.
> The new "Freenet" does not have anonymity as a design goal anymore,
Because the new Freenet will have a menu of anonymity options rather than committing to a one-size-fits-all approach, while also addressing the issue of illegal content[2].
[1] https://freenet.org/about/faq/#why-was-freenet-rearchitected...
[2] https://freenet.org/about/faq/#how-does-freenet-handle-harmf...
There was no "year of debate".
You came to the mailing list and announced it for the first time as a finalized decision already,
without any prior debate with the original team.
The "board" you cited as the body which allegedly discussed it did neither join the mailing list discussion,
nor were you willing to hand out their contact info.
It's all public for anyone to see on the mailing list archive:
https://www.mail-archive.com/devl@freenetproject.org/msg5526...
- https://www.mail-archive.com/devl@freenetproject.org/msg5534...
- https://www.mail-archive.com/devl@freenetproject.org/msg5534...
Gee, I can't imagine how that mailing list could ever be toxic.
And that repurposing the name would cause lots of damage.
Incorrect, I raised the issue with the lead maintainer over a year prior to that announcement.
> You came to the mailing list and declared it as a finalized decision.
As the project's architect I'm entitled to make decisions about the project's future direction.
> It's all public for anyone to see on the mailing list archive:
> https://www.mail-archive.com/devl@freenetproject.org/msg5526...
I stand by every word I said in that mailing list thread.
they were saying they debated with themselves,
before making the decision.
I'm sorry, but nothing following that even comes close to proving that it's a false narrative. Quite the opposite actually.
> To ease the transition the old freenetproject.org domain was redirected to hyphanet’s website, while the recently acquired freenet.org domain was used for the new architecture.
So in that aspect it seems more user friendly than a hard fork.
Well, that name pretty much dooms the project to a slow death in obscurity.
He has forked the project (to something that does not share the same goals so "fork" is arguable here), took the name, the cash and the goodwill.
We went from "we have enough donations/donators" to "how do we pay for the upcoming AWS bill?".
As someone who has been fairly active on the "old freenet", I have never cared about money nor funding... but I cannot help but notice that some has likely been misappropriated. Things like the SUMA award (https://web.archive.org/web/20150320201527/http://suma-award...) were awarded specifically for "protection against surveillance and censorship" that the "new freenet" does not even aim to provide.
"The board" of the non-profit seems to have been culled just before the decision. I don't know why, I wasn't on it. Maybe @agl can shime in (he was).
All I know is that this could have been handled better. It's what I wrote back then on https://www.mail-archive.com/devl@freenetproject.org/msg5527...
How do the goals differ, specifically?
> but I cannot help but notice that some has likely been misappropriated
You had no visibility into the project's finances, yet you're publicly implying financial impropriety without evidence.
I've raised substantially more funding for the new Freenet in the past 5 years than was raised during the entire prior 20-year history of the project.
> were awarded specifically for "protection against surveillance and censorship" that the "new freenet" does not even aim to provide.
In what way does a decentralized network with optional anonymity not protect against surveillance and censorship?
> "The board" of the non-profit seems to have been culled just before the decision. I don't know why, I wasn't on it. Maybe @agl can shime in (he was).
You also acknowledge here that you don't know what happened. Those board members' departures were at their request because they were no longer actively involved in the project.
> All I know is that this could have been handled better.
I'm sure you're right about that. But my experience at the time was that the disagreement was fundamentally about the outcome, not the process.
This isn't even the first time we did a ground-up redesign/rewrite of the Freenet codebase, we did this in 2008 with the 0.7 release.
And even without agreeing on whether people should be anonymous on the Internet,
it could be agreed that replacing a software which guards against a certain threat model (repressions) with one which does not,
without changing the name, is not exactly a wise decision.
We will also have a decentralized reputation system that will protect people from being exposed to unsavory or illegal content, a common criticism of the old Freenet architecture.
I’m not a fan of “think of the children“ arguments but the Internet cannot actually be a complete free for all and “freedom of speech” is not some magic shield that overrides all other ethical considerations. CSAM is not a particularly high bar and frankly if you want people to throw in with you then you can’t brush it off so lightly.
And yet, it's materially all anonymity is actually for in practice, within a margin of error. Tor - mostly crime & CSAM. Crypto - mostly crime. 4chan - mostly degeneracy, some crime. Faceless Corporations - used for crime, and things that should be crimes, but hide under other names.
Imagine an application where an authorized group of users can create and vote in polls, using cryptographic signatures and public/private keys for user verification.
What prevents me from connecting and saying that "everybody's state is wrong, that poll in 2024 which didn't reach quorum actually did, because I voted in it, here's my vote." How can the state merger know that the existing state has been valid for two years, and that the vote shouldn't be retroactively applied?
Blockchains solve this by having state get more authoritative as blocks age. To undo the `poll_didnt_reach_quorum` state transition from 2024, one would have to rewind all blocks that have been created since, and PoW / PoS ensures that this is incredibly costly to do.
On a related note, how does your design prevent sybil attacks, where one participant floods the network with many large contracts and large state updates?
> It feels like the state merging approach just pushes the hard problems onto the user, without giving them the tools to solve those problems properly.
We've created many of these tools, and have used them to implement practical applications like group chat, a CMS, and a social network, and we and others will build many more tools over time. Designing applications for Freenet can require some creative problem solving, but each problem only needs to be solved once.
> What prevents me from connecting and saying that "everybody's state is wrong, that poll in 2024 which didn't reach quorum actually did, because I voted in it, here's my vote." How can the state merger know that the existing state has been valid for two years, and that the vote shouldn't be retroactively applied?
You could solve this similarly to Bitcoin by having a mechanism that "locks" poll results at a particular point in time to prevent subsequent additions, analogous to how mining repeatedly locks in the blockchain.
> On a related note, how does your design prevent sybil attacks, where one participant floods the network with many large contracts and large state updates?
Peers in the network track cost/benefit of each connected peer, so if a peer starts to consume a lot more resources than it provides then its neighbors will disconnect, a kind of immune response.
I'm sure that once the network is big enough to attract large-scale attacks we'll need to adapt our approach, but I think we have a solid starting point.
- The synced value is a history of client updates, sorted in some eventually consistent order (e.g. by hybrid logical clocks). Merging takes the union of the update sets.
- The user-visible value is the result of processing these updates in order, using arbitrary contract code.
This is overkill for simple last-writer-wins values, but it lets you support fairly general data types & arbitrary update functions, including ones that preserve application-specific invariants.
The Automerge CRDT library works like this already [1][2], but it only allows specific updates to JSON data. Sharing code via your contracts solves the hard part of generalizing that to arbitrary data & updates.
Yes, in fact you can implement this within the current framework, for example with our group chat River, each room state maintains a list of the N most recent messages sorted by (approximate) timestamp.
The idea is that you can adapt the merge logic to the needs of the specific application, and I think a time ordered event log will be a common pattern.
One weakness is that we trust the message author to provide an accurate message timestamp, however bad behavior such as manipulating timestamps can be addressed by banning the user from the room.
(the main thing I've been wanting to try: rather than graphql, send a WASM blob along with your request to a server, and just run it to filter fields in the response / pipeline requests / define "fail if any err / pair errors with requests" for concurrent requests. arguably you could even have it control callee-internal retries.)
For example, if Freenet were to reach scale, it could eventually need some kind of economic primitive around it. Something similar to how Filecoin handles decentralized storage, but for app state. One way to do this could be paying peers to keep app state available, serve it reliably, etc. and prove they are doing so.
So there are a lot of possibilities but for now users are motivated by a desire to see the network succeed, and that seems to be a sufficient motivator at our current scale.
Freenet's approach works well for things like group chat, where temporary inconsistency is mostly just an irritation, but for a cryptocurrency it is fatal.
I'm not saying you couldn't build a cryptocurrency on Freenet, but you'd still need a solution to that problem.
Currently it appears centralized, but in principle it'd be pretty easy to shift it to a web of trust instead, and hosts can choose what they allow and how much they value it.
(zero-knowledge proofs seem probably rather important to adopt tho, as right now it'll tie you to a stable pseudonym)
- You participate in a secret cabal, and don't want participants' identities be visible to each other.
- You're a journalist, and want to give your informants in sensitive matters, or from oppressed countries, a way to securely interact with you, so that you won't be technically capable of reporting their identities.
- You're selling illegal goods or services.
I'd say that in the first two cases I would consider running a separate copy of the network, because it apparently involves one supernode, and I might want to control the supernode (or maybe not).
> We've developed a unique (AFAIK) solution to the consistency problem, every contract must define a "merge" operation for the contract's associated state. This operation must be commutative, meaning that you can merge multiple states in any order and you'll get the same end result.
Where can I learn more about this? How is this different from CRDTs/CmRDTs?
Thank you!
> Where can I learn more about this?
If you don't mind watching a video I gave this talk back in March that should be fairly comprehensive: https://youtu.be/3SxNBz1VTE0?si=R4ifrsfEUJfvjDPx
If you would prefer an article I recommend: https://freenet.org/about/news/summary-delta-sync/
> How is this different from CRDTs/CmRDTs?
It's very closely related, you can view Freenet contract state as a CmRDT, where the details of the merge operation are specified in the webassembly contract.
They describe it as a commutative monoid, which means it has associativity and commutativity. CvRDTs also need idempotence, so they can handle duplicate data. Either they are idempotent too (which would make it semilattice-like), or the network protocol handles the deduplication outside of the data itself.
Letting the payload/application define the merge operation is clever. I assume it would mean contracts could opt in to idempotency if it doesn't already exist.
The other bit Freenet has added is doing all this with DHT routing and subscriptions, rather than a more basic peer mesh. This is very different to a blockchain and means it probably isn't suited for anything transactional.
> CvRDTs also need idempotence, so they can handle duplicate data. Either they are idempotent too (which would make it semilattice-like), or the network protocol handles the deduplication outside of the data itself.
Freenet's summary/delta synchronization mechanism implicitly disregards duplicate updates. The idea is that a peer A creates a "summary" of a contract's state which is sent to the other peer B which then creates a "delta", which contains anything in B's state that isn't in A's state. The delta is then sent from B to A bringing A's state up-to-date. Thus the contract defines a custom synchronization mechanism for its state which can be very efficient.
These summaries and deltas are just arbitrary bytes as far as the framework is concerned, their meaning is entirely up to the contract.
> The other bit Freenet has added is doing all this with DHT routing and subscriptions, rather than a more basic peer mesh. This is very different to a blockchain and means it probably isn't suited for anything transactional.
That's correct, Freenet doesn't guarantee a global consensus although in practice contract states will converge within a few seconds. This is good enough for applications like group chat and social networks but for a cryptocurrency you still need to solve the double-spend and global ordering problems.
but "makes sense" and ways to optimize that can change massively with context. e.g. for a chat app, as soon as you see "deleted message X", you can reasonably drop X and all past and future changes to X because they won't be shown by anyone (don't even need to sync them). if you do that with "deleted chars 87..93" in a text editor, past-edits that you receive in the future might affect the behavior (it might add chars before those, changing what that range means), so you can't simply forget those chars (e.g. an easy option is to replay all events that occur after an event syncs, but that means retaining all events forever). the semantics you choose and what you do with the data affect your outcomes a lot.
tbh this is one of the reasons I like the idea of a WASM-defined algorithm. no one algorithm will be "best" for all data, and the storage/computation/transmission savings can be extreme.
and when played out of order, it's guaranteed to resolve to foobaz eventually or immediately, depending on when messages are received
when you encounter the scenario of a fork, there's usually a fork resolution rule, e.g. D: { "prev_hash": "<hash of B>", "content": "foobazbar" }
to resolve C vs D, sort lexicographically, choose direction of sort order and pick first
When you have non-continuous data due to messages dropping, e.g. you have B and perhaps an E that builds on C, you can either use the same lexicographic rule, or make the hash basis a combination of timestamp and hash, so you get temporality and lineage.
As for deletes, you have either the single set approach of simply making the message content empty and that _is_ the delete, or you have the 2-phase sets, where there exists an add set and a delete set.
Quite a few ways to approach it, but commutativity can be readily preserved.
So there is no one approach to this, rather you design the approach based on the application, and since contracts are just webassembly they are extremely flexible.
It was amazing and led me to get far more acquainted with the cyberpunk scene. It was this alternative separate internet from what the rest of the world saw with all of the good and bad that brought.
I've been meaning to set it up again and get back into it. I will say for everyone pining for the Internet of yesteryear freenet is it. Go and explore it it is everything the 90's Internet was like, super slow, crazy unhinged nerds all over the place random collections of links, crazy.
Thanks for all you've done Ian
Edit: Btw what is the best way to support the project and get involved?
If you're in a position to support the project financially you're more than welcome to donate[1], we're a 501c3 non-profit and all funds go to support development.
If you're a developer and are interested in building on Freenet I suggest starting with https://freenet.org/build/manual/tutorial/, you can also join our Matrix room[2], or install Freenet[3] and chat with us on River[3], our decentralized group chat.
[1] https://freenet.org/donate/
Is there a solution, or ideas, for DNS equivalents? I know the I2P approach (and remember that GNUNet had some unique approach as well), which can be workable in practice with "trusted registrars" as jump hosts. Name resolution feel even more important to solve in decentralized web.
How can anonymity be built on top of this system?
For ghost keys issuance, like with other privacy products, I'd really like to be able to buy redeem coupons in real life, not through stripe and all other online payment providers.
I'd say not working on mobile is probably the main one right now. Peers bootstrap into the network in seconds typically, and contract updates typically arrive at subscribed peers in under 2 seconds which was the design goal. The Freenet binary is just 10MB, and disk usage is fairly minimal as even the largest contracts are < a few MB.
> Is there a solution, or ideas, for DNS equivalents? I know the I2P approach (and remember that GNUNet had some unique approach as well), which can be workable in practice with "trusted registrars" as jump hosts. Name resolution feel even more important to solve in decentralized web.
Contracts in Freenet are identified by a hash of the contract webassembly + contract parameters - so the contract's identity is tied to its function. This is effectively a generalization of Freenet's "Signed-Subspace Keys" - which were also adopted by GNUnet.
> How can anonymity be built on top of this system?
Most likely through a mixnet or onion routing built on Freenet's contracts and delegates. If you don't mind listening to videos this was discussed in depth on a recent Freenet podcast[1].
Been chatting a lot with the HolePunch/Tether folks, and their work is impressive, particularly the use of the DHT for all signaling, Tailscale-inspired (aka Birthday Paradox) NAT hole-punching, an entire JavaScript runtime, etc. I'm curious about some of those details in Freenet. In particular, does it do fully decentralized hole punching?
Either way, congrats!
> What's it look like over the wire?
Encrypted UDP, but likely identifiable based on timing etc - we're not trying to hide it right now - the focus is more on decentralization.
> In particular, does it do fully decentralized hole punching?
Depends on what you mean by "fully". When peers first start up they need to connect to a "gateway", a freenet peer that can receive unexpected inbound UDP. But gateways are only required to introduce peers to the network, after the initial introduction they form new connections through the network.
Right now we run these introductory gateways but will decentralize it over time.
Curious about mobile though, you mentioned iOS is the main blocker because of wasm restrictions. Is the plan to run the peer on desktop and have mobile just connect to it, or are you expecting people to run a full peer on Android?
Now, whether giving up anonymity was worth it is a separate issue.
Citation needed? IIRC, the general advice for running a Tor relay is "don't, unless you want an endless supply of abuse complaints". So you'd require a jurisdiction that ignores abuse complaints.
Freenet seems to not interoperate with the existing WWW as much, while at the same time giving more specification on a specific routing and WASM validator. The existing WWW and Braid leave those decisions up to each particular host/authority to decide.
I wonder though, what is your idea of a future, where freenet plays an important role in most peoples lives?
Great work it seems, so far. I will yet have to really look through it all. Congratulations on this.
> I wonder though, what is your idea of a future, where freenet plays an important role in most peoples lives?
While I realize this is wildly ambitious, my goal is that Freenet could ultimately replace the world wide web and the client-server architecture more generally which I view as inherently concentrating power in the hands of a few (which it has done).
I also would like to see an emphasis on local-first approaches.
This experiment, in the spirit of UNIX, composes git and text files to form a social network:
https://github.com/dharmatech/9social
Video demo: https://youtu.be/q6qVnlCjcAI
It is hard to grok what Contracts, etc. etc. allow you to do in the abstract so working through how it allows us to build a decentralized GitHub might be a good anchor in a tangible use case.
The freenet-git work is quite recent but we do feature River, our group chat app, fairly prominently on our installation page[1] so that people can quickly try out something useful. River is by-far the most fully developed app so far.
OK, time for inception... 9social on freenet-git
¯ \ _ ( ツ ) _ / ¯
Think of it as going back to the Internet's decentralized roots.
I integrated "Fair Tunes", which tried to pay musicians for mp3 files, long before any label was selling mp3's.
(Edit: I just remembered Freshmeat automatically rejecting Snarfzilla because they were so sick of projects ending in *zilla. The owner thought it was cool and added it after I emailed. No idea why I used 'snarf'. I've never said it out loud.)
I am thinking about making a public proxy available so people can try the network itself without installing it, but we've made installation as quick and painless as possible.
Which then led to people storing Bad Stuff, and this is somehow addressed in the new version? (I also read some stuff about friends and trust in the previous one, but haven't looked into properly.)
I think understanding the old one and the issues it ran into would be helpful for understanding the context, and the motivations for the changes.
Or to put it very bluntly: what is this, why should I care, and why not just use the old one?
Thanks
If you don't mind I'll quote the FAQ[1]:
The previous and current versions of Freenet have several key differences:
Functionality: The previous version was analogous to a decentralized hard drive, while the current version is analogous to a full decentralized computer.
Real-time Interaction: The current version allows users to subscribe to data and be notified immediately if it changes. This is essential for systems like instant messaging or group chat.
Programming Language: Unlike the previous version, which was developed in Java, the current Freenet is implemented in Rust. This allows for better efficiency and integration into a wide variety of platforms (Windows, Mac, Android, MacOS, etc).
Transparency: The current version is a drop-in replacement for the world wide web and is just as easy to use.
Anonymity: While the previous version was designed with a focus on anonymity, the current version does not offer built-in anonymity but allows for a choice of anonymizing systems to be layered on top.
> Which then led to people storing Bad Stuff, and this is somehow addressed in the new version? (I also read some stuff about friends and trust in the previous one, but haven't looked into properly.)
The new version doesn't claim to provide anonymity as part of the platform itself although anonymity systems can be built on top of it. I'd also refer you to this FAQ [2].
[1] https://freenet.org/about/faq/#how-do-the-previous-and-curre...
[2] https://freenet.org/about/faq/#how-does-freenet-handle-harmf...
Ed: I guess you'd need a way to run wasm in wasm, and a way to author wasm contracts - and there's not yet a wasm-hosted rust compiler?
Ed2: I'm not up to date on the state of self-hosted wasm compiler/languages... But I did come across:
https://github.com/remko/waforth
I guess it's time to dig out the thesis[t] again and look at movable code and p2p classifications again ...
[t] https://ics.uci.edu/~fielding/pubs/dissertation/net_arch_sty...
https://news.ycombinator.com/item?id=40469711 - Ian Clarke explains the next generation of Freenet [video] (2023)
Also Freenet is much more general, you could think of Napster like a shared hard drive, whereas Freenet is like a shared computer capable of running decentralized applications like group chat, social networks, search engines, etc.
