@adastracomputing/ink 0.2.0 → 0.3.0

package/README.md

@@ -4,7 +4,9 @@
 
 An open protocol for AI agents that need to send each other typed, signed messages on the public web. Built for scheduling, introductions, receipts, and other coordination flows where a user delegates an agent to act on their behalf.
 
-**Status: v0.1, experimental.** Wire formats, trust semantics, and APIs may change without backward-compatible migration before v1.0.
+**Status: experimental; current defined wire version `ink/0.2`.** Wire formats, trust semantics, and APIs may change without backward-compatible migration before v1.0. On npm, `latest` is `0.1.2` and `0.2.0` is published on the `next` tag; senders still emit `ink/0.1` by default unless explicitly configured.
+
+`ink/0.2` is the recommended target for new receiver implementations. It is a backward-compatible minor over `ink/0.1`, changing only the body-signature domain: the neutral `ink/sign` in place of the legacy `tulpa/sign`, selected from the signed `protocol` field. `ink/0.1` remains fully supported: both are major version 0, and conformant major-0 receivers accept either. There is no plan to drop `ink/0.1` within major 0; any future version sunset follows the [compatibility policy](specs/ink-compatibility-policy.md).
 
 | | |
 |---|---|
@@ -23,7 +25,7 @@ An open protocol for AI agents that need to send each other typed, signed messag
 - [Agent-assisted implementation](#agent-assisted-implementation)
 - [Tests](#tests)
 - [Layout](#layout)
-- [What's stable in v0.1](#whats-stable-in-v01)
+- [What's stable](#whats-stable)
 - [Naming](#naming)
 - [Relationship to Tulpa](#relationship-to-tulpa)
 - [Interoperability](#interoperability)
@@ -130,9 +132,9 @@ test/          vitest unit + integration tests
 
 The library runs on any runtime providing standard Web Crypto and `fetch`: Node 24+, Deno, Bun, Cloudflare Workers, browsers. The timestamp freshness window is enforced inside `verifyInkAuth`; nonce single-use is enforced when a `NonceStore` is passed (otherwise `checkReplay` must be called separately). Nonce backing storage and its TTL policy are the integrator's choice.
 
-## What's stable in v0.1
+## What's stable
 
-Reliable to depend on:
+These hold across major version 0 (both `ink/0.1` and `ink/0.2`). Reliable to depend on:
 
 - Envelope structure and signing base
 - Authorization: signed intent plus Agent Card key set

package/dist/crypto/keys.d.ts

@@ -30,13 +30,26 @@ export declare function decodePublicKeyMultibase(multibase: string): Uint8Array;
  * Returns the raw 32-byte public key.
  */
 export declare function decodeEncryptionKeyMultibase(multibase: string): Uint8Array;
+/**
+ * agentId method prefixes that carry the same key-derived identity. Both encode
+ * the identical multibase public key, so they denote the same actor. `tulpa:`
+ * is canonical for emission (see deriveAgentId); `ink:` is an accepted inbound
+ * alias introduced in ink/0.4. Accept both, emit one.
+ */
+export declare const AGENT_ID_KEY_PREFIXES: readonly ["tulpa:", "ink:"];
 /**
  * Derive agent ID from a public key.
- * Format: tulpa:<multibase-encoded-public-key>
+ * Format: tulpa:<multibase-encoded-public-key> (canonical emission).
  */
 export declare function deriveAgentId(publicKey: Uint8Array): string;
 /**
  * Extract the public key from an agent ID.
  * Only used for initial key exchange — after that, always resolve via identity store.
+ *
+ * Accepts either the canonical `tulpa:` prefix or the `ink:` alias (ink/0.4):
+ * both carry the identical multibase key, so a signature made with that key
+ * verifies regardless of which accepted prefix carried it. The prefix is
+ * identity syntax, not signing authority. The multibase tail is decoded the
+ * same way for both, so a malformed tail is rejected identically.
  */
 export declare function extractPublicKeyFromAgentId(agentId: string): Uint8Array;

package/dist/crypto/keys.js

@@ -156,9 +156,16 @@ export function decodeEncryptionKeyMultibase(multibase) {
     }
     return key;
 }
+/**
+ * agentId method prefixes that carry the same key-derived identity. Both encode
+ * the identical multibase public key, so they denote the same actor. `tulpa:`
+ * is canonical for emission (see deriveAgentId); `ink:` is an accepted inbound
+ * alias introduced in ink/0.4. Accept both, emit one.
+ */
+export const AGENT_ID_KEY_PREFIXES = Object.freeze(["tulpa:", "ink:"]);
 /**
  * Derive agent ID from a public key.
- * Format: tulpa:<multibase-encoded-public-key>
+ * Format: tulpa:<multibase-encoded-public-key> (canonical emission).
  */
 export function deriveAgentId(publicKey) {
     return `tulpa:${encodePublicKeyMultibase(publicKey)}`;
@@ -166,13 +173,19 @@ export function deriveAgentId(publicKey) {
 /**
  * Extract the public key from an agent ID.
  * Only used for initial key exchange — after that, always resolve via identity store.
+ *
+ * Accepts either the canonical `tulpa:` prefix or the `ink:` alias (ink/0.4):
+ * both carry the identical multibase key, so a signature made with that key
+ * verifies regardless of which accepted prefix carried it. The prefix is
+ * identity syntax, not signing authority. The multibase tail is decoded the
+ * same way for both, so a malformed tail is rejected identically.
  */
 export function extractPublicKeyFromAgentId(agentId) {
     if (typeof agentId !== "string" || agentId.length === 0 || agentId.length > 512) {
         throw new Error("Invalid agent ID");
     }
-    const prefix = "tulpa:";
-    if (!agentId.startsWith(prefix)) {
+    const prefix = AGENT_ID_KEY_PREFIXES.find((p) => agentId.startsWith(p));
+    if (!prefix) {
         throw new Error("Invalid agent ID format");
     }
     return decodePublicKeyMultibase(agentId.slice(prefix.length));

package/dist/index.d.ts

@@ -1,7 +1,7 @@
 export { signInkMessage, verifyInkSignature, buildSignatureBase, buildAuthHeader, computeMessageHash, computeEventHash, computeAuditMerkleLeafHash, signAuditEvent, verifyAuditEventSignature, signAuditResponse, verifyAuditResponseSignature, verifyAuditEventChain, signAuditQueryResponse, verifyAuditQueryResponseSignature, encryptInkPayload, decryptInkPayload, checkReplay, base64urlEncode, base64urlDecode, hexToBytes, bytesToHex, jcsCanonicalize, MAX_TIMESTAMP_AGE_MS, MAX_FUTURE_TIMESTAMP_MS, } from "./crypto/ink.js";
 export { signMessage, verifyMessage } from "./crypto/sign.js";
 export { verifyInkSignatureWithKeys } from "./crypto/multi-key-verify.js";
-export { generateKeypair, generateEncryptionKeypair, deriveAgentId, encodePublicKeyMultibase, encodeEncryptionKeyMultibase, decodePublicKeyMultibase, decodeEncryptionKeyMultibase, extractPublicKeyFromAgentId, } from "./crypto/keys.js";
+export { generateKeypair, generateEncryptionKeypair, deriveAgentId, encodePublicKeyMultibase, encodeEncryptionKeyMultibase, decodePublicKeyMultibase, decodeEncryptionKeyMultibase, extractPublicKeyFromAgentId, AGENT_ID_KEY_PREFIXES, } from "./crypto/keys.js";
 export { fetchAgentCard, extractCandidateKeys, resolveBaseUrl, } from "./discovery/agent-card.js";
 export { verifyInkAuth, type NonceStore } from "./middleware/ink-auth.js";
 export { verifyInclusionReceipt, verifyAuditQueryResponse, type InclusionReceipt, type InclusionReceiptVerifyResult, type AuditQueryResponse, type AuditQueryResponseVerifyResult, type VerifyStep, } from "./audit/inclusion-receipt.js";

package/dist/index.js

@@ -4,7 +4,7 @@
 export { signInkMessage, verifyInkSignature, buildSignatureBase, buildAuthHeader, computeMessageHash, computeEventHash, computeAuditMerkleLeafHash, signAuditEvent, verifyAuditEventSignature, signAuditResponse, verifyAuditResponseSignature, verifyAuditEventChain, signAuditQueryResponse, verifyAuditQueryResponseSignature, encryptInkPayload, decryptInkPayload, checkReplay, base64urlEncode, base64urlDecode, hexToBytes, bytesToHex, jcsCanonicalize, MAX_TIMESTAMP_AGE_MS, MAX_FUTURE_TIMESTAMP_MS, } from "./crypto/ink.js";
 export { signMessage, verifyMessage } from "./crypto/sign.js";
 export { verifyInkSignatureWithKeys } from "./crypto/multi-key-verify.js";
-export { generateKeypair, generateEncryptionKeypair, deriveAgentId, encodePublicKeyMultibase, encodeEncryptionKeyMultibase, decodePublicKeyMultibase, decodeEncryptionKeyMultibase, extractPublicKeyFromAgentId, } from "./crypto/keys.js";
+export { generateKeypair, generateEncryptionKeypair, deriveAgentId, encodePublicKeyMultibase, encodeEncryptionKeyMultibase, decodePublicKeyMultibase, decodeEncryptionKeyMultibase, extractPublicKeyFromAgentId, AGENT_ID_KEY_PREFIXES, } from "./crypto/keys.js";
 // Discovery: Agent Card fetch + candidate-key extraction
 export { fetchAgentCard, extractCandidateKeys, resolveBaseUrl, } from "./discovery/agent-card.js";
 // Middleware: transport-level INK auth

package/docs/maturity.md

@@ -1,8 +1,10 @@
 # Maturity Notice
 
-> INK v0.1 is **experimental**. Wire formats, trust semantics and APIs
-> may change without backward-compatible migration before v1.0. Do not
-> use for load-bearing production traffic without your own review.
+> INK is **experimental**. The current defined wire version is `ink/0.2`, a
+> backward-compatible minor over `ink/0.1` (both major version 0). Wire formats,
+> trust semantics and APIs may change without backward-compatible migration
+> before v1.0. Do not use for load-bearing production traffic without your own
+> review.
 
 ## What "experimental" means here
 
@@ -12,8 +14,8 @@
   agent-card fetch, and DoS-amplification surfaces. Internal review is
   not a substitute for a third-party audit, treat the security
   posture accordingly.
-- Interop vectors (`../test-vectors/`) are authoritative for v0.1 but may
-  be added to or revised between v0.1 patch releases. Mismatched
+- Interop vectors (`../test-vectors/`) are authoritative for the current wire
+  version but may be added to or revised between patch releases. Mismatched
   implementations should report discrepancies as issues.
 - The protocol is in use by one production integrator (Tulpa). That is
   one data point, not a guarantee of robustness at scale.
@@ -22,7 +24,9 @@
   Bun, and edge runtimes. Browser use is feasible but not exercised by
   the maintainers.
 
-## What is stable in v0.1
+## What is stable
+
+These hold across major version 0 (`ink/0.1` and `ink/0.2`):
 
 - Envelope structure (fields, canonicalization with JCS / RFC 8785)
 - Ed25519 signing base: `ink/0.1\nMETHOD\nPATH\nrecipientDid\nJCS(body)\ntimestamp`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adastracomputing/ink",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "description": "Library and specification for the INK (Inter-agent Networking Kernel) protocol",
   "license": "MIT OR Apache-2.0",
   "author": "Ad Astra Computing Inc.",
@@ -61,12 +61,12 @@
     "zod": "^4.4.3"
   },
   "devDependencies": {
-    "@cloudflare/workers-types": "^4.20260418.1",
+    "@cloudflare/workers-types": "^4.20260604.1",
     "@types/node": "^24.12.4",
-    "@typescript-eslint/eslint-plugin": "^8.60.0",
+    "@typescript-eslint/eslint-plugin": "^8.60.1",
     "@typescript-eslint/parser": "^8.60.0",
-    "eslint": "^10.4.0",
-    "tsx": "^4.22.3",
+    "eslint": "^10.4.1",
+    "tsx": "^4.22.4",
     "typescript": "^6.0.3",
     "vitest": "^4.1.7"
   },

package/specs/ink-agent-containment-and-governance-extension-spec.md

@@ -1,7 +1,8 @@
 # INK Agent Containment and Governance Extension v0.1
 
-## Status
-Draft
+**Status:** Draft
+**Authors:** Ad Astra Computing
+**Last updated:** 2026-05-24
 
 ## Purpose
 

package/specs/ink-auditability.md

@@ -2,7 +2,7 @@
 
 **Status:** Draft
 **Authors:** Ad Astra Computing
-**Date:** 2026-03-19
+**Last updated:** 2026-06-01
 
 ## Problem
 

package/specs/ink-authorization-chain.md

@@ -2,7 +2,7 @@
 
 **Status:** Draft
 **Authors:** Ad Astra Computing
-**Date:** 2026-03-19
+**Last updated:** 2026-05-24
 
 ## Problem
 

package/specs/ink-compatibility-policy.md

@@ -1,7 +1,8 @@
 # INK Compatibility and Versioning Policy
 
-## Status
-Draft, v1 stabilization
+**Status:** Draft, v1 stabilization
+**Authors:** Ad Astra Computing
+**Last updated:** 2026-05-24
 
 ## Purpose
 
@@ -15,7 +16,7 @@ This is the normative compatibility contract. Any change to the INK wire format
 
 INK uses a single protocol version string in every message envelope, receipt, audit event and handshake message.
 
-Current version: `ink/0.1`
+Defined versions: `ink/0.1` (default) and `ink/0.2` (negotiated). See [§1.4](#14-defined-wire-versions).
 
 The version string appears in the `protocol` field of every top-level INK object and in the first line of every signature base.
 
@@ -48,6 +49,17 @@ prefix (e.g. `network.ink.*`) and define a transition policy. Until then,
 conforming implementations MUST emit and accept `network.tulpa.*` types as
 specified.
 
+### 1.4 Defined wire versions
+
+Two wire versions are defined:
+
+- `ink/0.1`, the original version. A sender emits it by default unless it has positively negotiated otherwise.
+- `ink/0.2`, a backward-compatible minor that changes only the body-signature domain separator, from the legacy `tulpa/sign\n` to the neutral `ink/sign\n`. Everything else, the transport-auth signature base, the envelope shape, the encryption and audit sub-protocols and every `network.tulpa.*` type, is identical to `ink/0.1`.
+
+`ink/0.2` is receiver-first. A receiver advertises the versions it verifies in its Agent Card `supportedProtocolVersions` array; when that field is absent a sender MUST assume `ink/0.1` only, and a sender MUST NOT emit `ink/0.2` to a receiver that has not advertised it. The negotiation is what keeps the change compatible: an `ink/0.1`-only receiver never receives `ink/0.2` traffic, so it is never asked to verify a domain it does not implement. An `ink/0.2` receiver selects the body-signature domain from the signed `protocol` field and verifies both versions, and because `protocol` is inside the signed body a relabelled message fails verification.
+
+This satisfies §1.1. The minor bump adds a capability without breaking deployed `ink/0.1` implementations, because the body-signature domain is negotiated rather than assumed.
+
 ---
 
 ## 2. Compatibility Rules

package/specs/ink-compliance-checklist.md

@@ -1,7 +1,8 @@
 # INK v0.1 Compliance Checklist and Implementation Matrix
 
-## Status
-Draft, v0.1 alpha conformance
+**Status:** Draft, v0.1 alpha conformance
+**Authors:** Ad Astra Computing
+**Last updated:** 2026-05-27
 
 ## Purpose
 

package/specs/ink-containment-phase1-implementation-spec.md

@@ -1,7 +1,8 @@
 # INK Containment Phase 1, Implementation Spec
 
-## Status
-Draft
+**Status:** Draft
+**Authors:** Ad Astra Computing
+**Last updated:** 2026-06-01
 
 ## Purpose
 

package/specs/ink-introduction-receipts-extension.md

@@ -1,10 +1,8 @@
 # INK Introduction Receipts Extension v0.1
 
-## Status
-Draft
-
-## Last Updated
-23 March 2026
+**Status:** Draft
+**Authors:** Ad Astra Computing
+**Last updated:** 2026-05-24
 
 ## Purpose
 

package/specs/ink-key-rotation-spec.md

@@ -1,7 +1,8 @@
 # INK Key Rotation Specification v0.1
 
-## Status
-Draft
+**Status:** Draft
+**Authors:** Ad Astra Computing
+**Last updated:** 2026-05-24
 
 ## Purpose