Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.by soundworlds
- 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.
by mhitza - > What are the current limitation of this system? Slow bootstrapping, high latency, large disk usage?
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].
by sanity - 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!
by adamfisk - 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.
by sanity - 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.by adamfisk
- 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 aspectby nurumaik
- 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.
by sanity - 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:by EGreg
- 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?
by gustavus - 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/
by sanity - 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?
by aleqs - I'm also curious about this. I don't understand how deletion and modification can be made commutative operations in a way that makes senseby dtj1123
- 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.
by dave1010uk - > 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.
by sanity - 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.
by alun - 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).
by nine_k - 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.
by sanity - 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.)
by Groxx - 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.
by sanity - 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.
by mweidner - > 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.
by sanity - 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?
by miki123211 - 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.
by sanity - 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:
by qcl820DV34 - 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.
- anonymity was the main point of freenet... So weirdby seany
- Thanks so much for the heads up. I loved Freenet as a concept back in the day and used to devote a significant chunk of my tiny hard drive to trying to help out. I looked it up a few months ago and honestly thought I was experiencing some kind of memory dailure when I saw the new project under that name. Was wondering what the project I was so excited for had _actually_ been called all those years back. Now I know what happened, and where to find the project I actually liked.
- Isn’t anonymity the one and only point of freenet.by dyauspitr
- 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.by outside2344