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.)
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
> 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?
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": "<hash of A>", "content": "foobarbaz" }
C: { "prev_hash": "<hash of B>", "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": "<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.
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:
ELI5, how is this different than the internet?
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.)
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
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": "<hash of A>", "content": "foobarbaz" } C: { "prev_hash": "<hash of B>", "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": "<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.
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!
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
We had too much Gnutella. I am in search for a locus to us. Now. SCNR