gkapi: per-IP invite rate limit is defeated by Tor circuit rotation

[sanity]

Problem

A spammer is repeatedly joining the Official River room under a small set of fixed
nicknames (TORMENTA, FURIA, Presagio). They have been banned 20+ times and keep
returning. Two independent causes; this issue covers the upstream one.

gkapi's per-IP invite limit is defeated by Tor circuit rotation.

rate_limit.rs allows MAX_INVITES_PER_WINDOW = 20 per IP. That is sound against a
single host, but the abuser rotates Tor exit nodes, so each request presents a fresh
IP and the limit never engages.

Evidence from /var/lib/gkapi/invite_rate_limits.json on vega (2026-07-25, UTC):

15-min bucket	invites	from Tor exits
baseline (18:00-22:00)	30-36	0
02:40	85	59
02:50	143	93

Organic quickstart traffic runs ~30-36 invites per 15 min with zero Tor-exit
origin. The 02:40-02:58 burst was 228 invites in ~18 minutes, 67% of them from
135 distinct Tor exit IPs (192.42.116.x, 185.220.101.x, 185.220.100.x,
109.70.100.x, 171.25.193.x, 45.84.107.x). No individual IP came close to the
20-request limit.

Because every invite yields a fresh keypair, per-identity banning cannot converge:
the abuser mints new identities faster than a moderator can ban them.

Why this is not simply "block Tor"

Freenet is a privacy project and the quickstart is the main onboarding path.
Blocking Tor exits would stop this abuser today at the cost of excluding exactly
the users the project exists to serve. That is a values decision, not a technical
one, so this issue documents options rather than picking one.

Options

1. Global burst limit (Tor-agnostic). Cap total issuance network-wide (e.g. N/min
   across all IPs) and shed load above it. Blunt, but the burst signature here (143 in
   15 min vs a 30-36 baseline) is ~4x baseline and trivially separable. Does not
   discriminate by origin.
2. Proof-of-work on /create-invite. Makes bulk minting cost CPU while staying
   near-free for one genuine user. Preserves Tor access. Costs some onboarding latency.
3. Per-/24 or per-ASN limiting. Raises the cost of rotation somewhat, but Tor exits
   span many ASNs, so this is partial at best.
4. Block Tor exit nodes. Effective immediately; carries the values cost above.
5. Do nothing upstream and rely on the moderation-side mitigations already applied
   (see below).

My read: (2) is the only option that actually fixes the asymmetry without excluding
Tor users, and (1) is a cheap stopgap that could ship first. But this is your call.

Already applied (moderation side, no code change)

• max_user_bans on the Official room raised 10 -> 200. This was the more
  immediate cause: the ban list is a FIFO, it was full at 10/10, and every new ban
  evicted the oldest — allowing a previously-banned identity to walk back in
  unchanged. Ban list went from 10 to 63 retained bans the instant the cap rose,
  with several identities appearing 2-3 times (banned, evicted, returned, re-banned).
• ~/bin/river-official-autoban.sh + */5 cron on nova: sweeps the member list and
  bans exact-nickname matches from a watchlist, so the manual toil stops.

Neither of these fixes the root asymmetry — they just stop the bleeding.

[AI-assisted - Claude]

[sanity]

Correction + status update

Two things in the issue body above are now known to be wrong, and one option got
built. Correcting the record rather than editing history.

1. The per-IP limit is 4/24h, not 20

The issue says MAX_INVITES_PER_WINDOW = 20. That was already stale when
written: #74 (merged 2026-07-16) lowered it to 4 and switched the limiter to
key on the TCP socket peer IP instead of X-Forwarded-For.

That second half matters and deserves calling out — gkapi binds :80/:443 directly
with no reverse proxy, so trusting X-Forwarded-For meant the limit was
bypassable with a spoofed header. #74 closed that, and it's what makes Tor exit
detection meaningful at all: a spoofable client IP would defeat any origin-based
metering.

2. The burst numbers were understated

The issue cites 228 invites / ~18 min / 135 Tor exits (67%). That came from a
prefix heuristic over a partial snapshot. Re-derived from the full dataset
(1728 invites, 2026-07-24T06:23Z–2026-07-25T05:54Z) classified against the
official bulk exit list:

Burst 02:35–03:05Z: 246 invites from 202 distinct IPs, 200 of them via 159 Tor
exits.

3. What got built: option (1½), and it is a stopgap

The issue deliberately declined to pick a fix and routed the values call to
@sanity. #82 implements something not on the option list: a Tor-specific
aggregate ceiling — neither the origin-blind global burst cap (option 1) nor
proof-of-work (option 2). That was my call to make in code, and flagging it here
so the decision is recorded where the issue asked for it.

It is not deployed and I've recommended it not be until @sanity rules on the
tradeoff, because review disproved the premise it was built on:

