Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It took a year to ship WebAssembly in Anubis

anubis.techaro.lol

Post reply on HN
Print view View original

111–120 of 225 posts

Re: It took a year to ship WebAssembly in Anubis

#111

Post by evnp »

doctor_radium wrote: post #103

I have every copy of Firefox here configured with webassembly disabled...because I don't tend to do what Webassembly was designed for, i.e. online games, video/audio editing, emulation, etc. [1] and because I dislike things running in the background without my knowledge. So this is going to be interesting. My plea (in a small voice) to the OP: just as many sites still do for JavaScript, please add a "This captcha req…

The second half of this post chronicles the author's Herculean efforts to make everything work well in the cases you describe.

> One of the big things that blocked this shipping for so long was not having an escape hatch of some kind to allow clients that disable WebAssembly by policy to get through the gate. [...] This combination of factors means that there would need to be another implementation of the proof of work code in JavaScript that would actually execute the number crunching.

Re: It took a year to ship WebAssembly in Anubis

#112

Post by nxobject »

kccqzy wrote: post #55

Hats off to Xe for spending so much time on backwards compatibility, especially the tidbit about targeting Chrome 66. I have a Mac from 2014 running Yosemite that I occasionally use to test for backwards compatibility in my own frontend code (for fun!). But IMO the best way to ensure compatibility is to use period-correct toolchains or toolchains where the pace of change is slower, like ClojureScript.

In the non-webdev realm, it's gobsmacking that you can put "FROM debian/eol:buzz" in a Dockerfile, and it will do what it says...

Re: It took a year to ship WebAssembly in Anubis

#113

Post by dspillett »

Lyrex wrote: post #106
dspillett wrote: post #100

> It also means that the "hey Claude vibeslop me a CUDA Anubis solver" route is on its way to being fundamentally dead. I assume that the previous challenges will still be available for circumstances where WASM is not available (unless we are just working on the basis that it is available if JS is?) or perhaps as a fallback. TFA explicitly mentions “smart” TVs, and I'm sure there are plenty of those out there that ru…

the answer to this is in the post: where wasm is not available, he transpiles the wasm binary back to Javascript

Ah I must have skipped by that bit. And presumably the memory-hard algorithm is CPU-easy enough that this won't be a problem. That leaves me wondering "why not just use a JS memory-hard routine in the first place, but maybe I've shouted over that too. I'll give TFA a reread later.

Re: It took a year to ship WebAssembly in Anubis

#114

Post by yborg »

drum55 wrote: post #58
Jtariiiii wrote: post #40

Earlier quoted context omitted.

>It’s not stopping anyone. You could just spend 30 seconds googling instead of confidently asserting nonsense. There are plenty of people demonstrating that Anubis reduces bot traffic.

That’s because its weird and mostly irrelevant, it’s nothing to do with the proof of work being any sort of economic impediment. It takes Claude a few minutes to write a near instant solver, that’s the maximum proof of work cost this adds.

This strain of nihilism about anti-bot efforts baffles me. Cloudflare built a gigantic business on stopping DDoS attacks. There will never be good faith self-restraint by AI bros, there is too much money at stake and no regulation, doing nothing means your only alternative is disconnect from the Internet. Anubis introduces enough friction that some percentage of the lunacy is throttled and possibly give your server a fighting chance.

Re: It took a year to ship WebAssembly in Anubis

#117

Post by tyre »

Lyrex wrote: post #106
dspillett wrote: post #100

> It also means that the "hey Claude vibeslop me a CUDA Anubis solver" route is on its way to being fundamentally dead. I assume that the previous challenges will still be available for circumstances where WASM is not available (unless we are just working on the basis that it is available if JS is?) or perhaps as a fallback. TFA explicitly mentions “smart” TVs, and I'm sure there are plenty of those out there that ru…

the answer to this is in the post: where wasm is not available, he transpiles the wasm binary back to Javascript

tangential fyi: the author is not a he

Re: It took a year to ship WebAssembly in Anubis

#119

Post by xena »

doctor_radium wrote: post #103

I have every copy of Firefox here configured with webassembly disabled...because I don't tend to do what Webassembly was designed for, i.e. online games, video/audio editing, emulation, etc. [1] and because I dislike things running in the background without my knowledge. So this is going to be interesting. My plea (in a small voice) to the OP: just as many sites still do for JavaScript, please add a "This captcha req…

I don't mean to be rude, but please search "wasm2js" in the article.

Re: It took a year to ship WebAssembly in Anubis

#120

Post by trickypr »

dspillett wrote: post #113
Lyrex wrote: post #106

Earlier quoted context omitted.

the answer to this is in the post: where wasm is not available, he transpiles the wasm binary back to Javascript

Ah I must have skipped by that bit. And presumably the memory-hard algorithm is CPU-easy enough that this won't be a problem. That leaves me wondering "why not just use a JS memory-hard routine in the first place, but maybe I've shouted over that too. I'll give TFA a reread later.

I think it is still compute-heavy if not compute-hard, and stuff like WASM SIMD makes it less compute heavy (not really available in JS). And also, for memory bound problems, you probably don't want the JS GC needing to clean up afterwards when WASM gives you that control.
Post reply on HN