A self-hosted household ledger.
0

Configure Feed

Select the types of activity you want to include in your feed.

archive profile-avatars, sync auth spec with avatar requirements

author graham.systems date (Jul 16, 2026, 6:29 PM -0700) commit 72b737bd parent e83174b6 change-id nyyypmsm
+20 -1
openspec/changes/profile-avatars/.openspec.yaml openspec/changes/archive/2026-07-14-profile-avatars/.openspec.yaml
openspec/changes/profile-avatars/design.md openspec/changes/archive/2026-07-14-profile-avatars/design.md
openspec/changes/profile-avatars/proposal.md openspec/changes/archive/2026-07-14-profile-avatars/proposal.md
openspec/changes/profile-avatars/specs/auth/spec.md openspec/changes/archive/2026-07-14-profile-avatars/specs/auth/spec.md
openspec/changes/profile-avatars/tasks.md openspec/changes/archive/2026-07-14-profile-avatars/tasks.md
+20 -1
openspec/specs/auth/spec.md
··· 4 4 TBD - created by archiving change bootstrap-finance-app. Update Purpose after archive. 5 5 ## Requirements 6 6 ### Requirement: ATProto OAuth login 7 - The system SHALL authenticate users via AT Protocol OAuth using handle-based login. The user enters their handle (or DID); the system resolves it, performs the OAuth authorization flow (PAR, PKCE, DPoP) against the user's authorization server, and establishes an application session on success. The system SHALL request only the `atproto` scope and SHALL NOT access the user's PDS data after authentication. 7 + The system SHALL authenticate users via AT Protocol OAuth using handle-based login. The user enters their handle (or DID); the system resolves it, performs the OAuth authorization flow (PAR, PKCE, DPoP) against the user's authorization server, and establishes an application session on success. The system SHALL request only the `atproto` scope and SHALL NOT make authenticated requests to the user's PDS after authentication. Resolving and rendering profile pictures from public ATProto profile data — without using the OAuth session or any application credential — is permitted. 8 8 9 9 #### Scenario: Successful login with allowlisted handle 10 10 - **WHEN** a user whose DID is in the allowlist completes the OAuth flow ··· 53 53 - **WHEN** the server process restarts and a user presents a previously issued valid session cookie 54 54 - **THEN** the session is honored because it is persisted in SQLite 55 55 56 + ### Requirement: Profile picture display 57 + The system SHALL display user profile pictures resolved from public ATProto profile data, keyed by the user's current handle and fetched by the browser without application credentials. Avatars SHALL appear in the navigation user chip alongside the handle, and in categorization provenance displays in place of the handle text, where the handle SHALL be revealed in a popover on hover or keyboard focus and the DID SHALL remain available via an accessible label. When an avatar cannot be loaded or does not exist, the UI SHALL fall back to the textual handle presentation. 58 + 59 + #### Scenario: Nav chip shows avatar 60 + - **WHEN** an authenticated user views any app page 61 + - **THEN** the navigation user chip shows their avatar together with their handle 62 + 63 + #### Scenario: Provenance avatar with popover 64 + - **WHEN** a user hovers over or keyboard-focuses the actor avatar in a transaction's categorization history 65 + - **THEN** a popover reveals the actor's handle, and the DID is exposed via an accessible label 66 + 67 + #### Scenario: Avatar unavailable 68 + - **WHEN** an avatar image fails to load or the actor has no profile picture 69 + - **THEN** the UI renders the actor's handle as text, and no provenance information is lost 70 + 71 + #### Scenario: Server fetches no profile data 72 + - **WHEN** pages containing avatars are rendered 73 + - **THEN** all profile-image requests originate from the browser against public endpoints, and the application server performs no profile-data requests 74 +