chore(api): remove User.prvkey field + thread-through helpers (Q1.2 Option b) #84
Merged
padreug
merged 1 commit from 2026-06-03 16:33:49 +00:00
chore/remove-user-prvkey-field into dev
1 commit
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 9a300c1679 |
chore(api): remove User.prvkey field + thread-through helpers (Q1.2 Option b)
Atomic phase-1 final per design-questions Q1.2 Option (b) and the 2026-05-29T00:30Z architecture-decisions lock-in. Removing the prvkey?: string field from the User interface flips the type system into the pressure mechanism that forces phase-2 to start: every remaining bucket-B sign-site (chat / forum / nostr-feed / activities-bookmarks/RSVP / market / tasks) now fails vue-tsc until it migrates to signEventViaLnbits() against POST /api/v1/auth/sign-event (aiolabs/lnbits PR #29, deployed on aio-demo). Changes: - src/lib/api/lnbits.ts: - Drop `prvkey?: string` from User interface. - getCurrentUser(): /auth/nostr/me used to merge prvkey alongside pubkey; post-cascade the endpoint returns only the pubkey. Updated the comment + cleaned the merge object. - src/modules/base/auth/auth-service.ts: - updateProfile() no longer threads `prvkey` through the merge. Server-side PATCH /auth publishes kind-0 via the signer per 869f67c3; the webapp doesn't keep prvkey at all. - src/modules/nostr-feed/components/NostrFeed.vue + src/modules/nostr-feed/components/ScheduledEventCard.vue: - Repoint the `ScheduledEvent` type import from the deleted `../services/ScheduledEventService` to `@/modules/tasks/services/TaskService`. Trivial post-#81-merge cleanup that fell through the dedup PR; same file exports the same interface. vue-tsc --noEmit fails with 8 errors after this commit, all TS2339 "Property 'prvkey' does not exist". The failing sites are exactly the bucket-B targets the design doc enumerates as phase-2 migration work: | Failing site | Bucket B kind | |-----------------------------------------------|---------------| | activities/composables/useBookmarks.ts:92,113 | kind 10003 (NIP-51 bookmarks) | | activities/composables/useRSVP.ts:153,187 | kind 31925 (NIP-52 RSVP) | | base/services/NostrTransportService.ts:100,112| kind 21000 (NIP-44 v2 RPC envelope) | | market/composables/useMarket.ts:455 | NIP-44 gift-wrap (kind 1059) unwrap | | nostr-feed/components/NostrFeed.vue:408 | kind 5 (deletion of own post) | NOT caught by vue-tsc but still bucket-B (BaseService injection pattern types `this.authService` as `any`, so optional chaining bypasses the type check): - chat/services/chat-service.ts:341,511,714 - forum/services/SubmissionService.ts:755,1167 - nostr-feed/services/SubmissionService.ts:769,1226 - nostr-feed/components/NoteComposer.vue:306 - nostr-feed/components/RideshareComposer.vue:423 - tasks/services/TaskService.ts:507,562,616 Those sites will runtime-fail (prvkey is undefined from the API post-cascade) but won't surface at compile time. Phase 2's per-module migration (Q5.2) catches them as each module flips. The webapp WILL NOT BUILD CLEANLY after this PR merges to dev until phase 2 lands. That's the intended trade-off per Q5.1 + Q1.2; the broken-build interval is the design-intended pressure mechanism to start phase 2. server-deploy's webapp-demo flake.lock bump will fail until phase 2 lands; demo will stay on the pre-PR-#84 webapp during that interval. Refs: - log:2026-05-29T00:30Z (consolidated decisions; Q1.2 Option (b) + Q5.1 risk: demo gap acceptable) - log:2026-05-29T17:30Z (lnbits confirming this PR stays atomic-after-the-two-bucket-A PRs) - ~/dev/coordination/webapp-design-questions.md Q1.2 + Q5.1 - Parent initiative: aiolabs/lnbits#9 (signer abstraction / bunker) - Sibling PRs (stacked base→head): #82 → #83 → this Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
