@awebai/pi 0.1.15 → 0.1.16

package/dist/index.js

@@ -5904,6 +5904,42 @@ function escapeJSON3(s) {
   return result;
 }
 
+// ../channel-core/dist/local_aw.js
+import { execFile } from "node:child_process";
+import { promisify } from "node:util";
+var execFileAsync = promisify(execFile);
+function createLocalAWDecryptProvider(options) {
+  const awCommand = options.awCommand || process.env.AW_BIN || "aw";
+  return {
+    async mailMessage(messageID) {
+      const id = messageID.trim();
+      if (!id)
+        return null;
+      const { stdout } = await execFileAsync(awCommand, ["mail", "show", "--message-id", id, "--json"], { cwd: options.workdir, timeout: 15e3, maxBuffer: 1024 * 1024 });
+      const payload = parseJSONOutput(stdout);
+      return (payload.messages || []).find((msg) => msg.message_id === id) || null;
+    },
+    async chatMessage(sessionID, messageID) {
+      const session = sessionID.trim();
+      const id = messageID.trim();
+      if (!session || !id)
+        return null;
+      const { stdout } = await execFileAsync(awCommand, ["chat", "history", "--session-id", session, "--message-id", id, "--limit", "1", "--json"], { cwd: options.workdir, timeout: 15e3, maxBuffer: 1024 * 1024 });
+      const payload = parseJSONOutput(stdout);
+      return (payload.messages || []).find((msg) => msg.message_id === id) || null;
+    }
+  };
+}
+function parseJSONOutput(stdout) {
+  const trimmed = stdout.trim();
+  if (!trimmed)
+    throw new Error("aw returned empty JSON output");
+  const start = trimmed.indexOf("{");
+  if (start < 0)
+    throw new Error("aw JSON output did not contain an object");
+  return JSON.parse(trimmed.slice(start));
+}
+
 // ../channel-core/dist/channel.js
 import { dirname as dirname2, join as join2 } from "node:path";
 import { homedir } from "node:os";
