Live data from Hacker News

Show HN: Freenet, a peer-to-peer platform for decentralized apps

freenet.org

1–10 of 302 posts

Show HN: Freenet, a peer-to-peer platform for decentralized apps

#1
For the past 5 years or so I've been working on a ground-up redesign of Freenet, my peer-to-peer project from the early 2000s (now renamed Hyphanet).

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/

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

[4] https://freenet.org/faq/

[5] https://youtu.be/3SxNBz1VTE0

Show HN: Freenet, a peer-to-peer platform for decentralized apps
freenet.org

Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps

#4
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

Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps

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

Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps

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

Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps

#8
post #5

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?

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

Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps

#9
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

Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps

#10
post #8
post #5

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?

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

For a basic CRDT set, merge rules have to have some kind of temporality basis in the messages such that commutativity is preserved. usually it's a timestamp, sometimes it's an unforgeable value like a hash, e.g. A: { "prev_hash": null, "content": "foobar" } B: { "prev_hash": "", "content": "foobarbaz" } C: { "prev_hash": "", "content": "foobaz" }

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": "", "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.

Post reply on HN