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

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:

https://www.hyphanet.org/

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.

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?

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? That is:

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

[1] https://automerge.org/

[2] https://arxiv.org/abs/1805.04263

Neat. I've been wanting to see WASM-defined network behavior like this for a while (yay arbitrary consistency algorithms!), I'll have to explore it in more detail :)

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

Very interesting. Beyond ideological motivation, I’m curious what the long-term incentive is for someone to run a peer.

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.

Very cool project!

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

In my early days of technology tinkering when I was young I was always interested in security, and one day I stumbled upon freenet, and my world changed.

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?

Big fan of this project. Three years ago, I interviewed Ian Clarke about his upcoming Freenet rewrite. He's the original "OG" of decentralized content networks. We go into detail regarding its architecture on the podcast:

https://www.youtube.com/watch?v=JWrRqUkJpMQ

I think better approach for "ghost keys" would be requiring X amount of crypto to be sent to 0x0 (burning). Current implementation (requiring donation to freenet) basically gives freenet foundation infinite reputation (including any other potential project that would accept ghost keys as identity), kinda breaking the decentralization aspect

What are the current limitation of this system? Slow bootstrapping, high latency, large disk usage?

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.

Exciting to see Freenet innovating so much, Ian! I haven't really dug in too deep but love that it's in Rust. What's it look like over the wire? How conspicuous is it in the face of, say government censors who can see and control every packet?

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!

Decentralized web has been a pipe dream forever but group chat actually working in practice is more convincing than anything they could have shown. Real time sync was always the hard part.

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?

Looks very interesting! I stumbled across your webpage a few months ago while looking into the state of peer-to-peer. Glad to see p2p projects are still active.

I wrote a short University essay on Freenet in 1998 I think it was... I may still have the document somewhere. Good stuff, very pioneer!

It's refreshing to see people doing something conceptually interesting outside of the LLM domain.

How do you compare this to the effort in https://braid.org, which is also a decentralized web, which adds subscriptions that can operate in a tree (or DAG) of reactive state, each with its own validator and supporting different media types, and merging with merge-types?

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.

Very interesting. I have been working on something quite some time, where something like this would play a very crucial role, but i never got around to really thinking about how to implement everything. And as I have still a lot of work to do on my project, that would utilize something like freenet, i am very eager to dive into your work. Just wanted to write this as some form as appreciation for your work.

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.

This is awesome. I rotated some ideas like this in my head a while ago but never had the motivation to put it together. Happy to see more types of protocols like this.

I definitely think we should be exploring decentralized approaches to services we use.

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

There's also https://internetcomputer.org/

ELI5, how is this different than the internet?

I wrote a web browser for Freenet called Snarfzilla. I guess it may have been the first web browser for "the dark web". [1]

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

[1] https://sourceforge.net/projects/snarfzilla/

Looks very intersting, congratulations for the launch and wishing you good Luck!

Is there any way to run this in the browser rather than downloading an app?

related wiki links: https://en.wikipedia.org/wiki/I2P https://en.wikipedia.org/wiki/Tahoe-LAFS

Can you tell me about the old Freenet? I've read up on Wikipedia and it seems to be very much in the line with the 90s/2000s p2p file sharing software. Except that you can store stuff on other people's computers and it's encrypted?

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

Serious question: how do you prevent/remove nefarious things like CSAM?

Can this be used to sync the data of an app from mobile to desktop without a server ? And vice-versa.

See also:

https://news.ycombinator.com/item?id=40469711 - Ian Clarke explains the next generation of Freenet [video] (2023)

Is this similar to how Napster worked?

It seems like downvoting brigading is happening quite a bit on this post on a lot of replies.

Interesting

[flagged]

[dead]

[dead]

[dead]

We had too much Gnutella. I am in search for a locus to us. Now. SCNR