@@ -6003,11 +6039,12 @@ function createChannelClient(config) {
 async function startChannelLoop(options) {
   const dispatched = /* @__PURE__ */ new Set();
   const deliveryStore = options.deliveryStore || await DeliveryStore.load(DEFAULT_DELIVERY_STORE_PATH);
+  const localDecrypt = options.localDecrypt || (options.workdir ? createLocalAWDecryptProvider({ workdir: options.workdir, awCommand: options.awCommand }) : void 0);
   const log = options.log || (() => {
   });
   for await (const event of streamAgentEvents(options.client, options.signal)) {
     try {
-      await dispatchAgentEvent({ ...options, deliveryStore }, dispatched, event);
+      await dispatchAgentEvent({ ...options, deliveryStore, localDecrypt }, dispatched, event);
       pruneDispatched(dispatched);
     } catch (err2) {
       log(`[aw-channel] dispatch error: ${err2}`);
@@ -6089,6 +6126,16 @@ async function dispatchMailEvent(options, dispatched, event) {
       continue;
     }
     const from = senderDisplayAddress(msg.from_alias, msg.from_address);
+    const decrypt = await resolveMailForDelivery(options, msg);
+    if (!decrypt.ok) {
+      await options.onAwakening({
+        kind: "mail",
+        content: "",
+        meta: encryptedDeliveryFailureMeta("mail", from, msg.message_id, conversationID, decrypt.error),
+        deliveryIntent: "wake"
+      });
+      continue;
+    }
     const trust = await normalizeMessageTrust(options, msg, msg.from_alias, msg.from_address, msg.to_did, msg.to_stable_id);
     msg.verification_status = trust.status;
     if (trust.stored)
@@ -6138,6 +6185,16 @@ async function dispatchChatEvent(options, dispatched, event) {
       continue;
     }
     const from = senderDisplayAddress(msg.from_agent, msg.from_address);
+    const decrypt = await resolveChatForDelivery(options, event.session_id, msg);
+    if (!decrypt.ok) {
+      await options.onAwakening({
+        kind: "chat",
+        content: "",
+        meta: encryptedDeliveryFailureMeta("chat", from, msg.message_id, conversationID, decrypt.error, event.session_id),
+        deliveryIntent: event.sender_waiting ? "steer" : "wake"
+      });
+      continue;
+    }
     const trust = await normalizeMessageTrust(options, msg, msg.from_agent, msg.from_address, msg.to_did, msg.to_stable_id);
     msg.verification_status = trust.status;
     if (trust.stored)
@@ -6177,6 +6234,58 @@ async function dispatchChatEvent(options, dispatched, event) {
 async function normalizeMessageTrust(options, msg, fromAlias, fromAddress, toDID, toStableID) {
   return options.trust.normalizeTrust(options.pinStore, msg.verification_status, senderTrustAddress(fromAlias, fromAddress), msg.from_did, msg.from_stable_id, toDID, toStableID, msg.rotation_announcement, msg.replacement_announcement, msg.signed_from || fromAddress || fromAlias || "");
 }
+async function resolveMailForDelivery(options, msg) {
+  if (!isEncryptedMessage(msg))
+    return { ok: true };
+  if (!options.localDecrypt?.mailMessage) {
+    return { ok: false, error: "local aw decrypt provider is not configured" };
+  }
+  try {
+    const decrypted = await options.localDecrypt.mailMessage(msg.message_id);
+    if (!decrypted || typeof decrypted.body !== "string") {
+      return { ok: false, error: "local aw did not return decrypted mail body" };
+    }
+    Object.assign(msg, decrypted);
+    return { ok: true };
+  } catch (error) {
+    return { ok: false, error: error instanceof Error ? error.message : String(error) };
+  }
+}
+async function resolveChatForDelivery(options, sessionID, msg) {
+  if (!isEncryptedMessage(msg))
+    return { ok: true };
+  if (!options.localDecrypt?.chatMessage) {
+    return { ok: false, error: "local aw decrypt provider is not configured" };
+  }
+  try {
+    const decrypted = await options.localDecrypt.chatMessage(sessionID, msg.message_id);
+    if (!decrypted || typeof decrypted.body !== "string") {
+      return { ok: false, error: "local aw did not return decrypted chat body" };
+    }
+    Object.assign(msg, decrypted);
+    return { ok: true };
+  } catch (error) {
+    return { ok: false, error: error instanceof Error ? error.message : String(error) };
+  }
+}
+function isEncryptedMessage(msg) {
+  return msg.content_mode === "encrypted_v2" || msg.message_version === 2 || msg.encrypted_envelope !== void 0;
+}
+function encryptedDeliveryFailureMeta(type2, from, messageID, conversationID, error, sessionID) {
+  const meta = {
+    type: type2,
+    from,
+    message_id: messageID,
+    encrypted: "true",
+    decrypted: "false",
+    decrypt_error: error
+  };
+  if (conversationID)
+    meta.conversation_id = conversationID;
+  if (sessionID)
+    meta.session_id = sessionID;
+  return meta;
+}
 function isTrustedVerificationStatus(status) {
   return status === "verified" || status === "verified_custodial";
 }
@@ -6486,6 +6595,7 @@ ${message}`),
         stableID: config.stableID
       },
       signal,
+      workdir: ctx.cwd,
       onAwakening: (awakening) => sendAwakening(pi, awakening),
       log: (message) => {
         if (ctx.hasUI) ctx.ui.notify(message, "warning");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awebai/pi",
-  "version": "0.1.15",
+  "version": "0.1.16",
   "description": "Aweb for Pi: real-time channel awakenings, aw CLI onboarding, and aweb skills.",
   "type": "module",
   "main": "./dist/index.js",

package/skills/aweb-identity/SKILL.md

@@ -67,7 +67,7 @@ The normative E2E contract is `docs/e2e-messaging-contract.md`. Do not invent pr
 
 For local E2E messaging, the self-custodial client needs both identity signing material and local encryption private keys. Back up the active encryption private key and archived encryption private keys with the same seriousness as `.aw/signing.key`: losing archived encryption keys makes historical encrypted messages unrecoverable. AC/aweb cannot recover or decrypt old encrypted messages for support.
 
-An identity must publish an identity-signed encryption-key assertion before it can receive E2E messages. Missing, stale, unsigned, or mismatched encryption-key discovery fails closed; do not retry as plaintext unless the human explicitly chooses the separately named legacy plaintext mode from the final CLI. Service signatures may assert route support, but not recipient encryption-key authority. Local identities omit absent `stable_id`/address fields instead of sending empty strings. In non-interactive runs, stop, report the exact `aw doctor` / command error, and ask the human or coordinator to run the approved key setup, backup, or rotation flow.
+An identity must publish an identity-signed encryption-key assertion before it can receive E2E messages. New self-custodial identity and team-install paths create local encryption key material automatically, including `aw id create`, `aw init`, `aw service init`, `aw id team accept-invite`, `aw id team fetch-cert`, and bootstrap/add-worktree flows. Current aw also creates/publishes the sender's key on the first default-E2E send from an upgraded old worktree. It cannot create keys for a different old recipient; if the recipient has no published key, tell them to upgrade aw/Pi/channel and run `aw id encryption-key setup`, or ask the human whether to send a server-readable upgrade note with `--plaintext`. Missing, stale, unsigned, or mismatched encryption-key discovery fails closed; do not retry as plaintext unless the human explicitly chooses `--plaintext`. Service signatures may assert route support, but not recipient encryption-key authority. Local identities omit absent `stable_id`/address fields instead of sending empty strings. In non-interactive runs, stop, report the exact `aw doctor` / command error, and ask the human or coordinator to run the approved key setup, backup, or rotation flow.
 
 Use the CLI keyring commands for self-custodial E2E readiness:
 
@@ -161,7 +161,7 @@ Interpret failures by what's missing (file references assume a self-custodial CL
 
 - **No `.aw/` in this directory** — there is no workspace here at all. Run `aw init` or move to a directory that has been initialized.
 - **`.aw/signing.key` missing** — workspace exists but has no signing key. Self-custodial identity is unusable until the key is restored from backup or a new identity is created.
-- **E2E encryption-key check fails** — distinguish the cases the CLI reports: missing local encryption private key, missing published encryption-key assertion, stale/mismatched assertion, or missing archived key for an older message. Do not advise plaintext fallback. Capture the exact error, run `aw doctor` when available, and ask the human to restore keys from backup or run `aw id encryption-key setup` / `aw id encryption-key rotate` as appropriate.
+- **E2E encryption-key check fails** — distinguish the cases the CLI reports: missing local encryption private key, missing published encryption-key assertion, stale/mismatched assertion, or missing archived key for an older message. Do not advise plaintext fallback. Capture the exact error, run `aw doctor` when available, and ask the human to restore keys from backup or run `aw id encryption-key setup` / `aw id encryption-key rotate` as appropriate. Use `--plaintext` only when the human explicitly chooses server-readable plaintext.
 - **`.aw/workspace.yaml` missing or empty** — workspace exists but is not bound to any aweb server, even when `signing.key` is present. Re-run `aw init`.
 - **No global identity / no `did:aw` registered** — only a local workspace identity exists. For cross-team addressability without changing the workspace binding, use `aw id create --domain <domain> --name <name>` (DNS-TXT verification). Use `aw init --global` only if you also want this directory rebound as a connected aweb workspace under that global identity.
 - **Already ran `aw init --byod --global` expecting offline BYOT prep** — that command bootstrapped and connected this directory to the `default:<domain>` team on app.aweb.ai (the team created during BYOD onboarding), leaving `.aw/{identity.yaml,signing.key,teams.yaml,workspace.yaml,team-certs/}` populated. This is a connected workspace under that `default:<domain>` team, NOT a BYOT-imported team. To recover, pick one:

package/skills/aweb-messaging/SKILL.md

@@ -12,7 +12,9 @@ It also covers explicit user requests to send mail or chat through aweb.
 
 E2E messaging boundary: for encrypted v2 messages, AC/aweb servers route ciphertext and local clients decrypt before showing or injecting plaintext. Hosted custodial MCP, dashboard-side send/read, and server-side tools are **server-readable hosted messaging**, not E2E. Do not describe hosted custodial/server-side messaging as end-to-end encrypted.
 
-Legacy plaintext boundary: existing plaintext mail/chat remains legacy/server-readable while retained and must not be described as retroactively E2E. If an intended E2E send fails because keys, capability, route support, or version support is missing/stale/mismatched, stop and report the exact failure. Do not resend as plaintext unless the human explicitly chooses the approved legacy plaintext command/flag.
+Legacy plaintext boundary: existing plaintext mail/chat remains legacy/server-readable while retained and must not be described as retroactively E2E. Mail and chat send E2E by default. If an intended E2E send fails because keys, capability, route support, or version support is missing/stale/mismatched, stop and report the exact failure. Do not resend as plaintext unless the human explicitly chooses `--plaintext`.
+
+Mixed-version boundary: old pre-E2E aw/channel/Pi clients may not have published recipient encryption keys yet. A current aw CLI creates/publishes the sender's local encryption key before default-E2E sends, but it cannot create keys for another recipient. If the recipient lacks a key, report that they need to upgrade aw/Pi/channel and publish a key. Use `--plaintext` only for an explicit human-approved server-readable upgrade note.
 
 If the event says to use the aw CLI and the response is not obvious, continue with this skill. For broader work coordination, load `aweb-coordination`. For recipient addressability, inbound-mode policy, team membership, or multi-team identity questions, load `aweb-team-membership`.
 
@@ -77,15 +79,15 @@ aw chat extend-wait <from> "working on it, 2 minutes"
 
 Before replying to a confusing chat, inspect pending/open/history state. Do not use chat for broad FYI updates. Send mail instead.
 
-Encrypted chat is explicit. Use `--e2ee` only when the human or policy asks for E2E chat and every participant has identity-authorized encryption capability:
+Mail and chat are E2E by default. Do not add `--e2ee`; it is a deprecated compatibility no-op. Use `--plaintext` only when the human explicitly asks for server-readable plaintext and policy allows it.
 
 ```bash
-aw chat send-and-wait <alias-or-address> "..." --start-conversation --e2ee
-aw chat send-and-leave <alias-or-address> "..." --e2ee
-aw chat extend-wait <from> "working on it" --e2ee
+aw chat send-and-wait <alias-or-address> "..." --start-conversation
+aw chat send-and-leave <alias-or-address> "..."
+aw chat extend-wait <from> "working on it"
 ```
 
-Read paths such as `aw chat pending`, `aw chat history`, and channel listen/decrypt paths show plaintext only after local decryption. If `--e2ee` fails because a key, capability, route, or version is missing or stale, stop and report the exact error; do not resend as plaintext unless the human explicitly chooses the approved legacy plaintext path.
+Read paths such as `aw chat pending`, `aw chat history`, and channel listen/decrypt paths show plaintext only after local decryption. If the encrypted send fails because a key, capability, route, or version is missing or stale, stop and report the exact error; do not resend as plaintext unless the human explicitly chooses `--plaintext`.
 
 ## Harness surfaces
 
@@ -109,7 +111,7 @@ Harness support differs:
 
 The channel is inbound only. Use `aw mail` or `aw chat` to respond.
 
-For E2E messages, channel/Pi/`aw run` may show plaintext only after local decryption in the user's workspace or client process. Server notifications and SSE payloads should be metadata-only for encrypted content. Recipient E2E capability and encryption keys must be identity-authorized; a service signature can assert route support only. If an event or tool error says an encryption key/capability is missing, stale, or mismatched, fail closed and report the error. Do not silently resend as plaintext.
+For E2E messages, channel/Pi/`aw run` may show plaintext only after local decryption in the user's workspace or client process. Server notifications and SSE payloads should be metadata-only for encrypted content. Recipient E2E capability and encryption keys must be identity-authorized; a service signature can assert route support only. If an event or tool error says an encryption key/capability is missing, stale, or mismatched, fail closed and report the error. Do not silently resend as plaintext. If the local channel/Pi process was upgraded from a pre-E2E version, run `aw id encryption-key setup` in the workspace before expecting it to receive encrypted messages.
 
 ## Control and work awakenings