Gzipped WASM based IPFS website?


I tried searching for a way to gzip my wasm based website that I host on IPFS but found no solution.

Browsers only unzip when the server send special headers but there’s no server in this case…

Has anyone tried something like this?

Can you add some more details about your griped wasm based website. Sounds interesting. I’m a big fan of wasm and I’m very interested in its use with IPFS so your project sounds intriguing.

Is there a reason it has to be gzipped? I vaguely recall some discussion about using a metadata file to do more complex things with serving files but I don’t think it got much further than a proposal.

Using Gzip can reduce Wasm binary size by 50% It’s worth trying to find a way to trick the browser into unzipping the binary.

Http headers are used by server to inform the browser. → “Content-Encoding” “gzip”

Right now I add a directory to IPFS containing the html, js, wasm, and the browser display the website fine. If IPFS were to add metadata to the IPLD object used to represent the directory it could work but is there no alternative that do no require modifying IPFS itself, some kind of hack?

Checkout my project at github.com/sionois/dit

I’d be using something like nginx as a reverse proxy if you need to add or edit the headers.

I can’t do that it’s a decentralized website there is no server.

1 Like

Here’s that proposal I mentioned Proposal: manifest file for the IPFS gateway · Issue #6214 · ipfs/go-ipfs · GitHub

After reading it seams like a features that is not that popular. Gluing HTTP and IPFS together is bound to produce friction I guess…

I wonder if you could include decompression code right in the folder then unzip the binary with it?
Would that be faster?

You could try using a web assembly decompressor. https://github.com/ColinTimBarndt/wasm-gzip Is one of them. There are a bunch of others

Thanks! Seams like a small enough binary that the compression would be worth it.

It will require testing to be sure it’s faster but a least it’s doable.