lewis.moe
+14
-15
TODO.md
+14
-15
TODO.md
···
5
### Migration tool
6
Seamless 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
-
- [x] Add `migratingTo` parameter to `deactivateAccount` endpoint
9
-
- [x] For self-hosted did:web users: set `migrated_to_pds`, update DID doc serviceEndpoint
10
-
- [x] "Migrated" account state for self-hosted did:web: can authenticate but no repo operations
11
-
- [x] 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
-
- [x] Outbound UI wizard: new PDS URL -> export repo -> guide account creation -> complete migration
13
- [x] Inbound UI wizard: login to old PDS -> choose handle -> import -> PLC token flow
14
- [x] Support `createAccount` with existing DID + service auth token
15
- [x] Progress tracking with resume capability
16
- [ ] Scheduled automatic backups (CAR export)
17
- [ ] One-click restore from backup
18
19
### Plugin system
20
-
Extensible 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
36
Records that only authorized parties can see and decrypt. Requires key federation between PDSes. Implemented as a plugin using the plugin system above.
···
51
52
Core 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
54
-
did: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
56
OAuth 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
···
5
### Migration tool
6
Seamless 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
- [x] Inbound UI wizard: login to old PDS -> choose handle -> import -> PLC token flow
9
- [x] Support `createAccount` with existing DID + service auth token
10
- [x] Progress tracking with resume capability
11
- [ ] Scheduled automatic backups (CAR export)
12
- [ ] One-click restore from backup
13
14
+
Outbound migration wizard exists but is disabled. Rethinking the approach: instead of a managed flow with `migratingTo` state, pds-hosted did:web users should just have direct control over their DID document. They can independently update serviceEndpoint, add/remove keys, export their repo, deactivate their account.
15
+
16
+
- [ ] Remove `migratingTo` field and related state machine
17
+
- [ ] Let did:web users edit their DID doc fields (serviceEndpoint, keys) whenever
18
+
- [ ] Repo export as standalone feature, not tied to migration wizard
19
+
20
### Plugin system
21
+
Extensible architecture allowing third-party plugins to add functionality. Going with wasm-based rather than scripting language.
22
23
- [ ] Plugin manifest format (name, version, deps, permissions, hooks)
24
+
- [ ] Plugin loading and lifecycle (enable/disable/hot reload)
25
+
- [ ] WASM host bindings for PDS APIs (database, storage, http, etc.)
26
+
- [ ] Resource limits (memory, cpu time, capability restrictions)
27
- [ ] Extension points: request middleware, record lifecycle hooks, custom XRPC endpoints
28
- [ ] Extension points: custom lexicons, storage backends, auth providers, notification channels
29
- [ ] Extension points: firehose consumers (react to repo events)
30
+
- [ ] Plugin sdk crate with traits and helpers?
31
+
- [ ] Example plugins: cdc, extra logging to 3rd party, content filter, better S3 backup
32
+
- [ ] Plugin registry with signature verification?
33
34
### Plugin: Private/encrypted data
35
Records that only authorized parties can see and decrypt. Requires key federation between PDSes. Implemented as a plugin using the plugin system above.
···
50
51
Core 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.
52
53
+
did: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`, clear registration warnings about did:web trade-offs vs did:plc.
54
55
OAuth 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.
56