Yeah, I'm not a fan. Feels like this project is trying to get popular off of Freenet's name recognition rather than its own merits.

I wasn't very happy as a user with an interest in tech/internet history to find my old bookmarks and notes had been hijacked by the new renamed project. The Original Freenet (Hyphanet) was quite interesting. The new one, less so, especially with the name hijacking.

> Notably this project was conceived by a backroom decision to dump the original Freenet development team's work,

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...

So he forked the project and went his own way. I am not sure I see the issue here. This is how we do open source on the internet. You don't have to join him, but he also has the right to go his own way too.

>while the old one continues to exist and is maintained under its new name "Hyphanet"

Well, that name pretty much dooms the project to a slow death in obscurity.

I'm very glad to hear that—the anonymity of the original Freenet has led to it being a very unsavory place that was more well known for CSAM then anything positive or useful. As an outsider, it sounds like this new direction is the right choice for Freenet to try and attract new users and fulfill the team's original goals.

Appreciate the feedback.

> 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.

> For values that don't have a natural merge function (or where you don't want to bother writing one), would it make sense to sync update logs instead?

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.

Thank you, that's actually an idea I considered a while ago - embed some wasm in a GET request (which retrieves complete contract state from the network) that could pre-process the state before returning it to the requestor.

The issue was that Freenet requires that intermediate peers can cache the contract state as they're passing it back to the requestor so in the end I decided against it, but might revisit in the future.

Why would you want to exchange private messages with anonymous counterparties?

- 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).

Our intention is that Freenet will only consume surplus resources, but we plan to build a reputation system that could have a notion of "karma" that is earned by providing resources to the network. This karma could be used to gate access to resources, for example like a VIP chat room on River.

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.

> Very cool project!

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.

It looks a lot like a CvRDT (i.e. a state-based CRDT).

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.

I'm also curious about this. I don't understand how deletion and modification can be made commutative operations in a way that makes sense

Ghost keys will ultimately be just one of a menu of options for bootstrapping reputation in a decentralized reputation system. They have the advantage of simplicity, anonymity, and helping to fund the project, but as you correctly point out - they are centralized.

A cryptocurrency-based solution like you suggest will undoubtedly be one of a menu of reputation bootstrapping options that will develop over time.

Thank Adam, nice you see you!

> 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.

Without knowing too much about the drama discussed here, I think the bottom line is that the "old" Freenet was a bit on life support as far as I could tell and absolutely needed this kind of innovation from its founder.

On Hyphanet (the original Freenet) there’s been working group chat via a Hyphanet-backed IRC server for over a decade (the server is named FLIP, the first working version was released in 2013, developed purely on Freenet/Hyphanet).

The hard part imo was not being exposed to, or unknowingly redistributing illegal content. They claim this new freenet solves this but the details on how weren't super clear.

Thank you!

> 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).

Interesting, we've also experimented with hosting git repos on Freenet, see: https://github.com/freenet/freenet-git

Unfortunately, this is an effectively unrelated project.

Imagine an internet that is fundamentally decentralized, where your online presence isn't at the mercy of a company like Google, Amazon, or Microsoft.

Think of it as going back to the Internet's decentralized roots.

Thank you!

Not currently, but installation is very quick - the binary itself is just 10MB.

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.

> Or to put it very bluntly: what is this, why should I care, and why not just use the old one?

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...

In principle but we don't yet support mobile except experimentally, in part due to mobile OS restrictions (eg. iOS apps can't embed webassembly).

Yes in the sense that users pool resources for the network, but no in the sense that Napster relied on a centralized database of content - whereas Freenet is entirely decentralized.

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.

I thought Gnutella was a bit more like Freenet than Napster, iirc only the bootstrap was centralized.

Thank you!

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/

[2] https://matrix.to/#/#freenet-locutus:matrix.org

[3] https://freenet.org/quickstart/