Skip to content

fix(imap): AuthAdapter JSDoc drift -- remove argon2 and D1 prescription#79

Merged
ssilvius merged 1 commit intomainfrom
fix/imap-auth-comment-drift
Apr 11, 2026
Merged

fix(imap): AuthAdapter JSDoc drift -- remove argon2 and D1 prescription#79
ssilvius merged 1 commit intomainfrom
fix/imap-auth-comment-drift

Conversation

@ssilvius
Copy link
Copy Markdown
Contributor

Summary

One-line (conceptually) fix. The JSDoc block above `AuthAdapter` in `packages/imap/src/commands/auth.ts` said:

App passwords are stored hashed (argon2) in D1 and verified here.

That is wrong on two axes:

  1. Interface-only posture. The IMAP server does not own credential storage or hashing. That was the original design but it was rewritten (per @vault-2026 review and Sean's call): `AuthAdapter` is a contract only, the consumer brings their own auth system. Prescribing argon2 contradicts the rewritten contract.
  2. Core must be generic. The rule from Sean is explicit: core docs use "blob storage" not "R2", "database" not "D1". Naming D1 inside the core protocol package violates the zero-vendor-dependency principle.

This is the same drift I found in `packages/imap-server/docs/quickstart.md` and fixed in PR #78 -- except this copy is in the source code JSDoc, not a doc file. The JSDoc ships in the npm tarball's `dist/*.d.ts` files and is the authoritative reference for anyone who hovers the `AuthAdapter` type in their editor.

The fix

Replaced the 1-line wrong prescription with a proper JSDoc block that:

  • States the interface-only posture explicitly
  • Names the consumer's ownership (storage, hashing, generation, revocation)
  • Lists the security guarantees the IMAP server DOES enforce regardless of adapter implementation (generic failure response, rate limit, disconnect after max attempts)
  • Uses neutral language with no vendor names

Verification

  • `pnpm --filter @rafters/mail-imap test`: 313 passing
  • `pnpm --filter @rafters/mail-imap typecheck`: clean
  • `pnpm --filter @rafters/mail-imap build`: ESM + dts clean
  • `pnpm lint`: 0 warnings, 0 errors
  • `legion-simplify` gate: clean

Scope

Single file, docblock only. No runtime behavior change. Safe to merge independently of the rest of the ship-to-npm PR stack.

@ssilvius ssilvius force-pushed the fix/imap-auth-comment-drift branch from e91357d to add0b61 Compare April 11, 2026 19:03
The JSDoc above `AuthAdapter` said "App passwords are stored hashed
(argon2) in D1 and verified here." That's wrong on two axes:

1. The IMAP server does not own credential storage or hashing. That
   was the original design but it was rewritten: AuthAdapter is an
   interface contract only, the consumer brings their own auth system.
   Prescribing argon2 contradicts the rewritten contract.

2. Core docs must be generic: "blob storage" not "R2", "database" not
   "D1". Referencing D1 by name inside the core protocol package
   violates the zero-vendor-dependency principle.

Replaced with a proper JSDoc block that:
- States the interface-only posture explicitly
- Names the consumer's ownership (storage, hashing, generation,
  revocation)
- Lists the security guarantees the IMAP server DOES enforce
  regardless of adapter implementation (generic failure response,
  rate limit, disconnect after max attempts)
- Refers to the adapter lifecycle in neutral language

This matches the authoritative `authentication.md` doc shipped in PR
#76 and the interface-only posture in the `@rafters/mail-imap-server`
quickstart.md fixed in PR #78.

Verification:
- pnpm --filter @rafters/mail-imap test: 313 passing
- pnpm --filter @rafters/mail-imap typecheck: clean
- pnpm --filter @rafters/mail-imap build: ESM + dts clean
- pnpm lint: 0 warnings, 0 errors

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ssilvius ssilvius force-pushed the fix/imap-auth-comment-drift branch from add0b61 to 572f443 Compare April 11, 2026 19:29
@ssilvius ssilvius merged commit b0d897c into main Apr 11, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant