this repo has no description
lewis.moe
1# Lewis' Big Boy TODO list
2
3## Active development
4
5### Storage backend abstraction
6Make storage layers swappable via traits.
7
8filesystem blob storage
9- [ ] FilesystemBlobStorage implementation
10- [ ] directory structure (content-addressed like blobs/{cid} already used in objsto)
11- [ ] atomic writes (write to temp, rename)
12- [ ] config option to choose backend (env var or config flag)
13- [ ] also traitify BackupStorage (currently hardcoded to objsto)
14
15sqlite database backend
16- [ ] abstract db layer behind trait (queries, transactions, migrations)
17- [ ] sqlite implementation matching postgres behavior
18- [ ] handle sqlite's single-writer limitation (connection pooling strategy)
19- [ ] migrations system that works for both
20- [ ] testing: run full test suite against both backends
21- [ ] config option to choose backend (postgres vs sqlite)
22- [ ] document tradeoffs (sqlite for single-user/small, postgres for multi-user/scale)
23
24### Plugin system
25WASM component model plugins. Compile to wasm32-wasip2, sandboxed via wasmtime, capability-gated. Based on zed's extensions.
26
27WIT interface
28- [ ] record hooks before/after create, update, delete
29- [ ] blob hooks before/after upload, validate
30- [ ] xrpc hooks before/after (middleware), custom endpoint handler
31- [ ] firehose hook on_commit
32- [ ] host imports http client, kv store, logging, read records
33
34wasmtime host
35- [ ] engine with epoch interruption (kill runaway plugins)
36- [ ] plugin manifest (plugin.toml): id, version, capabilities, hooks
37- [ ] capability enforcement at runtime
38- [ ] plugin loader, lifecycle (enable/disable/reload)
39- [ ] resource limits (memory, time)
40- [ ] per-plugin fs sandbox
41
42capabilities
43- [ ] http:fetch with domain allowlist
44- [ ] kv:read, kv:write
45- [ ] record:read, blob:read
46- [ ] xrpc:register
47- [ ] firehose:subscribe
48
49pds-plugin-api (rust), MVP for plugin system
50- [ ] plugin trait with default impls
51- [ ] register_plugin! macro
52- [ ] typed host import wrappers
53- [ ] publish to crates.io
54- [ ] docs + example
55
56pds-plugin-api in golang, nice to have after the fact
57- [ ] wit-bindgen-go bindings
58- [ ] go wrappers
59- [ ] tinygo build instructions
60- [ ] example
61
62@pds/plugin-api in typescript, nice to have after the fact
63- [ ] jco/componentize-js bindings
64- [ ] typeScript types
65- [ ] build tooling
66- [ ] example
67
68example plugins
69- [ ] content filter
70- [ ] webhook notifier
71- [ ] objsto backup mirror
72- [ ] custom lexicon handler
73- [ ] better audit logger
74
75### Misc
76
77migration handle preservation
78- [ ] allow users to keep their existing handle during migration (eg. lewis.moe instead of forcing lewis.newpds.com)
79- [ ] UI option to preserve external handle vs create new pds-subdomain handle
80- [ ] handle the DNS verification flow for external handles during migration
81
82cross-pds delegation
83when a client (eg. tangled.org) tries to log into a delegated account:
84- [ ] client starts oauth flow to delegated account's pds
85- [ ] delegated pds sees account is externally controlled, launches oauth to controller's pds (delegated pds acts as oauth client)
86- [ ] controller authenticates at their own pds
87- [ ] delegated pds verifies controller perms and scope from its local delegation grants
88- [ ] delegated pds issues session to client within the intersection of controller's granted scope and client's requested scope
89
90per-request "act as"
91- [ ] authed as user X, perform action as delegated user Y in single request
92- [ ] approach decision
93 - [ ] option 1: `X-Act-As` header with target did, server verifies delegation grant
94 - [ ] option 2: token exchange (RFC 8693) for short-lived delegated token
95 - [ ] option 3 (lewis fav): extend existing `act` claim to support on-demand minting
96 - [ ] something else?
97
98### Private/encrypted data
99Records only authorized parties can see and decrypt.
100
101research
102- [ ] survey atproto discourse on private data
103- [ ] document bluesky team's likely approach. wait.. are they even gonna do this? whatever
104- [ ] look at matrix/signal for federated e2ee patterns
105
106key management
107- [ ] db schema for encryption keys (user_keys, key_grants, key_rotations)
108- [ ] per-user encryption keypair generation (separate from signing keys)
109- [ ] key derivation scheme (per-collection? per-record? both?)
110- [ ] key storage (encrypted at rest, hsm option?)
111- [ ] rotation and revocation flow
112
113storage layer
114- [ ] encrypted record format (encrypted cbor blob + metadata)
115- [ ] collection-level vs per-record encryption flag
116- [ ] how encrypted records appear in mst (hash of ciphertext? separate tree?)
117- [ ] blob encryption (same keys? separate?)
118
119api surface
120- [ ] xrpc getPublicKey, grantAccess, revokeAccess, listGrants
121- [ ] xrpc getEncryptedRecord (ciphertext for client-side decrypt)
122- [ ] or transparent server-side decrypt if requester has grant?
123- [ ] lexicon for key grant records
124
125sync/federation
126- [ ] how encrypted records appear on firehose (ciphertext? omitted? placeholder?)
127- [ ] pds-to-pds key exchange protocol
128- [ ] appview behavior (can't index without grants)
129- [ ] relay behavior with encrypted commits
130
131client integration
132- [ ] client-side encryption (pds never sees plaintext) vs server-side with trust
133- [ ] key backup/recovery (lose key = lose data)
134
135plugin hooks (once core exists)
136- [ ] on_access_grant_request for custom authorization
137- [ ] on_key_rotation to notify interested parties
138
139---
140
141## Completed
142
143Core 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.
144
145did: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.
146
147OAuth 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.
148
149OAuth 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).
150
151App endpoints: getPreferences, putPreferences, getProfile, getProfiles, getTimeline, getAuthorFeed, getActorLikes, getPostThread, getFeed, registerPush (all with local-first + proxy fallback).
152
153Infrastructure: 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.
154
155Web 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.
156
157Auth: ES256K + HS256 dual support, JTI-only token storage, refresh token family tracking, encrypted signing keys (AES-256-GCM), DPoP replay protection, constant-time comparisons.
158
159Passkeys 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.
160
161App 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.
162
163Account 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.
164
165Migration: OAuth-based inbound migration wizard with PLC token flow, offline restore from CAR file + rotation key for disaster recovery, scheduled automatic backups, standalone repo/blob export, did:web DID document editor for self-service identity management.