aboutsummaryrefslogtreecommitdiff
path: root/web/index.templ
AgeCommit message (Collapse)AuthorFilesLines
2025-03-29Debug tool for benchmarking proof-of-work algorithms (#155)jae beller1-0/+51
* cmd/anubis: add a debug option for benchmarking hashrate Having the ability to benchmark different proof-of-work implementations is useful for extending Anubis. This adds a flag `--debug-benchmark-js` (and its associated environment variable `DEBUG_BENCHMARK_JS`) for serving a tool to do so. Internally, a there is a new policy action, "DEBUG_BENCHMARK", which serves the benchmarking tool instead of a challenge. The flag then replaces all bot rules with a special rule matching every request to that action. The benchmark page makes heavy use of inline styles, because currently all global styles are shared across all pages. This could be fixed, but I wanted to avoid major changes to the templates. * web/js: add signal for aborting an active proof-of-work algorithm Both proof-of-work algorithms now take an optional `AbortSignal`, which immediately terminates all workers and returns `false` if aborted before the challenge is complete. * web/js: add algorithm comparison to the benchmark page "Compare:" is added to the benchmark page for testing the relative performance between two algorithms. Since benchmark runs generally have high variance, it may take a while for the averages to converge on a stable difference. --------- Signed-off-by: Xe Iaso <me@xeiaso.net> Co-authored-by: Xe Iaso <me@xeiaso.net>
2025-03-29Show a progress bar for the probability of completing the proof of work ↵jae beller1-119/+20
challenge (#87) Since the challenge is done off of the main thread, there is no simple way to report the progress done towards completing it. This change adds a callback parameter, `progressCallback`, which is called with the most recently attempted nonce every ~1024 iterations (should this be configurable?). For the single-threaded "slow" algorithm, this is exactly every 1024 iterations. For the multi-threaded "fast" algorithm, threads take turns reporting in a round-robin as then notice they have passed a multiple of 1024. This complexity is to avoid individual threads falling behind their siblings due to the overhead of messaging the main thread. To minimize this overhead as much as possible, a regular number is sent instead of an object. With the new information provided by the callback, a hash rate display is added to the challenge page. This display is updated at most once per second and set with tabular numbers to avoid the constantly changing value being too visually distracting. * web: show a progress bar based on completion probability To provide more feedback to the user, the spinner is replaced with a progress bar of the probability the challenge is complete. Since it looks a little weird that a progress bar would fill up a quarter of the way and then jump to the end (even though the probability would make that happen 1 in 4 times), the bar is mapped with a quadratic easing function to move faster at the beginning and then slow down as the probability of redirection increases. If the probability exceeds 90%, a message appears letting the user know things are taking longer than expected and to continue being patient. Signed-off-by: Xe Iaso <me@xeiaso.net>
2025-03-28web/js: show more errors when some probable error cases happen (#151)Xe Iaso1-1/+6
Closes #150 This should hopefully make Anubis more self-describing when errors do happen so users can self-service.
2025-03-22Refactor and split out things into cmd and lib (#77)Yulian Kuncheff1-0/+217
* Refactor anubis to split business logic into a lib, and cmd to just be direct usage. * Post-rebase fixes. * Update changelog, remove unnecessary one. * lib: refactor this This is mostly based on my personal preferences for how Go code should be laid out. I'm not sold on the package name "lib" (I'd call it anubis but that would stutter), but people are probably gonna import it as libanubis so it's likely fine. Packages have been "flattened" to centralize implementation with area of concern. This goes against the Java-esque style that many people like, but I think this helps make things simple. Most notably: the dnsbl client (which is a hack) is an internal package until it's made more generic. Then it can be made external. I also fixed the logic such that `go generate` works and rebased on main. * internal/test: run tests iff npx exists and DONT_USE_NETWORK is not set Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: install deps Signed-off-by: Xe Iaso <me@xeiaso.net> * .github/workflows: verbose go tests? Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: sleep 2 Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: nix this test so CI works Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: warmup per browser? Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: disable for now :( Signed-off-by: Xe Iaso <me@xeiaso.net> * lib/anubis: do not apply bot rules if address check fails Closes #83 --------- Signed-off-by: Xe Iaso <me@xeiaso.net> Co-authored-by: Xe Iaso <me@xeiaso.net>