@vii @i @mpg

> I really don't want to be sketching JS myself right now

Nobody wants to write JS!

> Theoretically yes, but by what strategy? Do we just race for the first one to return and kill the rest? That seems... potentially expensive.

The idea is to have one in-flight on all the servers you've got, and then for each block it doesn't find (for obvious reasons, regular HTTP traffic to hit the endpoint doesn't trigger the slush), rotate the list to ask the next server; the side-effect is that unless the server you get the head block from does some sniffing on block contents (in which case it could know what you're fetching) then none of the other servers knows what you're assembling, so you could enforce fetching the first one (or all the non-leaf blocks) from servers with .onion hostnames and then the rest could. (This isn't perfect, like someone could construct a blob such that there's a block only people fetching one specific thing will fetch.) The problem with a tree is you've gotta pointer-chase down the list but that only really matters for the first few blocks because it gets to be a linear stream in a hurry, so maybe something like use one fetching strategy until you get to leaf blocks and then those can be filled in in parallel using a different strategy. Or something like have the fetcher notice when it's hit the bottom and have it start firing off parallel requests to populate the cache while the local CPU runs around juggling arrays because JavaScript is a language for idiots and it's not good at strings or blobs.

Anyway, concept of proofed, like, there'll be a reasonable strategy for doing this client-side but I don't know if client-side assembly is worth it instead of just running a local peer.