glm-5.1
2b63cda1c7
Copy architecture docs, ADRs, storage domain specs, research, reviews, and 56 storage architecture tasks from the alkhub_ts monorepo. Adapt for standalone @alkdev/hub repo structure (src/ not packages/hub/). Sanitize all sensitive information: - Replace private IPs (10.0.0.1) with localhost defaults - Remove internal server hostnames (dev1, ns528096) - Replace /workspace/ private paths with npm package references - Remove hardcoded credentials from examples - Rewrite infrastructure.md without private network details Add Deno project scaffolding: deno.json (pinned deps), .gitignore, AGENTS.md, entry point. Migrate existing code stubs (crypto, config types, logger) with updated import paths.
17 lines
1.0 KiB
Markdown
17 lines
1.0 KiB
Markdown
# ADR-004: Keypal integration strategy
|
|
|
|
- **Status**: Accepted
|
|
- **Date**: 2026-04-19
|
|
- **Deciders**: alkdev
|
|
|
|
## Context
|
|
|
|
keypal (v0.1.11, MIT) provides API key management with hashing, scopes, caching, and a Drizzle storage adapter. Need API key management for hub authentication.
|
|
|
|
## Decision
|
|
|
|
Use keypal as a dependency (not fork). Import core utilities (createKeys, hashKey, validateKey, scope checking) directly. Define our own api_keys table following the commonCols pattern with proper columns for high-query fields (owner_id, key_hash, enabled, expires_at, revoked_at). Implement keypal's Storage interface as a thin adapter (HubKeyStorage) over our Drizzle tables.
|
|
|
|
## Consequences
|
|
|
|
Custom Storage adapter is more work than using keypal's DrizzleStore directly, but our commonCols pattern and column structure are important for consistency. The adapter is ~100 lines and straightforward. Positive: clean integration that respects our schema conventions. Negative: maintenance burden on adapter if keypal's Storage interface changes. |