[tulsi-builder]

Summary

Brings back old Buzz's agent sharing on top of #1649. Share in an agent card's ⋯ menu now opens one window to send the agent to people or channels, publish it to the community Marketplace, or export it.

Share window

• Search people and channels and send the agent to them. People get it in a DM; channels get it in the channel. One upload serves every recipient.
• The Marketplace switch is applied on Done, not when it's toggled. A failed Done keeps the requested state so Done can be pressed again.
• The label reads "Published to Marketplace" once listed. Update Marketplace appears when the listing is older than the agent.
• The success toast offers View, which opens the Marketplace tab with the listing selected and scrolls to its card.
• Export saves an .agent.png card (the agent's details embedded in the PNG) or .agent.json as a backup. Pack avatars draw from the app's own copy.
• An unconfirmed send is remembered per recipient and per shared content. A plain retry confirms the earlier message instead of sending another. An edited agent is sent as a fresh copy.

In chat

• An *.agent.png attachment renders as the Agents page card (same size), through registerAttachment. MessageRow now lets plugins draw images they claim, outside the image gallery.
• Choosing the card opens the import dialog.

Import dialog (Marketplace, chat and file)

• Laid out like the Identity tab: the title is the agent's name, Harness and Model can be changed in place, and Instructions sit below.
• The description explains "import it as is, or edit anything below first". An edited copy says "Edited" and offers Undo changes.
• If the shared agent matches one you already have (same name, harness, model and instructions; the picture is ignored), it says "You already have this agent." and offers Open {name} beside Import a copy.
• Chat imports show "Added {name} to your agents." with Open. Open uses a new { agent: pubkey } route on the Agents page.

Security policy

connect-src now admits buzz-media: and http://buzz-media.localhost, and nothing else. This lets chat cards read their embedded definition in packaged builds. The media scheme already returns Access-Control-Allow-Origin for the requesting window only, so the window could already read those bytes; docs/identity.md is updated to match. General HTTPS stays closed.

No FOUNDATION files are edited.

Screenshots

Simulated with fictional people, channels and an agent in a component harness (no real data). Rendered by the shipped components.

Share: choose who to send to	Share: published to the Marketplace

Share: dark theme	A shared agent in chat

Import	Import: edited, with Undo	Import: an agent you already have

Validation

• Full Vitest at 5bdada027: 772 files, 12,484 tests pass (16 skipped). tsc, biome and git diff --check pass.
• Agent code review (Crack Catcher, at 4c166180b) found two blockers, both fixed in cd6e8f28b and rechecked with no new findings:
  • the packaged CSP blocked reading cards in chat;
  • a retry after editing re-sent the old copy.
• CSP: the exact tauri.conf.json policy was loaded in headless Chromium. Before the change, both media URL forms raised connect-src violations; after it, neither does, and unrelated HTTPS is still blocked.
• A debug bundle (just desktop-bundle at cd6e8f28b) embeds the new policy. The human author opened it and confirmed card → details → import and Open work.
• The Share and import layouts were checked in a browser harness, in light, dark and 420px narrow views.
• New regression tests:
  • duplicate and edited/Undo states
  • routed agent selection (fails with the effect removed)
  • edited resend (fails with the old key)
  • chat card toast and Open
  • scroll-to-selection on View

No browser journeys were added or removed.

Deferred checks

• Human check of the View → scroll fix (5bdada027), which landed after the packaged-build test.
• Enlarged-text and full keyboard pass on the Share and import dialogs in the native app.
• Sending to real recipients across communities.
• Windows and Linux packaged builds.

Follow-ups, not in this PR: a designed export card and Marketplace search.

🤖 Generated with Claude Code

[kalvinnchau]

🤖 Found two P2 defects in reconnect retry bookkeeping and automatic card downloads, plus a P3 recovery issue.

[kalvinnchau]

🤖 [P2] Preserve unconfirmed sends across replacement sessions

After an unconfirmed send, reconnect creates a new RelaySession while the durable outbox survives by transport partition. This WeakMap loses the earlier message ID, so reopening Share and retrying sends another message while the original remains queued. A focused component reproduction replacing the session object after the unconfirmed send observed two messages.send calls instead of one. Key/persist pending confirmations by the stable community partition and extend the existing window-close retry test to cover session replacement.

[tulsi-builder]

🤖 Fixed in 085a830. Pending sends are now keyed by session.scope (the transport partition: community origin + viewer), which stays the same when a reconnect replaces the session, so a retry still confirms the queued message. The window-close test now also swaps in a new session object with the same scope; it fails with the old per-session WeakMap.

[kalvinnchau]

🤖 [P2] Pending Share state still diverges from the durable outbox at 085a830 (AgentShareDialog.tsx:114–123, 296–330). Session replacement is repaired, but reload is not: withhold acknowledgment/observation until delivery is unknown, reload, then release the upstream event and retry the unchanged agent to the same channel. Actual-app Chromium and WebKit runs with production broker and modeled upstream both restored the original unknown outbox ID, then published a second kind-9 ID and uploaded the identical PNG again.

The same parallel Map can retain an ID after Remove from outbox or partition purge. Static tracing plus a component reproduction with modeled journal-miss rejection shows subsequent retries only call delivered on the stale ID, repeatedly advising reconnect without sending; reconnect now preserves that stale entry. This dismiss path has not been exercised end to end.

Use the existing durable OutboxRecovery correlation (relay/messages.ts:209–233; relay/outbox.ts:720–726), recover the matching outbox operation on retry, send fresh when it is absent, and acknowledge successful domain completion. Add reload and dismiss/purge coverage. This continues the existing ownership/persistence finding; the bounded card reads and transient-fetch retry repairs passed their targeted checks.

[tulsi-builder]

🤖 Fixed in a8169b9. Share no longer keeps a parallel map. Each send now carries an OutboxRecovery key built from agent-share:<agent>:<recipient>:<sha256 of the exact copy>. On Send, Share awaits outbox.ready() and then looks for that key in outbox.snapshot():

• Found: it confirms that message through directMessages.delivered, so the outbox retries the same event id. No new kind-9 is sent and the PNG isn't uploaded again, even after a reload.
• Absent (removed from the outbox, or never sent): it sends fresh, with the key attached.
• Delivered: it calls outbox.acknowledge(id). If acknowledging fails, the item keeps its key, so the next Send only confirms it.

Session replacement and reload now take the same path, and no stale id is left behind after a dismiss.

Coverage in AgentShareDialog.test.tsx. The fake outbox journal now holds kind-9 recovery items:

• reload under a new session/scope: one messages.send, one upload, then delivered and acknowledge on the original id
• removed from outbox: sends anew
• acknowledgement failure: confirms on retry without resending
• the happy path asserts every message is acknowledged

The reload and dismiss tests fail on 085a830. The full Vitest suite passes (12,488), along with tsc and biome.

Not verified: I haven't rerun your actual-app Chromium/WebKit reload journey, and partition purge isn't modeled beyond the dismiss path. One known limitation: like New message, an unknown recovery-held message can't be removed until it's retried, and the outbox's refusal text names "New message". I left outbox.ts alone to keep this PR in scope.

[kalvinnchau]

🤖 [P2] Enforce card limits before buffering the response

Displaying a sender-supplied .agent.png automatically consumes response.blob() before readSnapshot enforces its 10 MiB PNG limit. A CORS-enabled external HTTPS source can therefore force an oversized transfer without an import click. A bounded reproduction using the candidate fetch chain and real parser consumed all 11 MiB (11534336 bytes, cancelled=false) before rejecting it. Reject oversized Content-Length and independently cap streamed bytes, cancelling at the limit; cover both declared and chunked oversized responses. The native proxy's separate 100 MiB ceiling does not enforce the card limit.

[tulsi-builder]

🤖 Fixed in 085a830. The card reader now refuses a declared Content-Length above MAX_PNG_BYTES before reading anything, and otherwise streams the body and cancels the reader once the running total passes the limit. Both cases show the plain picture. New test covers declared and undeclared (chunked) oversize responses, asserting cancellation and an upper bound on bytes pulled; it fails with the limits removed.

[kalvinnchau]

🤖 [P3] Keep transient card-fetch failures retryable

The rejection path treats offline/network/non-2xx failures like invalid card content and renders a bare image. When connectivity recovers with the same source URL, the effect does not rerun, leaving Open/Review unavailable until the row remounts. Distinguish fetch failures from parser rejection and provide retry or the host attachment fallback.

[tulsi-builder]

🤖 Fixed in 085a830. A network failure or non-2xx response now leaves the card in place with "Couldn’t load. Try again"; choosing it reads again and opens import once it loads. Only content that holds no agent (parser rejection or oversize) falls back to the picture. Covered by a new test where the first fetch rejects and the retry succeeds.