this repo has no description
lewis.moe
1# Lewis' Big Boy TODO list
2
3## Active development
4
5### Frontend
6So like... make the thing unique, make it cool.
7
8- [ ] Frontpage that explains what this thing is
9- [ ] Unique "brand" style both unauthed and authed
10- [ ] Better documentation on how to sub out the entire frontend for whatever the users want
11
12### Delegated accounts
13Accounts controlled by other accounts rather than having their own password. When logging in as a delegated account, OAuth asks you to authenticate with a linked controller account. Uses OAuth scopes as the permission model.
14
15- [ ] Account type flag in actors table (personal | delegated)
16- [ ] account_delegations table (delegated_did, controller_did, granted_scopes[], granted_at, granted_by, revoked_at)
17- [ ] Detect delegated account during authorize flow
18- [ ] Redirect to "authenticate as controller" instead of password prompt
19- [ ] Validate controller has delegation grant for this account
20- [ ] Issue token with intersection of (requested scopes :intersection-emoji: granted scopes)
21- [ ] Token includes act_as claim indicating delegation
22- [ ] Define standard scope sets (owner, admin, editor, viewer)
23- [ ] Create delegated account flow (no password, must add initial controller)
24- [ ] Controller management page (add/remove controllers, modify scopes)
25- [ ] "Act as" account switcher for users with delegation grants
26- [ ] Log all actions with both actor DID and controller DID
27- [ ] Audit log view for delegated account owners
28
29### Passkeys and 2FA
30Modern passwordless authentication using WebAuthn/FIDO2, plus TOTP for defense in depth.
31
32- [ ] passkeys table (id, did, credential_id, public_key, sign_count, created_at, last_used, friendly_name)
33- [ ] user_totp table (did, secret_encrypted, verified, created_at, last_used)
34- [ ] WebAuthn registration challenge generation and attestation verification
35- [ ] TOTP secret generation with QR code setup flow
36- [ ] Backup codes (hashed, one-time use) with recovery flow
37- [ ] OAuth authorize flow: password → 2FA (if enabled) → passkey (as alternative)
38- [ ] Passkey-only account creation (no password)
39- [ ] Settings UI for managing passkeys, TOTP, backup codes
40- [ ] Trusted devices option (remember this browser)
41- [ ] Rate limit 2FA attempts
42- [ ] Re-auth for sensitive actions (email change, adding new auth methods)
43
44### Plugin system
45Extensible architecture allowing third-party plugins to add functionality, like minecraft mods or browser extensions.
46
47- [ ] Research: survey Fabric/Forge, VS Code, Grafana, Caddy plugin architectures
48- [ ] Evaluate rust approaches: WASM, dynamic linking, subprocess IPC, embedded scripting (Lua/Rhai)
49- [ ] Define security model (sandboxing, permissions, resource limits)
50- [ ] Plugin manifest format (name, version, deps, permissions, hooks)
51- [ ] Plugin discovery, loading, lifecycle (enable/disable/hot reload)
52- [ ] Error isolation (bad plugin shouldn't crash PDS)
53- [ ] Extension points: request middleware, record lifecycle hooks, custom XRPC endpoints
54- [ ] Extension points: custom lexicons, storage backends, auth providers, notification channels
55- [ ] Extension points: firehose consumers (react to repo events)
56- [ ] Plugin SDK crate with traits and helpers
57- [ ] Example plugins: custom feed algorithm, content filter, S3 backup
58- [ ] Plugin registry with signature verification and version compatibility
59
60### Plugin: Private/encrypted data
61Records that only authorized parties can see and decrypt. Requires key federation between PDSes. Implemented as a plugin using the plugin system above.
62
63- [ ] Survey current ATProto discourse on private data
64- [ ] Document Bluesky team's likely approach
65- [ ] Design key management strategy
66- [ ] Per-user encryption keys (separate from signing keys)
67- [ ] Key derivation for per-record or per-collection encryption
68- [ ] Encrypted record storage format
69- [ ] Transparent encryption/decryption in repo operations
70- [ ] Protocol for sharing decryption keys between PDSes
71- [ ] Handle key rotation and revocation
72
73---
74
75## Completed
76
77Core ATProto: Health, describeServer, all session endpoints, full repo CRUD, applyWrites, blob upload, importRepo, firehose with cursor replay, CAR export, blob sync, crawler notifications, handle resolution, PLC operations, did:web, full admin API, moderation reports.
78
79OAuth 2.1: Authorization server metadata, JWKS, PAR, authorize endpoint with login UI, token endpoint (auth code + refresh), revocation, introspection, DPoP, PKCE S256, client metadata validation, private_key_jwt verification.
80
81OAuth Scope Enforcement: Full granular scope system with consent UI, human-readable scope descriptions, per-client scope preferences, scope parsing (repo/blob/rpc/account/identity), endpoint-level scope checks, DPoP token support in auth extractors, token revocation on re-authorization, response_mode support (query/fragment).
82
83App endpoints: getPreferences, putPreferences, getProfile, getProfiles, getTimeline, getAuthorFeed, getActorLikes, getPostThread, getFeed, registerPush (all with local-first + proxy fallback).
84
85Infrastructure: Sequencer with cursor replay, postgres repo storage with atomic transactions, valkey DID cache, debounced crawler notifications with circuit breakers, multi-channel notifications (email/Discord/Telegram/Signal), image processing, distributed rate limiting, security hardening.
86
87Web UI: OAuth login, registration, email verification, password reset, multi-account selector, dashboard, sessions, app passwords, invites, notification preferences, repo browser, CAR export, admin panel, OAuth consent screen with scope selection.
88
89Auth: ES256K + HS256 dual support, JTI-only token storage, refresh token family tracking, encrypted signing keys (AES-256-GCM), DPoP replay protection, constant-time comparisons.