this repo has no description
lewis.moe
1# Lewis' Big Boy TODO list
2
3## Active development
4
5### Migration tool
6Seamless account migration built into the UI, inspired by pdsmoover. Users shouldn't need external tools or brain surgery on half-done account states.
7
8- [ ] Add `migratingTo` parameter to `deactivateAccount` endpoint
9- [ ] For self-hosted did:web users: set `migrated_to_pds`, update DID doc serviceEndpoint
10- [ ] "Migrated" account state for self-hosted did:web: can authenticate but no repo operations
11- [ ] Migrated did:web user UI: minimal dashboard with "update forwarding PDS" setting, or full migration wizard to handle PDS 2 -> PDS 3 moves automatically
12- [ ] Outbound UI wizard: new PDS URL -> export repo -> guide account creation -> complete migration
13- [ ] Inbound UI wizard: login to old PDS -> choose handle -> import -> PLC token flow
14- [ ] Support `createAccount` with existing DID + service auth token
15- [ ] Progress tracking with resume capability
16- [ ] Scheduled automatic backups (CAR export)
17- [ ] One-click restore from backup
18
19### Plugin system
20Extensible architecture allowing third-party plugins to add functionality, like minecraft mods or browser extensions.
21
22- [ ] Research: survey Fabric/Forge, VS Code, Grafana, Caddy plugin architectures
23- [ ] Evaluate rust approaches: WASM, dynamic linking, subprocess IPC, embedded scripting (Lua/Rhai)
24- [ ] Define security model (sandboxing, permissions, resource limits)
25- [ ] Plugin manifest format (name, version, deps, permissions, hooks)
26- [ ] Plugin discovery, loading, lifecycle (enable/disable/hot reload)
27- [ ] Error isolation (bad plugin shouldn't crash PDS)
28- [ ] Extension points: request middleware, record lifecycle hooks, custom XRPC endpoints
29- [ ] Extension points: custom lexicons, storage backends, auth providers, notification channels
30- [ ] Extension points: firehose consumers (react to repo events)
31- [ ] Plugin SDK crate with traits and helpers
32- [ ] Example plugins: custom feed algorithm, content filter, S3 backup
33- [ ] Plugin registry with signature verification and version compatibility
34
35### Plugin: Private/encrypted data
36Records that only authorized parties can see and decrypt. Requires key federation between PDSes. Implemented as a plugin using the plugin system above.
37
38- [ ] Survey current ATProto discourse on private data
39- [ ] Document Bluesky team's likely approach
40- [ ] Design key management strategy
41- [ ] Per-user encryption keys (separate from signing keys)
42- [ ] Key derivation for per-record or per-collection encryption
43- [ ] Encrypted record storage format
44- [ ] Transparent encryption/decryption in repo operations
45- [ ] Protocol for sharing decryption keys between PDSes
46- [ ] Handle key rotation and revocation
47
48---
49
50## Completed
51
52Core 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, full admin API, moderation reports.
53
54did:web support: Self-hosted did:web (subdomain format `did:web:handle.pds.com`), external/BYOD did:web, DID document serving via `/.well-known/did.json`, migration tracking for did:web users who leave (serviceEndpoint redirect), clear registration warnings about did:web trade-offs vs did:plc.
55
56OAuth 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.
57
58OAuth 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).
59
60App endpoints: getPreferences, putPreferences, getProfile, getProfiles, getTimeline, getAuthorFeed, getActorLikes, getPostThread, getFeed, registerPush (all with local-first + proxy fallback).
61
62Infrastructure: 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.
63
64Web 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.
65
66Auth: ES256K + HS256 dual support, JTI-only token storage, refresh token family tracking, encrypted signing keys (AES-256-GCM), DPoP replay protection, constant-time comparisons.
67
68Passkeys and 2FA: WebAuthn/FIDO2 passkey registration and authentication, TOTP with QR setup, backup codes (hashed, one-time use), passkey-only account creation, trusted devices (remember this browser), re-auth for sensitive actions, rate-limited 2FA attempts, settings UI for managing all auth methods.
69
70App password scopes: Granular permissions for app passwords using the same scope system as OAuth. Preset buttons for common use cases (full access, read-only, post-only), scope stored in session and preserved across token refresh, explicit RPC/repo/blob scope enforcement for restricted passwords.
71
72Account Delegation: Delegated accounts controlled by other accounts instead of passwords. OAuth delegation flow (authenticate as controller), scope-based permissions (owner/admin/editor/viewer presets), scope intersection (tokens limited to granted permissions), `act` claim for delegation tracking, creating delegated account flow, controller management UI, "act as" account switcher, comprehensive audit logging with actor/controller tracking, delegation-aware OAuth consent with permission limitation notices.