• Organic Tor peaks at 33/hour, not the 11 I originally derived (my earlier
  figure came from excluding busy hours as "burst" by magnitude, then taking the
  max of the rest — circular). The first ceiling, 25/hour, would have refused
  real users. It is now 60 and runtime-tunable.
• "Ordinary Tor users are unaffected" is false under attack. Sustaining the
  ceiling costs ~150 exits/day out of ~1400 available, refused requests cost the
  attacker nothing, and a poller wins every freed slot against a human. Before
  feat(gkapi): meter Tor exits through one shared invite ceiling #82, denying Tor users invites was not possible; after it, it is cheap.

So the asymmetry this issue is actually about is not closed by #82. #82
shaves the peak and buys time.

Recommendation unchanged: option (2), proof-of-work

It remains the only option on the list that closes the asymmetry rather than
raising its price, and the only one that preserves Tor availability under
attack — which is precisely when availability matters. A shared bucket over an
unlinkable pool cannot do that by construction: the loudest member takes the
budget.

Keeping this open; #82 is Refs, not Closes.

Related, worth its own issue

Review of #82 surfaced that CorsLayer::permissive() applies to
/create-invite. With a shared budget that becomes an amplifier: any webpage
can make Tor Browser visitors drain the ceiling without the attacker owning a
circuit. Not fixed in #82 (an Origin allowlist is a distinct change with its
own risk). Worth filing separately if the aggregate ceiling ships.

[AI-assisted - Claude]

[sanity]

Network-wide impact measurement (2026-07-25)

This is no longer just a moderation problem. Telemetry analysis of the invite-spam
wave shows the Official River room contract is now the single largest source of
broadcast traffic on the Freenet network.

Three ~2.5h telemetry windows (~5.2 GB / 7.4-7.6M records each) from
/mnt/media/freenet-telemetry/:

metric	07-23	07-24 pre-spam	07-25 now	now/pre
room broadcast_received	6,084	5,085	563,891	111x
room broadcast_emitted	438	303	68,130	225x
room per-target sends (fanout)	4,691	3,930	660,984	168x
room % of ALL network broadcast	0.49%	0.55%	32.09%	58x
room rank by broadcast volume	>#12	>#12	#1	—
room state size (median)	178 KB	162 KB	323 KB	2.0x
peers hosting room updates	58	66	296	4.5x
transfers_failed (network-wide)	1,921	2,455	85,583	35x

The room accounts for 67% of the entire network's broadcast-traffic growth over
that window.

Causal chain

1. Invite spam via /quickstart — 47-107 new identities/hour, sustained 18+ h
   (cumulative roster 337 → 1,443), driven by the per-IP limit defeated by Tor
   rotation described above.
2. Every join / ban / message is a room state change, fanned out to ~296 hosting peers.
3. The spam widened the hosting mesh 4.5x (66 → 296 peers), multiplying fan-out.
4. Room state grew 162 KB → 323 KB.
5. Per-hop cost scales with state size: each per-target send runs summarize_state
   • get_state_delta over the full state, ~10 targets per emit.
6. Per-hop local processing went 154 ms → 539 ms p50 / 2,285 ms p90, with worst
   peers at p50 13-31 s. Over ~3 hops that reconstructs the user-visible
   1-2 s → 6-11 s message delay.

Notably this is a CPU cost, not bandwidth: room broadcast payloads measured at
370-379 bytes, so deltas are working correctly. The expense is per-target WASM
execution over a large state.

Caveat, stated honestly: end-to-end delay is reconstructed, not directly
measured — per-peer clock skew makes cross-peer timing unusable, so only same-peer
recv→apply deltas are trustworthy. The per-hop numbers are skew-free; the 6-11 s
is per-hop cost x estimated hop count.

Why moderation cannot fix this

The room's ban list sits at 200/200, completely full. At ~80 spam identities/hour
a 200-slot FIFO turns over completely every ~2.5 hours, so bans are evicted,
identities rejoin unchanged, and every rejoin-and-reban is more state churn.
Banning is a treadmill that adds load. Only stopping invite minting converges.

Bearing on this issue

This is the strongest available argument for acting on #81 rather than leaving it
to moderation. The per-IP limit is defeated by rotation, and the downstream cost is
no longer confined to one room's usability — a single contract is consuming roughly
a third of the network's broadcast traffic and degrading its own latency 3.5-6.8x
per hop.

PR #82 (shared hourly ceiling across the Tor exit set) bounds the minting rate. It
does not close the asymmetry — proof-of-work remains the only option that does —
but it is implemented, reviewed and available now.

Measurement scripts and raw aggregates preserved at /tmp/river-delay-scripts/
(extract.py, latency.py, plus before23.json / pre_spam.json / now.json)
so every number here is auditable without re-running the analysis.

[AI-assisted - Claude]