|
| 1 | +// SPDX-License-Identifier: PMPL-1.0-or-later |
| 2 | +// SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk> |
| 3 | += SafeBruteForce — EXPLAINME |
| 4 | +:toc: preamble |
| 5 | +:icons: font |
| 6 | + |
| 7 | +This file maps README.adoc claims to their implementation evidence for |
| 8 | +sceptical developers. |
| 9 | + |
| 10 | +== "Controlled, ethical brute-force utility with automatic safety pauses" |
| 11 | + |
| 12 | +[quote, README.adoc] |
| 13 | +____ |
| 14 | +Automatic Safety Pauses: Stops every 25 attempts, requires user confirmation. |
| 15 | +____ |
| 16 | + |
| 17 | +How this is implemented:: |
| 18 | +`src/sbf_state.lfe` implements an OTP `gen_statem` state machine with three |
| 19 | +states: `running`, `paused`, and `waiting`. The `should-pause?` predicate |
| 20 | +fires when `(rem attempt-count 25) == 0`, transitioning to `waiting` and |
| 21 | +blocking execution until the user sends a `{continue}` message. The state |
| 22 | +machine cannot be bypassed — it sits between the executor and the pattern |
| 23 | +generator. |
| 24 | + |
| 25 | +Caveat:: |
| 26 | +The pause interval (25 attempts) is the default. It can be configured in |
| 27 | +`config/sys.config` but cannot be set to infinity — the safety pause is |
| 28 | +a mandatory mechanism, not an optional feature. |
| 29 | + |
| 30 | +== "Erlang/OTP concurrent architecture via LFE" |
| 31 | + |
| 32 | +[quote, README.adoc] |
| 33 | +____ |
| 34 | +Concurrent architecture using Erlang/OTP: supervision trees, gen_server |
| 35 | +executor, gen_statem state machine. |
| 36 | +____ |
| 37 | + |
| 38 | +How this is implemented:: |
| 39 | +`src/sbf_app.lfe` is the OTP application entry point. `src/sbf_sup.lfe` |
| 40 | +is the supervisor using `one_for_one` strategy — if the executor crashes, |
| 41 | +it is restarted without taking down the state machine. `src/sbf_executor.lfe` |
| 42 | +is a `gen_server` that manages the worker pool and tracks attempt counts. |
| 43 | +`rebar.config` and `rebar.lock` define the build and dependency configuration. |
| 44 | +The LFE (Lisp Flavored Erlang) dialect compiles to the same BEAM bytecode as |
| 45 | +Erlang. |
| 46 | + |
| 47 | +Caveat:: |
| 48 | +LFE is an unusual choice for a hyperpolymath project (Gleam is the preferred |
| 49 | +BEAM language). This repo pre-dates the Gleam preference and uses LFE. Future |
| 50 | +versions may migrate to Gleam. |
| 51 | + |
| 52 | +== "Rate limiting via token bucket algorithm" |
| 53 | + |
| 54 | +[quote, README.adoc] |
| 55 | +____ |
| 56 | +Rate Limiting: Token bucket algorithm for controlled request rates. |
| 57 | +____ |
| 58 | + |
| 59 | +How this is implemented:: |
| 60 | +`src/sbf_rate_limiter.lfe` implements a token bucket: a bucket is refilled at |
| 61 | +a configurable rate (tokens per second), and each attempt consumes one token. |
| 62 | +When the bucket is empty, the executor waits until a token is available before |
| 63 | +proceeding. This is in addition to (not instead of) the safety pause. |
| 64 | + |
| 65 | +Caveat:: |
| 66 | +The token bucket is a soft rate limit — it adds delay but does not guarantee |
| 67 | +a precise requests-per-second rate due to Erlang scheduler jitter. For |
| 68 | +strict rate limiting, pair with system-level network controls. |
| 69 | + |
| 70 | +== "Checkpoint and resume for long-running operations" |
| 71 | + |
| 72 | +[quote, README.adoc] |
| 73 | +____ |
| 74 | +Checkpoints: Auto-save and manual checkpoint creation. Resume from checkpoints. |
| 75 | +____ |
| 76 | + |
| 77 | +How this is implemented:: |
| 78 | +`src/sbf_checkpoint.lfe` serialises the current execution state (attempt count, |
| 79 | +patterns tried, successful patterns) to DETS (Erlang disk-based term storage) |
| 80 | +with a timestamped key. The REPL function `sbf:save_checkpoint/1` writes a |
| 81 | +manual checkpoint; `sbf:load_checkpoint/1` restores from a named checkpoint. |
| 82 | +Checkpoints are stored in the `priv/checkpoints/` directory. |
| 83 | + |
| 84 | +Caveat:: |
| 85 | +DETS is not a crash-safe storage — a power loss during a write may corrupt |
| 86 | +the checkpoint file. For critical long-running sessions, use frequent manual |
| 87 | +checkpoints rather than relying solely on auto-save. |
| 88 | + |
| 89 | +== Dogfooded Across The Account |
| 90 | + |
| 91 | +[cols="1,2,2", options="header"] |
| 92 | +|=== |
| 93 | +| Technology / Pattern | Used here | Also used in |
| 94 | + |
| 95 | +| OTP gen_statem for state machines |
| 96 | +| Pause/resume state machine |
| 97 | +| link:https://github.com/hyperpolymath/boj-server[boj-server] |
| 98 | + (cartridge lifecycle state management) |
| 99 | + |
| 100 | +| Erlang/BEAM for concurrency |
| 101 | +| Worker pool, supervision trees |
| 102 | +| link:https://github.com/hyperpolymath/burble[burble] |
| 103 | + (Elixir/BEAM control plane) |
| 104 | + |
| 105 | +| Token bucket rate limiting |
| 106 | +| Attempt rate control |
| 107 | +| link:https://github.com/hyperpolymath/boj-server[boj-server] |
| 108 | + (API rate limiting) |
| 109 | + |
| 110 | +| Rebar3 build tool |
| 111 | +| LFE compilation and test runner |
| 112 | +| Unique to BEAM Erlang repos in the account |
| 113 | + |
| 114 | +| DETS persistence |
| 115 | +| Checkpoint storage |
| 116 | +| Unique to this repo |
| 117 | +|=== |
| 118 | + |
| 119 | +== Known Gaps |
| 120 | + |
| 121 | +[CAUTION] |
| 122 | +==== |
| 123 | +The README and `CLAUDE.md` at the repo root reference LFE (Lisp Flavored |
| 124 | +Erlang) as the language, but the hyperpolymath-standard BEAM language is |
| 125 | +Gleam. A future migration from LFE to Gleam is the correct direction. |
| 126 | +==== |
| 127 | + |
| 128 | +The `rust_nif/` directory and `rebar.config`'s Rust NIF support suggest a |
| 129 | +Rust-backed performance path is planned but not yet implemented. The current |
| 130 | +implementation is pure LFE. |
| 131 | + |
| 132 | +The web UI mentioned in the v0.2.0 roadmap section does not yet exist. SSH, |
| 133 | +FTP, and database connection modules are also roadmap items, not current |
| 134 | +capabilities. |
0 commit comments