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

▲

sanity 3 hours ago | parent [-]

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.

	▲	Groxx 2 hours ago \| parent [-]
		yea, there's a lot of scenarios it doesn't make sense in imo. and even with processing-gas-limits it's still kinda weird and harder to prevent abuse on (e.g. you can't predict costs because you don't know what requests it might send next - graphql's declarative approach helps it here). but for e.g. mobile apps with a trusted backend? probably great. you could even just send hashes of the WASM blobs because they will often be identical (and the full blob if that fails), and some serialized data to serve as args that vary (e.g. page-size limit of the third internal request), and you'd have an absurdly flexible system with fairly small requests. I'm just not sure how small, or if it'd end up computationally worth it compared to graphql / sparql / etc.