mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-10 00:16:59 +00:00
72aac98ff12ee07840ecd0de6fa38fc2c95fc8a5
607
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Vitor PamplonaandGitHub
|
122321cd94 |
Merge pull request #3704 from vitorpamplona/claude/buzz-community-star-add-buttons-knx2ry
Support Buzz stream messages in group chat and improve chat previews |
||
 Claude
|
107ff18366 |
fix(buzz): count all Buzz chat-timeline kinds as a room's last message
Widen the fix beyond the plain stream chat message: every Buzz kind the chat
feed renders as a row — stream messages (40002), system lines (40099), diffs
(40008), and the agent-job (43001-43006) and huddle (48100-48103) lifecycle
events — is `h`-scoped and attaches to the same RelayGroupChannel as a kind-9
via consumeBuzzTimelineEvent. So all of them must count as a room's newest
message and toward its unread dot; leaving them out left the Messages-list
preview stale whenever the newest thing in a channel was one of these.
- Add `Event.isBuzzChatTimelineContent()` (quartz buzz) enumerating exactly the
kinds consumeBuzzTimelineEvent attaches / the chat renders — excluding edits
(folded into their target), canvas, and forum kinds. `isGroupChatContent()`
now ORs it in, so the initial scan, the live additive update, and the unread
dot all agree.
- These kinds carry JSON/diff in `content`, so previewing raw `content` would
dump `{"ephemeral_channel_id":…}`. Extract the in-chat labels into pure
helpers (`buzzSystemMessageText`, `buzzActivityLabel`,
`buzzTimelinePreviewSummary`) so the Messages-list preview shows the same
human-readable summary the chat row shows ("🔊 huddle started", "topic
changed", "⚙ job progress: …", "📄 <file>") instead of raw payload.
- Extend the regression test to cover stream/system/huddle counting and edit/
reaction not counting.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012dtx8Shek4sSAXmHjnNMJF
|
||
|
Claude
|
affc547b0e |
fix(buzz): update Messages-list preview + unread dot for Buzz stream channels
A Buzz stream-channel chat message is a kind-40002 StreamMessageV2Event, not a NIP-C7 kind-9 ChatEvent. It is `h`-scoped and attaches to the same RelayGroupChannel as a kind-9, but `isGroupChatContent()` only recognized ChatEvent/PollEvent/ThreadEvent/CommentEvent, so the Messages-list "newest message" logic (initial scan `newestChatNote` + the live additive `filterRelevantRelayGroupMessages`) and the unread-dot check all skipped it. Result: a Buzz channel's row never reflected its real chat and never updated live as new messages arrived. Include StreamMessageV2Event in `isGroupChatContent()` (the Buzz dialect of NIP-29), fixing the Messages preview and unread dot in one place. Adds a regression test asserting kind-40002 counts as group chat content while a group-scoped reaction does not. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012dtx8Shek4sSAXmHjnNMJF |
||
|
Vitor PamplonaandGitHub
|
b4e8719ee2 |
Merge pull request #3701 from vitorpamplona/claude/nip47-spec-compliance-1c9ook
Add NWC payment notifications and deep-link pairing |
||
|
Claude
|
9789ff61f4 |
fix(nip47): parse space-separated encryption/notification tags; drop accumulating notification subscription
Two issues found in an audit of the NWC changes: 1. (correctness, high) NIP-44 negotiation never triggered against real wallets. The info event carries schemes in a single space-separated tag value (["encryption", "nip44_v2 nip04"]), but encryptionSchemes() returned tag.drop(1) = ["nip44_v2 nip04"], so the nip44_v2 membership check never matched and every request fell back to NIP-04. Split each tag value on whitespace in encryptionSchemes()/notificationTypes() so both the spec's space-separated form and a multi-element tag normalize to individual tokens. Adds NwcInfoEvent tests for the wire format. 2. (performance) NwcPaymentNotificationWatcher subscribed via subscribeAsFlow, which accumulates every event into an ever-growing list and re-emits the whole list per event — wrong for a lifetime subscription (unbounded retention + O(n) rescan per event). Replace with a raw client.subscribe listener (callbackFlow) that emits each event once; reconnect re-delivery is still de-duped by the seen set. Also documents why the watcher keys the account flow on pubkey. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDAAS4ktFbWtRnEVXQsjfs |
||
|
Claude
|
6ce61f0dc8 |
Merge remote-tracking branch 'origin/main' into claude/chat-picture-sending-consistency-qit0pz
# Conflicts: # commons/src/commonMain/kotlin/com/vitorpamplona/amethyst/commons/actions/ConcordActions.kt |
||
|
Claude
|
6f40d997c6 |
feat(minichat): allow sending pictures in thread replies
Every chat composer in Amethyst already had a picture/media attach button (SelectFromGallery) except the minichat "thread" screen — the kind-1111 reply composer opened from the "N replies" chip — which was text-only. This brings it to parity with every other chat. - quartz: ChannelChat.imageReply() — a kind-1111 thread reply carrying encrypted image imeta(s), combining reply()'s NIP-22 pointers with imageMessage()'s ciphertext-URL/imeta handling (+ round-trip test). - commons: ConcordActions.buildChannelImageReply(). - Account.sendMinichatReply() now accepts imetas and routes per backend: Concord sends an encrypted image reply; NIP-28/NIP-29 public chats append the URL to the content and carry a plaintext imeta on the comment; Buzz appends the URL to the stream message content. - Extract toConcordImeta()/toPlainImetas() into a shared UploadImetas.kt so the minichat and Concord composers build imeta the same way. - MinichatScreen: add the SelectFromGallery leading icon + ChatFileUpload dialog, encrypting only when the backend is end-to-end (Concord). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D8FD5xm8nyEKzd8dk9VfT1 |
||
|
Claude
|
c2f6aa9992 |
feat(nip47): add NWC-07 deep-link helper and NIP-44 request opt-in
Add Nip47DeepLink for the NWC-07 same-device pairing convention: build/parse the `nostrnwc://connect` request (client -> wallet) and the callback URI that returns the `nostr+walletconnect://` pairing code (wallet -> client). All params are URI-encoded per the spec. Also thread `useNip44` through LnZapPaymentRequestEvent.create so pay_invoice requests can opt into NIP-44, matching createRequest. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDAAS4ktFbWtRnEVXQsjfs |
||
|
Claude
|
92915c9b17 |
fix(concord): use the dedicated kind-3302 edit, matching Armada's wire format
Verified against the Concord v2 reference client (Soapbox Armada, src/concord-v2/lib/kinds.ts): a chat message edit is a dedicated KIND_EDIT = 3302 rumor, NOT a kind-1010 modification. It names the target with a single `e` tag (no `k` — Armada adds `k` only to deletes), carries the replacement text, and rides the channel/epoch binding. The fold applies only edits authored by the original message's author (latest by CORD-02 §4 send time `created_at*1000 + ms`), non-destructively. The prior commit used kind-1010 TextNoteModificationEvent, which would not interop with Armada. Corrected: - New ConcordChatEditEvent (kind 3302) in quartz, registered in EventFactory; ChannelChat.edit now builds it. orderingMs() honors the `ms` remainder tag. - LocalCache.consume(ConcordChatEditEvent) wires the edit to its target note and invalidates the edits flow; findLatestConcordEditForNote returns the author-matching kind-3302 edits ordered by send time (latest wins). - observeConcordEdit reads that finder instead of the kind-1010 machinery. Send/compose/action-sheet plumbing is unchanged (it routes through ChannelChat.edit). Note: Amethyst does not yet emit the `ms` remainder tag on Concord rumors (a pre-existing, message-wide gap), so its own edits order at one-second granularity; received Armada edits are ordered at full precision. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013HdLnAa4Pa1pFV9FTYVTB6 |
||
|
Claude
|
a5925c16c2 |
feat(concord): let authors edit their own channel messages
Brings feed-post-style edits to Concord chat. A Concord message rumor is a standard kind-9 event, so an edit reuses Amethyst's native kind-1010 TextNoteModificationEvent: a channel/epoch-bound rumor that e-tags the target and carries the replacement text, wrapped and published on the same channel plane as any other Chat Plane rumor. Receivers overlay the newest edit through the existing shared machinery (LocalCache.findLatestModificationForNote), which only applies edits authored by the original message's author, so a member can't rewrite someone else's message. Clients that don't understand kind-1010 keep showing the original text, so it degrades gracefully. - ChannelChat.edit + ConcordActions.buildChannelEdit build/wrap the edit rumor. - Account.editConcordChannelMessage gates to my own kind-9 messages and publishes the wrap (local echo + relays), mirroring reactToConcordMessage so the edit never leaks the private rumor id onto public relays. - The chat bubble overlays the newest edit (RenderConcordEditedNote) with an "(edited)" marker, matching the Buzz kind-40003 edit presentation. - The long-press action sheet offers Edit on my own Concord messages; the composer enters edit mode with an editing banner and publishes the edit on send. The former onWantsToEditBuzz callback is generalized to onWantsToEditChatMessage, shared by the Buzz and Concord surfaces. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013HdLnAa4Pa1pFV9FTYVTB6 |
||
|
Vitor PamplonaandClaude Opus 4.8
|
31acb5037b |
fix(concord): decode the community list even when an entry has a keyless channel
A public channel carries no delivered key, so a writer lists it under an
entry's `channels` with only {id, epoch, name}. `WireChannel.key` was a
required field, so kotlinx.serialization threw MissingFieldException — and
`decodeDocument`'s catch-all turned that one bad channel into an empty list,
silently dropping EVERY joined community from the kind-13302 list (communities
"won't load" at all).
- Default `WireChannel.key = ""` so a keyless (public) channel no longer throws.
- Decode entries one at a time and keep any we still can't parse verbatim in
`ConcordListResidue.unparsedEntries`, re-emitted on write — so one malformed
entry can never wipe the whole list, and a read-modify-write never deletes a
membership this version can't model.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Claude
|
a657a9698d |
fix(buzz): use assertTrue instead of assert in ForumCommentEventTest
Kotlin/Native marks the stdlib `assert()` with `@ExperimentalNativeApi`, so the iOS test target (`compileTestKotlinIosSimulatorArm64`) failed to compile without an opt-in — while JVM/Android were fine. Swap it for `assertTrue` from `kotlin.test`, which needs no opt-in on any target and matches the assertions already used in this file. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J8KBSw6smQRyXLiWHeDsZ8 |
||
|
Claude
|
45d18ab330 |
feat(buzz): resolve kind-20001 collision so BitChat + Buzz presence coexist
Kind 20001 is claimed by both BitChat's GeohashPresenceEvent and Buzz's PresenceUpdateEvent. EventFactory's flat when(kind) could only route one, so Buzz presence never materialized (parsed as a geohash event) in either direction — this was the deferred "EventFactory collision". Disambiguate inside the shared 20001 branch by BitChat's required `g` (geohash) tag: present -> GeohashPresenceEvent, absent -> PresenceUpdateEvent. Verified against the Buzz Rust ground truth (buzz-sdk build_presence_update + the relay's synthesize_presence read form): Buzz presence carries the status in content plus a `status` tag (client) or a `p` tag (relay-synthesized), never a `g` tag, and BitChat presence always carries `g` with empty content. Both inbound parse (EventDeserializer) and outbound signing (EventAssembler) route through this factory, so one guard fixes both. Make it usable, not just parseable: add BuzzPresenceState (process-wide latest online/away/offline per subject, mirroring BuzzTypingState), a PresenceUpdateEvent.subjectPubKey() accessor (the `p` tag or the author), and a LocalCache branch that records presence and drops the ephemeral without storing it. Tests cover both Buzz wire shapes, the BitChat guard, and latest-wins. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J8KBSw6smQRyXLiWHeDsZ8 |
||
|
Claude
|
f8bb53848b | Merge remote-tracking branch 'origin/main' into claude/buzz-repo-analysis-7k54ga | ||
|
Claude
|
bb39fb29fc |
feat(buzz): invite-link redemption + live-interop fixes (amy)
Validated against the production relay wss://amethyst.communities.buzz.xyz
by joining and running a full DM round-trip. Adds the join primitive and
fixes the interop gaps that live testing surfaced.
- quartz: BuzzInviteLink — parse `https://<host>/invite/<token>` (relay-signed
base64url payload → community/role/expiry). A Buzz invite is NOT a NIP-29
code; it is redeemed over HTTP against the tenant host. Unit-tested with a
real token; rejects the Concord `/invite/<naddr>#…` shape (no collision).
- cli: `amy buzz join <invite-url>` — the real 3-step claim: GET /api/join-policy,
POST /api/invites/accept-policy, then NIP-98-signed POST /api/invites/claim.
Proven live (status: joined, role: member).
- cli: Context.publish now authenticates-then-retries on an `auth-required`
relay (warm the connection with a pendingOnAuthRequired REQ, then re-publish)
— the write path had no NIP-42 handling, so every Buzz write was rejected.
- cli: Buzz reads (dm list / read / console / personas) use the auth-aware
drain (pendingOnAuthRequired).
- cli: `dm open` surfaces the relay's synchronous OK `response:{channel_id}` —
the authoritative DM channel id (the relay assigns it; it is not polled).
- cli: `dm list` rewritten to the relay's actual discovery — kind-44100
member-added notifications (#p=me) filtered to the kind-40099 `dm_created`
channels. The deployed relay does NOT emit kind-41001.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J8KBSw6smQRyXLiWHeDsZ8
|
||
|
Claude
|
d571bee394 |
fix(store): rank multi-filter search REQs + harden merge from branch audit
Two-reviewer adversarial audit of the branch found no correctness/data-loss/ crash bugs. This closes one gap and applies three robustness fixes: - Multi-filter search ordering: a REQ whose filters all carry a search term (e.g. the client's search-across-kinds) was created_at-ordered via the union path. Now relevance-ordered — unionSubqueriesIfNeeded(projectRank) projects rank per branch, UNION ALL + GROUP BY row_id MIN(rank) dedups across branches keeping the best score. Only when every branch is a search branch; mixed search/non-search REQs and count/delete unions stay as before. - prepareAuthorStreams/prepareTagStreams build cursors via buildStreams, which closes already-prepared statements if a later prepare throws (was: stranded checked-out, un-reset handles holding read locks in the pooled connection). - Stream counts computed as Long so authors×kinds / values×kinds can't overflow Int back into the eligible band and route a huge fan-out into the merge. - Renamed CachedStatement.finalize() -> finalizeStatement(): a no-arg finalize() is the JVM Object.finalize, risking a GC double-close of the native handle. Tests: multi-filter search relevance + cross-branch dedup + count parity; existing merge/cache/search suites green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XqGuBuSUsRudGerPqDuoKA |
||
|
Claude
|
c79b795477 |
fix(buzz): address adversarial review findings (channel-swap, verified marks, engram tombstone)
Three-reviewer pass over the branch. Fixes, most-severe first: HIGH — channel-instance swap froze open screens. The subclass-upgrade design replaced a group's RelayGroupChannel with a Buzz-typed instance on dialect discovery, but screens/feeds/composers capture the instance for life, so all of them kept rendering the orphan (frozen feed; composer stuck on kind 9). Removed BuzzWorkspaceChannel entirely; RelayGroupChannel is a single stable type again. Buzz-only overlay state (edit + canvas) now lives in BuzzWorkspaceStates, a registry keyed by the channel UUID — dialect discovery no longer touches object identity. The swap also silently dropped all relay-signed state (name, members, admin status, pins, threads) and demoted the confirmed host; gone with the swap. HIGH — wrong thread-root got messages relay-rejected AFTER the draft was destroyed. A reply to a direct reply derived root=parent (buzzThreadRoot null on a collapsed reply), which Buzz's ancestry validator rejects. Fallback is now buzzThreadRoot() ?: buzzThreadReply() ?: parent.id. Also: minichat (kind 1111) replies in Buzz channels are relay-rejected, so they're gated off for Buzz relays. HIGH — pre-create defeated stray-redirect and marked the dialect off unverified input. consumeBuzzTimelineEvent no longer pre-creates the channel; attachment goes through the shared NIP-29 path (with its stray protection), and the dialect is marked only off a VERIFIED event (markBuzzIfVerified) — a hostile relay can no longer flip what the composer sends. MEDIUM — engram tombstone divergence: a memory body missing `value` decoded as a null tombstone (a deletion) where Buzz rejects it. `value` is now required (no default); added NIP-AE slug-grammar validation. Pinned by test. MEDIUM — unbounded edit overlay: pruneOldMessagesChannel now prunes overlay entries for reaped messages. Overlay is keyed by channel id so own offline edits (null relay) apply too. Also: 40002 inbound reply linkage in computeReplyTo (we emit thread markers we couldn't read); registered-but-unhandled 40901/40902/48001 now consumed; unconditional Buzz-kind widening (kills the history-cursor-skip); stream mention dedup; persona empty-list omission for content-hash parity; thread-marker positional guard; edit-note-loading blank-row fallback. Full amethyst unit suite + affected quartz suites green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J8KBSw6smQRyXLiWHeDsZ8 |
||
|
Claude
|
de114d1621 |
fix(store): relevance-order search+tag queries too, not just tag-free search
Any filter with a search term must be relevance-ranked (NIP-50), but only the tag-free shape (makeSimpleSearch) was — search + a tag fell through to the row-id-subquery path (prepareRowIDSubQueries/makeQueryIn), which ordered by created_at. prepareRowIDSubQueries gains projectRank: when a search filter joins event_fts, it also projects the bm25 score as a `rank` column and cuts its LIMIT by rank (most relevant, not newest); makeQueryIn(orderByRank) then presents the joined result by that rank, created_at DESC as tie-break. Off by default, so count/delete/union/negentropy (which must stay single-column and unranked) are untouched. toSql wires it on whenever the filter carries a search term. SearchRelevanceOrderTest adds a tag-scoped case (stronger-but-older outranks weaker-but-newer, wrong-tag and non-matching excluded, limit cuts by score). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XqGuBuSUsRudGerPqDuoKA |
||
|
Claude
|
8e7b1b63be |
fix(store): order NIP-50 search by relevance (bm25), not created_at
NIP-50: results are returned "in descending order by quality of search result ... not by the usual .created_at", with the limit applied after the score. The store sorted search by created_at DESC (pre-existing), so it returned the newest matches rather than the best ones. makeSimpleSearch (the search [+ kinds/authors/since/until] + limit shape) now orders by FTS5 bm25 (ORDER BY event_fts.rank, created_at DESC as a tie-break). Verified bm25 rank works on the contentless table through the join, and that a stronger-but-older match outranks a weaker-but-newer one. The rarer search+specific-tag shape and the negentropy snapshot still sort by created_at (the row-id subquery can't carry rank; negentropy is a sync set) — documented. This is a correctness fix, not a scaling one: bm25 scores every match, so search latency still grows with the match set. Tests: SearchRelevanceOrderTest, Fts5CapabilityProbe.bm25RankWorksOnContentlessTableInAJoin; QueryAssemblerTest search plans updated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XqGuBuSUsRudGerPqDuoKA |
||
|
Claude
|
e6a8f80826 |
fix(store): drop non-compliant rowid search ordering, keep FTS delete/size wins
searchOrderByRowId ordered NIP-50 search by the FTS rowid (ingestion order) to get O(limit) search, but NIP-01's limit requires the newest events by created_at. Once ingestion diverges from created_at (any historical sync) that returns the wrong events under a limit — a spec violation — so the flag, its QueryBuilder branch, and its test are removed. Search stays created_at-ordered; corpus-independent search is an external-engine job, not this index. The contentless + rowid=row_id schema stays for the reasons that don't touch ordering: the delete trigger now seeks by rowid (O(log n)) instead of scanning by an FTS column (O(n)) — measured ~78× faster at 8k rows and widening, on a path every deletion hits — and the index is smaller. Benchmark reframed around the delete win and the honest (unchanged) search cost; plan doc updated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XqGuBuSUsRudGerPqDuoKA |
||
|
Claude
|
c7670a52d4 |
perf(store): scale NIP-50 search and tag-watcher queries with corpus size
The scale-curve report showed the SQLite store degrading with corpus size on NIP-50 search (~18×) and the large-IN tag watcher, while point reads stayed flat. Three read/size changes (write path and index set unchanged): - FTS: rebuild event_fts as a contentless FTS5 table (content='', contentless_delete=1) keyed by rowid = event_headers.row_id. Drops the stored content copy (smaller index); external-content can't hold the derived indexable text, so contentless is the correct primitive. Adds an opt-in searchOrderByRowId strategy flag: ORDER BY event_fts.rowid DESC early-terminates (O(limit), corpus-independent) at the cost of ingestion-order results — flat ~0.22 ms vs created_at's 4.26 ms at 200k (~19×). reindexAll ends with 'optimize'; the periodic optimize() folds in a bounded segment 'merge'. DB version 4->5 with a drop-and-rebuild migration. - MergeQueryExecutor: extend the k-way merge to the tag path (kinds + #e IN [hundreds] + limit), one cursor per (value[,kind]) stream heap-merged to the limit, deduping events that carry several queried values. O(limit + streams) instead of collecting all matches and sorting. - StatementCachingConnection: pool multiple handles per SQL so the merge's many concurrent identical-SQL cursors all hit the cache (previously only the first did) and repeated polls reuse their per-stream statements. Tests: contentless migration (real v4 DB upgrade), rowid-order search, tag merge correctness (incl. cross-stream dedup), statement pool, FTS5 capability probe, and an FTS search-scaling benchmark. Plan in quartz/plans/2026-07-21-sqlite-query-scaling.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XqGuBuSUsRudGerPqDuoKA |
||
|
Claude
|
f5d22ce720 |
feat(quartz): implement the full Buzz-custom protocol surface (~77 event kinds)
Adds Quartz-native models for the entire block/buzz custom kind space, each as an idiomatic per-NIP package (Event + KIND companion + tags/ + write-DSL + read accessors, mirroring nip88Polls) and registered in EventFactory. Standard NIP-29/34/51/42/43 kinds Buzz reuses are left to their existing Quartz classes. Coverage: - Agent identity: Persona 30175, Team 30176, Managed Agent 30177, Agent Profile 10100 - Agent telemetry (encrypted): Observer 24200, Engram 30174 (HMAC d-tag derivation pinned to Buzz reference vectors), Turn Metric 44200 (prior commit) - Workspace overlays: Reminders 30300, Push Lease 30350, DM Visibility 30622, Workspace Profile 9033, Identity Archival 9035/9036/8002/8003/13535, Channel Window 39005/39006, relay admin 9030-9032, moderation 9040-9044, 42000 - Messaging/collab: stream 40002-40100 (+sidecars), DMs 41001/41010-41012, jobs 43001-43006, forum 45001-45003, workflow 30620/46001-46031, notifications 44100/44101, presence 20001/20002, huddles 24810/48100-48106, pairing 24134, audit 48001, media 49001, read-state (NIP-RS helpers on 30078) All schemas confirmed against the authoritative Rust in a local block/buzz checkout (buzz-core / buzz-sdk / buzz-relay), not the outdated prose NIPs. Kinds only reserved-but-unbuilt in Buzz (jobs, workflow lifecycle, some stream/sidecar/audit kinds) are modeled tolerantly and flagged in KDoc + README. Kind conflicts with existing Amethyst classes are implemented but deliberately NOT registered in EventFactory (incumbent keeps dispatch): 9041 (GoalEvent), 20001 (GeohashPresenceEvent), 39005 (GroupPinnedEvent), plus 49001 (Buzz marks it non-wire) and 30078 read-state (reuses AppSpecificDataEvent). 156 Buzz tests pass; full quartz jvmTest green (no regressions). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J8KBSw6smQRyXLiWHeDsZ8 |
||
|
Claude
|
a54c808763 |
feat(quartz): add Buzz protocol kind registry + Owner Attestation (NIP-OA)
Introduces a top-level `buzz` package modelling the block/buzz protocol in
Quartz. Buzz is a NIP-29-family relay-group workspace (relay is the source of
truth, plaintext content, server-side membership) that layers an agent +
workspace vocabulary on top, so this package models only the Buzz-custom
extensions and reuses the existing NIP-29/34/51/42/43 classes for the standard
kinds.
- BuzzKinds: the full kind registry mirroring buzz-core `kind.rs`, annotated
with where each standard kind already lives in Quartz.
- Owner Attestation (NIP-OA): the owner-signed `auth` tag that lets agents act
as first-class members. Commitment = SHA-256("nostr:agent-auth:" + agent +
":" + conditions), BIP-340 Schnorr-signed by the owner; conditions grammar
(kind=/created_at</created_at>, canonical decimals, u16/u32 bounds) matches
buzz-sdk `nip_oa.rs` exactly.
- Tests pin Buzz's own published known-answer vector as a cross-implementation
compliance check: our preimage hash equals Buzz's SHA-256 and our verifier
accepts Buzz's reference signature.
Confirmed against the authoritative Rust (buzz-core/buzz-sdk), not the prose
NIP drafts, which lag the implementation.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J8KBSw6smQRyXLiWHeDsZ8
|
||
|
Claude
|
5f5356c0fe |
fix: complete PR clone multi-value, git-status auth spoofing, CLI robustness
Addresses review findings from a merge-time audit. - **Complete the headline multi-value `clone` fix for PRs** (was applied only to kind:30617). GitPullRequestEvent (1618) and GitPullRequestUpdateEvent (1619) carry `clone` with the same spec shape but still emitted repeated single-value tags and read only the first value — so the exact interop bug this branch set out to kill was still live for PRs, both directions (ngit keeps only the last repeated tag; we lost every URL after the first from ngit's multi-value tag). Now both emit one multi-value `["clone", …]` tag and read both forms. Verified on the wire + GitNip34InteropTest + CLI harness (40 checks). - **Android git-status spoofing (GitStatusIndex)**: newest-status-wins with no author check meant anyone could publish a kind-1632 and make someone else's issue render closed. Now filter statuses to the repository owner (from the status's own `a` tag), declared maintainers (from the cached announcement), or the target item's author — matching NIP-34 and the CLI's derivation. Pre-existing on main; this branch made the CLI/Android divergence visible. - **CLI robustness**: `git comment`/`git patch` no longer block forever reading stdin on an interactive TTY (amy is non-interactive — error instead). The local `git` subprocesses in `git init`/`git apply` now drain stdout on a side thread under a bounded `waitFor` + `destroyForcibly`, so a wedged git can't hang the CLI. Left as a follow-up (cosmetic): GitBrowseCommands.candidateUrls duplicates GitRepositoryBrowserViewModel's — worth lifting to shared code, not worth the cross-module coupling here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UKMaNoK5M2PQKCAxhxWzPr |
||
|
Claude
|
1a77c95531 |
fix(quartz): NIP-34 wire-format interop with ngit (clone/web, issue p, plain r)
Verified Amethyst's NIP-34 events byte-for-byte against the ngit reference implementation (DanConwayDev/ngit-cli) and the spec, and fixed three real interop divergences in quartz — so ngit/gitworkshop and Amethyst read each other's git repos, issues, patches, and PRs without losing data. - Repository announcement `clone`/`web` were emitted as REPEATED single-value tags (`["clone", a]`, `["clone", b]`). The spec and ngit use ONE multi-value tag (`["clone", a, b]`), and ngit's parser keeps only the LAST of repeated known tags — so multi-URL repos silently lost every URL but one in both directions. Now emitted as a single multi-value tag; `clones()`/`webs()` read BOTH the spec form and the legacy repeated form, so old events still parse. (`relays`/`maintainers` were already correct multi-value tags.) - Issues (kind 1621) were missing the `["p", <repo-owner>]` tag that patches and PRs already include — a maintainer watching `#p` wouldn't see them. The builder now adds it (fixes both the CLI and the Android issue-creation path, which both passed an empty notify list). - Patch / PR / PR-update `r` tags carried the `"euc"` marker (`["r", commit, "euc"]`). Per the spec and ngit that marker belongs only on the kind-30617 announcement; other `r` tags are plain `["r", commit]`. A `#r` filter matches either shape, so this is a spec-compliance/byte-parity fix. `alt` (NIP-31) tags are intentionally still omitted — quartz treats the generic alt client-hint as deprecated, and ngit/gitworkshop parse the structured tags, so it isn't required for interop. Adds `GitNip34InteropTest` (5 cases: multi-value write, tolerant read of both forms, issue p-tag, plain patch r-tag) and 4 wire-format assertions to the CLI git harness (37 offline). No regressions in the nip34 or Search suites. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UKMaNoK5M2PQKCAxhxWzPr |
||
|
Vitor PamplonaandClaude Opus 4.8
|
a0ab3ec66d |
Merge PR: feat(compose): resolve NIP-05 (incl. Namecoin .bit) in the @-mention popover
Merges nostr proposal b07eb505 into main:
- feat(nip05): add Nip05Id.parseLenient for mention/text rendering
- feat(compose): wire NIP-05 popover mentions to nostr:nprofile1…
Also closes duplicate proposal 4b90b41f, which pointed at the same commits.
Beyond the feature, this replaces the unvalidated `Nip05Id("_", prefix)` raw
constructor in UserSuggestionState with `Nip05Id.parseLenient(prefix)`, closing
a hole where a typed mention such as `evil.com#x.bit` produced a GET to an
arbitrary host via `toUserUrl()`'s bare interpolation.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Vitor PamplonaandClaude Opus 4.8
|
8913af7a79 |
fix(concord)!: enforce CORD-04 rank gating on the Banlist fold
Closes the privilege escalation: any BAN holder could ban the authorities above
them — including the owner — because the Banlist gate checked only the BAN bit.
Once banned, a member loses all authority (`hasPermission` is `!isBanned && ..`)
and honest clients drop their events, so a single edition from the most junior
moderator permanently silenced every admin above them.
CORD-04 §3 requires the rank half: "One hard rule binds every action: the actor
must hold the required bit and strictly outrank its target — equal cannot act on
equal (an admin cannot ban a peer admin)", restated as §5 step 3. Only §4, which
defines the Banlist, states the bit half alone — which is why both this client
and Armada shipped the same rank-blind gate.
§3 is stated per TARGET while the Banlist is one whole-list document, so it is
enforced as a DELTA rule: an edition may only add or remove npubs its signer
strictly outranks, judged against the roster settled behind it; the owner is
never a valid target (position 0 is "supreme and unremovable"); and entries the
signer may not act on are IGNORED rather than rejecting the edition, so one bad
entry cannot discard the bulk-ban §4 recommends as the collision remedy, and a
rogue cannot grief the list by forcing rejections.
ConcordModeration.currentBanned now reads the honored banlist through the
resolver instead of decoding the raw head. Besides picking up the fork healing
it was missing, this closes a laundering path: our own next ban/unban would
otherwise re-publish an entry our fold refuses, under our signature.
BREAKING (consensus): Armada has not shipped this rule, so banlists can differ
between clients until it does — we now ignore a ban Armada honors whenever the
signer did not outrank the target. Shipping the spec-conformant behaviour was
judged better than continuing to honor an escalation. Write-up to send upstream
is docs/concord-banlist-rank-conformance.md.
The three tests added in
|
||
|
Vitor PamplonaandClaude Opus 4.8
|
0ae6bc6698 |
fix(concord): rank-gate the Ban and Remove affordances
Ban/Remove were offered to any BAN holder against any non-owner, ignoring rank — unlike the role picker, which routes through `canActOn`. Both the Members roster and the message-level path (`Account.concordBanTarget`, the chokepoint for the quick-action menu, the note dropdown, the note action sections and the chat action sheet) now require `canActOn(me, target, BAN)`. This is NOT the no-op it first looked like. The premise that the fold would drop such a ban is wrong, and a test proves it: BANLIST is a single whole-list entity, so `authorizedHeads`/`banGate` gate on the author's BAN bit alone and never rank-check the list's *contents*. A rank-5 moderator's ban of a rank-1 admin is therefore ACCEPTED by every client, and the admin then loses every permission, since `hasPermission` is `!isBanned && ..`. It is privilege escalation, not a silent no-op. The fold is deliberately left alone. Armada has the identical gap — its `banlistGate` calls the rank-blind `isAuthorized(.., Permissions.BAN)` while its role path uses the rank-aware `canActOnPosition` — so rank-gating our fold would make us ignore bans every other client honors, splitting the banlist across clients. Closing it needs a spec change, like CORD-05. Refusing to AUTHOR such a ban restricts only what we write, never what we accept, so it cannot diverge consensus. Three `@Ignore`-d tests in AuthorityResolverTest state the fold-level invariant and currently fail by design; two companions assert the gate does not over-correct (a moderator still bans a plain member; the owner still bans anyone). Un-ignore the first three when the spec closes the gap. The owner short-circuits the check rather than going through `canActOn`, which begins at `hasPermission` and is false while banned — since a rogue BAN holder *can* currently banlist the owner, routing them through it would let them be locked out of moderating their own community. Device-verified on Amethyst QA Concord as Dr. Edo (QA Lead, rank 2): Bob (Admin, rank 1) now offers only the disabled "Roles… / You don't outrank this member" where Ban and Remove used to be enabled, while the Helper (rank 5) still offers Roles…, Ban and Remove. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Vitor PamplonaandClaude Opus 4.8
|
62440748a7 |
fix(concord): stop a rejected edition orphaning the honest ones after it
An unauthorized control edition in the middle of an entity's chain
permanently froze that entity. Observed on device for a member's GRANT:
v0 owner (grant mods)
v1 owner (grant admins) <- fold stopped here, forever
v2 MIDTIER (escalation, correctly rejected)
v3,v4,v5 owner orphaned, unreachable
`AuthorityResolver` filtered unauthorized editions out BEFORE calling
`EditionFold.foldEntity`, and the walk only advances when the next
version cites the current head's hash. Removing v2 severed the chain, so
every honest edition above it was lost. Any member could permanently
freeze any member's role assignment — including the owner's ability to
change it — with a single event, recoverable only by a Refounding. It
predates the recent rank gates (verified with a zero-role identity); the
gates only widen which editions can poison.
Armada does not have this bug, and its approach settles the design.
Reading its control-plane fold (read for semantics only — Armada is
AGPLv3, Amethyst is MIT, no code taken): the chain walk runs over the
UNFILTERED set, producing an ordered candidate list — chain-verified head
first, then every remaining edition version-descending — and authority is
applied AFTERWARDS, per candidate, picking the first admissible one. A
rejected edition is skipped during the ascending admissibility walk
without truncating it. For the chain above, Armada picks v5.
So the fix is not to filter later but to gate later: `EditionFold` gains
candidate-based gated folding, and the resolver and community state now
gate per candidate instead of pre-filtering the pool. Authority checks
themselves are unchanged — only WHEN they run moved. Applied to ROLE,
GRANT, BANLIST, CHANNEL, METADATA and the authorized-head map.
The writer had to be fixed too, for a sharper reason than expected. With
an ungated `headOf`, a rogue banlist edition at the tip is read as
current state, so the owner's next ban REPUBLISHES THE ROGUE'S CONTENT
UNDER THE OWNER'S SIGNATURE — an unauthorized empty banlist laundered
into an owner-signed one the moment the owner bans anyone else. Tolerant
reading cannot heal that, because the resulting edition is genuinely
authorized. `ConcordModeration.headOf` now folds the authority-gated
heads, and `owner` is a REQUIRED parameter rather than defaulted, since a
silently-wrong default here is a consensus footgun.
Banlist healing is preserved with one necessary change: the ancestry walk
now runs over the full pool rather than the authorized subset. Ancestry is
structural — walking only authorized editions stops at the rejected one
and misreads genuine ancestors as concurrent forks, resurrecting bans an
unban had cleared.
Six regression tests, each verified to fail without the fix. Two process
notes worth recording: the first "without the fix" run reported BUILD
SUCCESSFUL because Gradle served a stale up-to-date `jvmTest` — trusting
it would have meant concluding the tests were worthless. And the
forged-edition test initially passed both ways because the forgery's
content coincided with the honest outcome; it was rewritten so the
mid-chain arm genuinely discriminates.
The rank-gate, rogue-higher-version, floor and rollback tests all pass
unchanged.
Known gap: `headOf` gates through the per-kind permission map, which is
coarser than the resolver's rank gates, so the writer can still pick a
head the reader rejects when an in-permission but out-of-rank edition
sits at the tip. Tolerant reading makes that benign, but it is not an
exact reader/writer match; tightening it needs the resolver to expose
per-entity heads.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Vitor PamplonaandClaude Opus 4.8
|
73d59a29bf |
fix(nip46): gate identity reads on pairing; make decrypt consent informed
Two problems in the remote signer, both about a client getting something
without the user meaningfully agreeing to it.
**`get_public_key` and `get_relays` answered anyone.** Every other method
runs through `ifAuthorized`; these did not, and nothing required a prior
successful `connect`. The service decrypts and dispatches any well-formed
kind-24133 envelope, so anyone holding the `bunker://` URI — pasted into a
malicious app, posted for support, leaked in a screenshot — could ask it
which account it belongs to, without the secret and without connecting.
`get_relays` additionally handed over the inbox relay set. That defeated
the transport/identity split, which otherwise works: the relay-visible
traffic really is anonymous, since the p-tag and author are a transport
key and the payload is NIP-44.
Both now require the client to be paired. The authorizer interface gains
`isPaired` with NO default, so a future authorizer has to state its own
rule rather than silently inheriting "everyone is paired".
`ping` is deliberately left open. It reveals nothing the caller does not
already have — a signer is alive at a pubkey they hold — and first-party
behaviour could be confirmed but third-party clients that ping before
connecting could not be ruled out. Breaking a legitimate handshake to
close a minor oracle is a bad trade. The choice is pinned by a test that
also asserts the pairing check is never consulted, so it stays deliberate
rather than drifting back by accident.
**Decrypt consent showed nothing at all.** The bridge populated the
content preview and raw data only for signing requests, so a decrypt
request produced an empty preview block — no ciphertext, no counterparty,
not even the "Show event" toggle — leaving "AppName wants to read your
private messages" with *Allow always* as the primary button. Meanwhile
the coordinator documented the opposite: "Amethyst decrypts first, then
asks permission to expose." That was never implemented.
Now:
- The counterparty is resolved and shown, so the prompt reads "…read your
private messages **with Alice**". It never degrades to nothing —
cached name, else a shortened npub. Knowing *whose* messages is a
categorically different decision.
- The message is decrypted BEFORE prompting and the plaintext is the
preview, as documented. It is a local operation and nothing is exposed
until approval. Failure, blank and hang all collapse to an explanatory
string under a timeout, so the dialog is never empty and cannot stall.
- A narrower grant is offered ALONGSIDE the broad one, not instead of it:
`DecryptFrom(counterparty)` keyed `decrypt:<hex>` next to `Decrypt`.
The dialog's primary button becomes "Always allow for Alice" with the
broad option demoted. Because the ledger stores an opaque op key, no
persisted decision migrates and the storage format is untouched.
Scoping decrypt per counterparty *instead* would have been worse than
the bug: a DM client would prompt once per conversation, training users
to approve everything. A narrow option beside the broad one gives
granularity without the prompt explosion.
Also fixes a latent bug found on the way: `AllowForSession` recorded the
*requested* op rather than the *granted* one, which would have widened a
narrow session grant back to broad.
Verified by three sabotage passes; the tests that stayed green under them
are the intended negative guards. One existing test asserted the buggy
behaviour outright ("public reads are never gated") and was rewritten.
Not done: the batched consent sheet still records the broad op for
"remember" — offering the narrow choice per row there is a UX design
question, not a mechanical change.
Needs a device check before release: the decrypt preview runs the account
signer before consent. That is free for a local key, but an account backed
by an external NIP-55 signer (Amber) may show Amber's own prompt ahead of
Amethyst's.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Vitor PamplonaandClaude Opus 4.8
|
5c23f8490d |
fix(concord): stop destroying other clients' data in the community list
The private community list (kind 13302) is documented as wire-compatible with Armada's `communityList.ts`, whose entry type ends in `[k: string]: unknown` — unknown keys are part of the contract, and `ConcordJson`'s own KDoc says shapes are "deliberately client-extensible (CORD-03/04)". But `ignoreUnknownKeys = true` plus closed `@Serializable` DTOs meant decode dropped every unmodelled key and encode never restored it, so **every Amethyst write of a user's list silently stripped fields another client had written**, across every community in it. Already proven, not hypothetical: `JoinMaterialWire` declared a `refounder` field that nothing in the repo reads, so it was parsed and destroyed on the first write. We only avoided destroying Armada's `invite_ref`/`excluded_at_epoch` because those were modelled hours ago, for stranded recovery — the anchor recovery depends on would otherwise have been deleted on every write. Each wire DTO's compiler-generated serializer is now wrapped in a shared `JsonTransformingSerializer` that lifts unknown keys into a bag on decode and merges them back on encode, with declared fields winning on conflict. The known-key set is read from the descriptor rather than hand-listed, so it cannot drift from the DTO. Preserved at the document root, each entry, the `current` join material, each channel, each held_root, each tombstone, and everything nested inside `seed`. `refounder`'s typed field is removed so it round-trips generically. Two further data-loss bugs surfaced while doing it, both fixed here: - **`seed` was overwritten with `current` on every write**, destroying the immutable join anchor. It is now kept and re-emitted verbatim as a raw JsonObject — we never hydrate from it while `current` exists, so we have no business rewriting it, and keeping it raw preserves everything nested inside for free. - **`tombstones` were re-encoded as an empty list**, which did not just lose their unknown keys: it RESURRECTED communities another client had deliberately removed. They are now carried verbatim. Verified by four separate sabotage passes (no-op the transform, re-mint `seed`, restore the empty-tombstone write, flip the merge order); each new test fails under at least one, and every mechanism is covered. Control-plane re-serialization was audited too and is NOT fixed here: `compactControlPlane` is safe (it re-wraps the original seal verbatim), but the user-facing *edit* paths — `editConcordMetadata`, `grant`, and the channel edits — construct fresh typed entities and re-encode, so they drop extensions the same way. Fixing those means merging into the head edition's raw JsonObject on each edit path, which is a larger change than this should carry. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Vitor PamplonaandClaude Opus 4.8
|
f8d8a2b135 |
feat(concord): recover a membership stranded by a Refounding
A rotation carries only (newRoot, newEpoch, rotator) — no recipient list — so a member simply left out of the recipient set receives nothing and is stranded on the dead epoch forever while everyone else moves on. It applies to any member, the owner included, and cannot be prevented on the receive side: there is nothing to check. Armada does not prevent it either; it recovers, and this follows the same approach. The invite link a membership was joined through is stored as the anchor, and when that link later resolves to a HIGHER epoch, the membership merges forward. Uses Armada's exact wire names so the kind-13302 list stays compatible in both directions: `invite_ref` (the link in bare `<naddr>#<fragment>` form, host-stripped so a link minted by a different front end reduces to the same anchor) and `excluded_at_epoch`, both at the entry level. Details that decide whether this works at all: - `merge()` lets a higher-epoch winner inherit the loser's `invite_ref` when it has none. Without it a two-device merge silently discards the only anchor recovery has, disarming it permanently. - `adoptConcordRoot` carries `invite_ref`/`excluded_at_epoch` through a rotation; it rebuilt the entry field-by-field and would have dropped them at exactly the moment they matter. - Merging forward preserves `heldRoots`, so prior-epoch history the member legitimately holds is not lost by recovering. - Recovery requires a strictly higher epoch and a matching community id, so it is monotonic and cannot be steered by an unrelated bundle. Hooked onto the existing Concord revision tick immediately after `drainConcordRekeys`, because the two are halves of one problem: a rotation you were included in arrives as a rekey to drain, one you were excluded from produces no message at all and can only be found by polling the link. Rate-limited to 15 minutes per community; an idle tick costs a map lookup. Only a Live bundle recovers — an expired or revoked link is not a missed rotation. Verified by mutating the production code eight ways (dropping the anchor, dropping heldRoots, dropping the epoch comparison, renaming the wire keys, removing the merge inheritance, breaking bare-form parsing) and confirming each produced exactly the expected failures. Two things this surfaced, both left for their own change: - Our parser does NOT round-trip unknown JSON keys — `ignoreUnknownKeys` plus closed DTOs — while Armada's format ends in `[k: string]: unknown`. So every Amethyst write of the community list silently strips fields Armada added that we do not model; it already discards the `refounder` field we parse but never re-emit. That is live interop data loss, caused by us, independent of this work. - `mergeForward` keeps the entry's existing private-channel grants rather than adopting the bundle's, matching what `joinConcordViaInvite` already does. If a recovered member should pick up new-epoch grants, both paths need it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Vitor PamplonaandClaude Opus 4.8
|
fac1bf5b5d |
feat(concord): refuse Control-Plane rollbacks with a version floor
`ConcordRefounding.compactControlPlane` re-wraps one edition per entity when a community rotates epoch, and the ROTATOR chooses which one survives. The receiving side had no memory: `refold()` folds only the wraps at the current epoch's Control-Plane address and discards the prior epoch's buffer, and `EditionFold` accepts whatever it is handed (its no-genesis fallback anchors at the lowest version present). So a rotator could publish only version 1 of a chain and omit version 2 — restoring a revoked role, clearing a banlist, reverting metadata. Every signature is genuine; this is rollback by omission, not forgery. Adds a per-entity floor: the version AND hash last successfully folded. - **No floor (fresh joiner)** — unchanged: genesis anchor, else the lowest-version edition as the legitimate compaction bootstrap. - **With a floor** — the walk is anchored AT the floor: the offered set must contain the exact edition already folded (version and hash; a same-version sibling is a fork, not our chain), then walks up. A head below the floor is structurally unreachable. - **Gap** (the floor edition is absent) — refuse, and keep the known head. Refusing by *retaining* matters here: this fold is recomputed from scratch each time, so letting an entity vanish would itself be a rollback — a dropped banlist is an unban. The floor needs no new persistence. It is derived from `heldRoots`, the rotated-out access roots already persisted in the NIP-44 self-encrypted kind-13302 list: the session derives each prior epoch's Control-Plane address from them, folds oldest-first, and takes the resulting heads as the floor. That survives both a process restart and the session rebuild `ConcordSessionRegistry.sync` performs at exactly the moment of a Refounding — which would have destroyed any in-session floor. If the old planes are not served, there is no floor and behaviour is as before. Floors are built from AUTHORITY-GATED heads, not raw ones. Without that, any ex-member still holding a rotated-out root could mint a high-version edition on the old plane and freeze the entity for every honest client — a denial of service this change would otherwise have introduced. Covered by a test. Verified by disabling both enforcement points: 7 of 12 quartz tests and the end-to-end commons test fail, and the ones that still pass are exactly the non-regression cases (fresh joiner, honest compaction, pass-through without floors). Known limit: `AuthorityResolver.resolve` folds authorized SUBSETS of the edition pool and does not carry floors itself; gating happens at the pool level before the resolver sees anything. Sound, but connectivity checked on the full set is a weaker precondition than on each subset — passing floors into the resolver's three folds is worth a follow-up. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Vitor PamplonaandClaude Opus 4.8
|
0f53eb09a2 |
fix(concord): gate revokes on target rank; drop the owner rotation refusal
Reviewed the previous commit's authority changes against Armada
(gitlab.com/soapbox-pub/armada), the reference Concord client we interop
with. Read for its rules only — Armada is AGPLv3 and Amethyst is MIT, so
no code was taken from it.
It confirmed the role rank gate (Armada checks both directions too: the
author must outrank the position being minted AND the standing position
being replaced) and the banlist check on rotation. It also showed one of
our rules was wrong and one gate was missing.
**Removes the owner's refusal of foreign rotations.** The previous commit
made the owner ignore any rotation it did not author, reasoning that a
BAN-holder could otherwise carry the owner onto a root of their choosing.
Armada does the opposite on purpose — "authority is the roster, never key
possession" — and it is right: an admin legitimately rotating to remove a
spammer would leave the owner alone on the dead epoch, self-inflicting
the strand the rule was meant to prevent, and diverging from the
reference implementation forks communities across clients. The threat is
better answered by the rank gate: with role editions gated, nobody can
escalate themselves to BAN, so BAN-holders are people the owner
deliberately trusted.
**Adds the missing rank gate on grants.** A grant was authorized if the
granter outranked every role it handed out — but a REVOKE carries no role
ids, and `all {}` over an empty list is vacuously true. So any
MANAGE_ROLES holder could strip anyone's roles, the owner's admins
included: promotion was gated, demotion was free. Armada treats a grant
as an action ON the member and requires outranking the target's standing
rank; this now does the same.
Both new tests were verified to fail with the corresponding check
disabled, and each has a companion asserting the legitimate case still
works (an admin can still revoke a moderator beneath it).
Also records what Armada does about exclusion, since we cannot prevent it
receiver-side: it does not try to. A rotation carries no recipient list
there either, so a stranded member instead re-resolves the invite link
they joined through and merges forward to the higher epoch ("stranded
recovery"). Amethyst has no equivalent, so a stranded member stays
stranded — noted at the call site as follow-up work.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Vitor PamplonaandClaude Opus 4.8
|
c9c91a8c98 |
fix(concord): rank-gate role editions and harden rotation authority
Two authority holes, plus the limit that remains. **Role editions had no rank gate.** Grant editions are correctly gated — a granter must hold MANAGE_ROLES *and* strictly outrank every role it hands out. Role editions checked only that the author held MANAGE_ROLES. Nothing stopped an authorized signer editing a role at or above its own rank, including the role it holds itself. So a moderator at position 5 with MANAGE_ROLES could publish one edition on their own role's chain claiming position 1 and every permission bit, then a second demoting the real admins beneath them — reaching full authority over everyone but the owner in two editions. The rogue-higher-version defence added earlier does not cover this: it drops editions from *unauthorized* signers, and this signer is authorized. Role editions are now gated in both directions: an author may not claim a position at or above its own rank, may not touch a role that already sits at or above it, and may not hand a role permission bits it does not hold itself. Deleting keeps only the second rule, so retiring a role beneath you still works. The owner is unaffected. **A banned moderator could still rotate the community.** The rekey receive path authorized the rotator with `effectivePermissions(...)`, which ignores the banlist, rather than `hasPermission(...)`, which excludes banned members. Now uses the latter. **The owner no longer adopts a root someone else minted.** A rotation replaces the community root, so a rotator who *includes* the owner as a recipient hands themselves the keys to the owner's own community — the owner would follow them onto an attacker-chosen epoch. The owner changes epoch only by rotating themselves. **Known limit, documented at the call site.** A rotation carries only (newRoot, newEpoch, rotator) — no recipient list — so a receiver cannot tell who was omitted. A BAN-holder can therefore still evict the owner by leaving them out: everyone else adopts, the owner is stranded on the old epoch. That is not fixable in the receive path; it needs a protocol change (a recipient commitment the receiver can check, or owner co-signing). Tracked for CORD-06. The escalation test was verified to fail with the gate disabled, and a companion test asserts an admin can still edit a role beneath it, so the gate is not merely blocking everything. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Vitor PamplonaandClaude Opus 4.8
|
c8be65a02e |
fix(concord): require consent for invite links, enforce expiry, fold the head
Three fixes to the Concord invite and moderation paths. **Invite deep links redeemed with zero consent.** `ConcordInviteScreen` called `joinConcordViaInvite` from a `LaunchedEffect` on open, and the manifest registers `https://amethyst.social/invite/` as BROWSABLE. So a link on any web page — or a QR code, or a push — silently caused a connection to up to three ATTACKER-CHOSEN relay URLs decoded from the URL fragment (disclosing the user's IP to a third party), a Guestbook JOIN signed by the user's identity published to those relays, and a write to their private community list. No tap, no preview. The screen now opens in an awaiting-consent state and only joins from an explicit Join button. The preview is built entirely from the link itself — base64url and NIP-19 decoding, both pure in-memory — and touches the network for nothing: no relay connection, no signing, no publishing. It shows the relays it would contact so the user can see whom they'd be talking to. The community name lives inside a bundle only those relays can serve, so it is honestly reported as unknown until joining rather than fetched. **Invite expiry was decorative.** `ConcordInviteBundle.isExpired` had no production callers at all — the only ones were in a test — so an expired invite redeemed forever. Expiry is now enforced at `classify`, the choke point every redeem path funnels through, with its own result and message so the user knows to ask for a fresh link. **Moderation read the wrong edition.** `ConcordModeration` used `firstOrNull` over `controlEditions()`, which is in wrap-ARRIVAL order, not the folded head. Once an entity had two or more editions the next one chained off a stale predecessor, forking the chain at an already-used version, and `EditionFold` then resolved the fork by `minByOrNull` on the rumor id — a coin flip. Bans were masked by a down-only healing union; UNBANS and role revocations were not, so they could silently fail to apply. Both call sites now fold to the true head. Regression tests assert the fold-head behaviour under two arrival orders — a single order accidentally puts the head first and passes against the buggy code. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Vitor PamplonaandClaude Opus 4.8
|
5fd8be64fd |
fix(podcast): clamp V4V fee splits so a feed cannot multiply payments
`computeShares` paid each fee recipient `totalMilliSats * split / 100` with no upper bound on `split`, and `split` comes verbatim from a kind-30054 episode event that anyone can publish (`ValueTag.parse` is a bare `fromJson` with no validation). A single `fee:true, split:1000` recipient was therefore paid TEN TIMES the amount the user chose. The `remainder` clamp looked like a safety net but only zeroed the honest recipients; it never touched the fee recipients themselves. Proven by test before fixing: `split:1000` pays 10x, and two fee recipients at 60% each pay 1,200,000 millisats for a 1,000,000 zap. This was reachable in the worst possible place. Streaming V4V pays every minute, automatically, so a modest multiplier stays under a typical NWC budget and simply runs — and the on-screen running total tracks the INTENDED amount, so it reads "100 sats" while 1,000 left the wallet, while the streaming error handler suppresses the toast. The ordinary zap button reroutes through the same path for any note carrying a value block, so it was not limited to the streaming toggle. Fees are a percentage off the top, so each is now clamped to 100% and the cumulative total to the remaining budget: the payout can never exceed what the user chose. The existing test asserted the right invariant (`sum <= total`) but only ever ran it on well-formed input, which is why this survived. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Vitor PamplonaandGitHub
|
035c50421c |
Merge pull request #3642 from vitorpamplona/claude/cli-module-deep-review-le4dsj
amy CLI overhaul: exit-code/JSON contract v1, per-command help, contract tests, docs, and thin-layer extractions |
||
|
Claude
|
4efb2cca98 |
fix(quartz,cli): audit fixes — bounded drains, no event loss, honest verdicts, false-reject traps
Adversarial audit of the PR's own changes (8 finder angles, verified before fixing). Quartz core: - fetchAll-family drains get a wall-clock ceiling (maxTotalMs, default 10x the idle window, delay()-watchdog: cancellable and virtual-time testable). The pure idle window was unbounded when a relay trickled events forever — sandboxed napplet queries, set -e fetches, and marmot await stuck inside one drain. Streaming relays still finish. - The suspending onEvent hook no longer runs inside a cancellable timeout scope (an expiring window could cancel verifyAndStore mid-write and silently drop a received event); the timeout is armed only when the channels are dry (no per-message timeout-job churn). - fetchAll is a projection over fetchAllWithHooks: fixes its unsynchronized events/seenIds mutation from concurrent socket threads and deletes the duplicate loop + per-event activity channel. - publishAndConfirmDetailed regains its only-responders contract (synthetic no-response entries no longer render as 'relay rejected your message' in app callers); results built by pure associateWith; shared failure-reason constants + PublishResult.isTransportFailure. - NIP-65 mutations: split read+write r-tags for the same URL now merge to BOTH instead of last-wins dropping a facet (+ test). - TcpProber's 128-thread pool drains after 60s idle. CLI: - publishGuard: all-transport failure exits 124 as timeout; rejected/1 is reserved for an actual OK-false answer. - --help anywhere in argv is hoisted centrally; 'amy notes post "x" --help' prints usage instead of publishing. - rejectUnknown false-reject traps fixed: geochat --no-fetch behind an early return, and 13 elvis-alias short-circuit sites read eagerly. - Aliases load once per Context and only match name-shaped inputs (no shadowing a real npub/NIP-05/hex); stderr color requires a positively-known terminal (TERM sniff polluted captured logs). - Relay-CSV strictness unified on RawEventSupport.relayFlag (post, graperank publish/followers/register no longer silently drop malformed URLs); Args.timeoutMs(+OrNull) replaces 27 hand-rolled conversions, all strict; offer/debit --timeout > 3600 rejected with a 'looks like milliseconds' hint; NPub.create idiom; stale jq .id in the marmot reactions harness; printUsage drift (offer pay --with, profile --clink-offer, search --kind). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CP4kfLCa3wWtE8Khy21Pkj |
||
|
Claude
|
962d1706dc |
fix(quartz): fetchAll-family timeouts are idle windows, not absolute deadlines
The fetchAll/fetchAllWithHooks accessories wrapped their whole collection loop in one withTimeoutOrNull, so a relay actively streaming a large backlog was cropped mid-delivery the moment the absolute deadline hit — even though the loop already has proper terminal conditions (per-relay EOSE / CLOSED / cannot-connect) and the timeout's only real job is stall detection. timeoutMs now measures the delta since the LAST message: every event or terminal signal resets the window (fetchAll gains a conflated activity ping so event progress is visible to its wait loop), and only a full window of silence ends the fetch early. fetchFirst/count keep absolute waits (single-response — idle and absolute coincide), and subscribe's duration timeout stays absolute by design (a live stream has no terminal state). Since the pages/pool helpers delegate to fetchAll, pagination inherits the semantics. This also changes app-side callers of these accessories — in their favor: the timeout only ever fired on slow relays, exactly when cropping loses data. New commonTest suite pins the behavior: a relay emitting every 200ms under a 300ms window streams to completion (10/10 events); a stall ends one window after the last message, not after the start; EOSE still returns immediately. CLI docs reworded (--timeout = idle window). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CP4kfLCa3wWtE8Khy21Pkj |
||
|
Vitor PamplonaandGitHub
|
43704772a7 |
Merge pull request #3641 from vitorpamplona/claude/nip29-group-load-perf-wz4yca
NIP-29 group chat: split state (always-on) from content (paginated) |
||
|
Vitor PamplonaandClaude Opus 4.8
|
e66550091d |
fix(relay): send an unresolvable host straight to the long backoff
A relay whose domain no longer exists (lapsed registration, decommissioned host) was treated like a busy relay: the backoff doubled from 1s and spent about ten dials climbing to the ceiling it was always going to reach. An HTTP upgrade rejection already jumps straight there; a name that does not resolve deserves the same. Matching is on the exception type rather than the message because the message is localized and platform-specific — Android says `Unable to resolve host "x"`, JVM on macOS says `nodename nor servname provided, or not known` — while the class name is stable. That is why onCannotConnect appends it in the first place. Neither message ends with "Host unreachable", so the existing check never caught DNS failures. Being this eager is only safe because the verdict is cheap to revisit: a DNS answer is a property of the network, not of the relay (a captive portal or a filtering resolver forges NXDOMAIN), and both a network-identity change and a transport change now clear the backoff outright. The test pins that round trip, not just the classification. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Vitor PamplonaandClaude Opus 4.8
|
b1b6190d2f |
fix(relay): forgive reconnect backoff when the network or transport changes
A relay's reconnect backoff was process-global and network-blind: the delay earned on one network was still being served out on the next. The only reset signal was OkHttpClient reference identity, which is rebuilt off the metered bit, so it fired for wifi<->cellular and nothing else. Wifi A -> wifi B, a VPN coming up, a captive portal clearing, and metered-wifi -> cellular all left every relay parked on a penalty earned against a network the device had left — up to five minutes of silence on a network that might reach the relay instantly. The transient Off that would have reset things is swallowed by the 200ms debounce in ConnectivityFlow, so it never rescued those cases. Key the decision on ConnectivityStatus.Active.networkId instead, which is the same signal SurgeDns already uses to stale its cache, and treat a genuine network change as a full pool rebuild: every socket is bound to an interface that no longer carries traffic, and needsToReconnect() cannot see that because it only compares the proxy and the timeouts. Also treat a Tor policy flip as a transport change. Flipping a Tor toggle while Tor is already up leaves both OkHttpClient references identical, so a relay whose transport just changed kept waiting out a backoff earned on the other transport. Only TorRelaySettings is compared, not the relay sets that TorRelayEvaluation also carries — those churn while an account's relay lists load (observed firing three times in one cold start), and forgiving the whole pool every time any list updates is far more damage than it repairs. Adds IRelayClient.resetBackoff() (default no-op, so the existing fakes and BleNostrClient are unaffected) rather than reusing ignoreRetryDelays, which only skips the gate for a single attempt and still doubles the stored delay — a relay that failed that one dial came back worse off than before. INostrClient.resetBackoff() is deliberately separate from reconnect(): the latter debounces, so folding this into a coalescing command would let a later request silently drop the reset. The decision table moves into RelayProxyClientConnector.apply() so it can be exercised directly, without a debounce and a shared StateFlow in the way. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Claude
|
7ea6920679 |
refactor(nip65): move read/write-marker merge semantics from the CLI into quartz
The kind:10002 facet-merge rules (adding a write marker to a read-only relay promotes it to BOTH; removing one facet of BOTH demotes to the other; removing the last facet drops the relay) lived as private helpers in the CLI's RelayCommands. Any frontend that edits a NIP-65 list needs them, so they now live in quartz nip65RelayList as AdvertisedRelayListMutations (applyFacet/addFacet/removeFacet/setFacet) with commonTest coverage. Behavior unchanged; the CLI rewires to the shared functions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CP4kfLCa3wWtE8Khy21Pkj |
||
|
Claude
|
9bc436b0c2 |
feat(blossom): BUD-07 confirm-then-pay for paid-server mirroring
Adds a confirm-then-pay flow so a 402 from a paid Blossom server can be settled from the app instead of only being reported. - quartz: BlossomPaymentProof (settled Cashu token / lightning preimage) with the X-Cashu / X-Lightning retry headers; BlossomClient.mirror accepts a proof. - BlossomPaymentHandler (Android): pays the challenge's BOLT-11 invoice via the account's existing NIP-47 (NWC) wallet and returns the preimage — it never handles keys or funds itself, only drives the connected wallet. Decodes the invoice amount for display. - Blob manager: a mirror that hits 402 now raises a payment prompt; a dialog shows the amount and, on confirm, pays and retries the mirror, then continues with the remaining servers. Cancel leaves the blob unmirrored. Cashu-only servers and the composer upload path still surface a clear message; auto-settlement there can reuse this handler next. Not yet validated against a live paid server. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ckbnz1N94W1hnNC9xpsCNP |
||
|
Claude
|
bb03cd2a3c |
feat(blossom): full-client protocol support across quartz, commons, CLI and Android
Extends Blossom support toward a full client on both the CLI and the mobile app. Quartz (protocol): - BlossomAuthorizationEvent: add t=media auth (BUD-05) and optional BUD-11 `server` domain scoping on every factory (stops replayable upload/delete tokens) - BlossomServerUrl: mirror/media/list/report path builders, BUD-06 preflight and BUD-07 payment header constants, and a lowercase bare-domain helper - BlossomUploadResult: parse `ox` (BUD-05 original hash) and `nip94` (BUD-08) - BlossomPaymentRequired: BUD-07 402 challenge model (Cashu/Lightning) - BlossomReport: BUD-09 kind-1984 blob report reusing NIP-56 tag builders Commons (shared JVM client, now in jvmAndroid so Android shares it too): - BlossomClient gains mirror (BUD-04), list/delete (BUD-02), media (BUD-05), preflight/has (BUD-06/01), report (BUD-09) and typed 402 handling - BlossomAuth: media/list/delete passthroughs with server scoping CLI (first-class): - amy blossom now routes all HTTP through the shared client and adds `media` and `report` verbs; auth tokens are scoped to --server Android (first-class): - uploads mirror to the user's other Blossom servers (BUD-04) best-effort - new "Manage stored files" screen: per-server presence matrix (BUD-02 list + BUD-01 HEAD), delete, mirror-to-missing, and report actions Tests: quartz URL/auth/descriptor/payment parsing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ckbnz1N94W1hnNC9xpsCNP |
||
|
Vitor PamplonaandGitHub
|
cd5060e5dc |
Merge pull request #3626 from vitorpamplona/claude/graperank-algorithm-improvements-oco5ue
Add follower crawl and trusted-follower metrics to GrapeRank |
||
|
Vitor PamplonaandGitHub
|
60d492e2bc |
Merge pull request #3619 from vitorpamplona/claude/nip-84-tag-rendering-0o9owh
NIP-84: Support W3C TextQuoteSelector for highlight context |
||
|
Claude
|
db586e30d3 |
feat: render NIP-84 highlights from web highlighter clients
Web-based highlighter clients publish kind:9802 highlights with W3C Web Annotation selectors (textquoteselector / textpositionselector / rangeselector) instead of a NIP-84 `context` tag. These were previously ignored, so the highlight rendered without its surrounding paragraph and the "jump to page" link couldn't disambiguate repeated quotes. - Parse the W3C textquoteselector into TextQuoteSelectorTag (exact/prefix/ suffix; a "-" or empty exact is treated as a placeholder since the quote lives in .content). - HighlightEvent.contextOrReconstructed() prefers an explicit `context` tag and otherwise rebuilds the paragraph from prefix + content + suffix, so the in-context bolding still works. - Build a disambiguated Text Fragment URL (`#:~:text=prefix-,exact,-suffix`) from the selector's prefix/suffix so the source link scrolls to the correct occurrence. The position/range selectors are left unparsed; they only matter for an in-app live-page re-highlighter, which we don't have. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Di4UurD9SQGrpScX7uy2Kh |
||
|
Vitor PamplonaandGitHub
|
3254b90b19 |
Merge pull request #3618 from vitorpamplona/claude/amy-nip46-bunker-concord-epoch-diag
fix(nip46): remote-signer pubKey is the user identity + amy Concord epoch tooling |