Legal

Privacy

Short, because the posture is simple: fixing is local, sharing is opt-in, and what the network keeps about you is pseudonymous by construction.

The account

An account is a key pair. The account id is derived from your public key — no email, no name, no phone number. You prove ownership by signing; the server never sees your private key. Pages that show accounts show the first 4 and last 4 characters of the id (a “4+4 id”) — enough to recognise, not enough to identify.

What never leaves your machine

The dry run and every fix run locally. Logged out, cargo refine uploads nothing: no telemetry, no error reports, no usage counts. It does download: cargo refine update and sync fetch the public fix corpus, a read that tells the server nothing beyond the request itself (your IP address, as any download does). (The Rust toolchain it drives — cargo fetching dependencies, docker resolving images — behaves as it always does; that traffic is yours, not ours.)

What mining uploads — opt-in, per machine

Mining is the one thing that uploads, and it is off until you switch it on with cargo refine --mine. The switch is per machine: once it is on, every heal run on that machine syncs. What each repo contributes is then decided by its own deny-by-default policy file (.refine-sync-policy, which --mine writes in the repo you run it from). A repo with no policy file syncs nothing. A signed batch then carries:

• the fix records: which rule fired (lint_key) and its rule family (domain), the code span the fix replaced and its replacement (shape / fix, each capped at 64 KiB) with the snippet’s content hash (shape_id), counters — how often the rule worked (success_count, fail_count, consecutive_fails), a quality rating the local model maintains (elo, span_elo), and an evidence tier (tier) — a direction vector, 8 numbers the local model derives from the change, the id of the run that produced it (last_run_id), a timestamp of when it was last seen (last_seen_at), and the row’s secret-scan verdict (gate: a decision that reads allow or redacted, plus findings — one entry per detected secret, described under redacted mode below);
• a header: row counts (rows_included, rows_blocked), a checksum over the rows (batch_commitment), the schema and scanner version numbers (payload_version, redact_version), a fixed source tag (origin, always “own-repo” — it names no project), the batch’s creation time (created_unix), your account’s public key (account_pubkey_hex — public by design; it is how a batch is attributed to an account), and a signature made with it (signature_hex).

Never whole files. Never file paths or directory names. Each snippet is capped at 64 KiB, and every row passes a secret scan before the batch is signed: hex-shaped strings of 32+ characters are blocked outright, other high-entropy strings too — each finding drops the row by default, and redacted mode (below) is the one alternative. The scanner has honest limits — a secret wrapped in another encoding (byte arrays, xor, split literals) is treated as uncaught, not probably caught. Treat the batch for what it is: spans of your own code, selected by a policy you wrote.

Redacted mode — opt-in, per project

The default is the drop above: a detected secret excludes its whole row from the batch. If your policy file instead sets allow_redacted, the row ships with every detected secret replaced by a [REDACTED:kind] placeholder — for example [REDACTED:aws-access-key] — and the row’s gate metadata records each finding as three facts: which field it was in, the secret’s kind, and a 12-hex-character fingerprint (the first 48 bits of the secret’s BLAKE3 hash). The secret’s bytes never leave your machine — but be honest about what the fingerprint is: someone who already holds the secret could hash a guess and confirm a match against it. The fingerprint says what kind of thing was redacted and lets the row stay useful as training data; it is not a guarantee that nobody can test a guess. If that is more than you want to disclose, leave allow_redacted off — the drop-the-row default is what runs without it.

See for yourself: a real batch from a small demo crate after 4 fixes — and cargo refine sync --export writes your own crate’s exact batch to a file without sending anything.

What the server keeps

• Mining rows: the fix records above, keyed by a content hash. They feed the verification queue and the epoch settle. A row the verification pass proves is published: its before/after snippet joins the shared corpus every machine downloads, from a public URL with no login, under the MIT licence (the terms say what mining licenses).
• Work aggregates: per-epoch counters of which rules the network fixed, plus a machine label only if you set one (RIIR_REFINE_MACHINE_LABEL; current builds send none, older builds sent your hostname — update and re-run --mine to replace it). The label is stored, never shown on a public page. Counts, never text.
• Decision-outcome rows (opt-in, separate consent): which decision suite and answer class a hosted lane chose. Counts and classes, never your questions or answers.
• Ledger records: balances, the free-grant marker, burn watermarks and burn events, mint receipts, stake tranches, payment intents — keyed by account id.
• Browser wallet sessions (only if you use the browser wallet): a short-lived session row binding your GitHub login or wallet key to the account ids your published keys match. No cookies — the page holds the session token.

Retention and deletion — the honest version

There is no automated server-side deletion today. The ledger is the books: records settle into epoch history and stay. If you want an account’s records removed, write to security@gist.rs — the operator will remove what the account owns where the books’ integrity allows, and would rather tell you a record stays than pretend otherwise.

No sale, no ads, no analytics

Nothing here is sold or shared for advertising, ever. These pages carry no analytics, no trackers, no cookies; the only third party involved in serving them is the hosting provider. What the network fixes and who contributes is public by design — shown by pseudonymous 4+4 ids on the leaderboard.

Changes

Material changes to this policy are announced on this page before they take effect. Questions: security@gist.rs, or the contact named in security.txt.