## Goal The magic-link request form gets a **honeypot field**: a hidden input humans never see or fill, which naive form-filler bots do. A submission with the honeypot filled is silently swallowed — identical `{ ok: true }` response, but no login token issued and no mail sent. Zero UX cost for real users; cuts the generic form-spam noise on the one public endpoint that mails arbitrary addresses. ## Context — current state - `POST /api/v1/auth/request-link` (`apps/api/src/http/auth.ts`) already has real protection: per-IP 10/15 min (IPv6 keyed on the /64), per-email 3/15 min, enumeration-safe identical responses, and the signup-closed gate (unknown addresses get no mail when signup is closed). What it lacks is any deterrent against dumb bots *filling the form itself*. - Since the landing page (#181), the login form is publicly discoverable by crawlers. **Consequence if left alone:** while signup is open, generic form-spam bots can make the instance mail magic links to strangers — unsolicited mail carrying the instance's name, sent through the operator's relay, where a burst harms deliverability of everything else that relay sends. - A honeypot only fools bots that drive the form; a client replaying the JSON call just omits the field. The backstop for that class (an instance-wide outbound-mail cap) was discussed alongside this item and is deliberately **not** in scope here — it would be its own story. ## Decisions 1. **Field name `homeport`** — plausible enough that form-fillers populate it, and outside the browser-autofill vocabulary (`website`, `url`, `fax`, …), so a real user's browser never autofills it and locks them out silently. Optional string on `RequestLinkBody` (absent/empty = normal path). 2. **Tripped path gates only token + mail.** Both rate limiters are consumed exactly as on the normal path, the response is the byte-identical `200 { ok: true }`, and 429 behavior is unchanged — the honeypot introduces **no oracle at all**; the only difference is that no token row is written and no mail leaves. (Consuming the email budget on tripped requests is no regression: a bot could burn it anyway by simply not filling the field.) 3. **Tripped requests are logged** (`warn`, with the client rate key, not the submitted address) so abuse is visible in the logs. 4. **SPA rendering:** the input lives in the login form (`apps/web/src/routes/Login.tsx`) visually off-screen via CSS (not `display:none` — some fillers skip those), with `tabindex="-1"`, `aria-hidden="true"`, `autocomplete="off"`, no label text and nothing in the i18n catalogs — keyboard and screen-reader users never meet it. 5. **Only this form.** No other unauthenticated endpoint triggers mail; invitation mail requires an authenticated owner and has its own budget. ## Scope - **Contracts**: optional `homeport` field on `RequestLinkBody` (`packages/contracts`). - **API**: honeypot check in the request-link handler per decision 2, plus the log line. - **Web**: hidden field per decision 4; submitted value wired into the request-link call. - **Docs, same commit**: `API-CONTRACTS.md` (request-link body), `ARCHITECTURE.md` (auth flow — honeypot listed beside the rate limits as the abuse controls on this endpoint). ## Acceptance criteria - [ ] A honeypot-filled request returns the byte-identical `200 { ok: true }`, writes no login-token row, sends no mail, and logs a warning; rate-limit behavior (including 429s) is indistinguishable from the normal path. - [ ] An absent or empty honeypot behaves exactly as today (existing request-link tests untouched or extended, not weakened). - [ ] The login form renders the field off-screen, unfocusable via keyboard, invisible to screen readers, and submits it empty on a normal user flow (web test asserts the empty submit). - [ ] Docs updated in the same commit (see Scope). Depends on: nothing open — builds on the request-link limiters and #181 (landing page).