Skip to content
INK

Versioning & Compatibility

INK versions its wire format with a ink/<major>.<minor> string carried in the protocol field of every message. Major versions are incremented for incompatible wire changes; minor versions for backward-compatible additions.

Current wire version

ink/0.2 is the current defined wire version and 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. Everything else, including the transport-auth signature base, the envelope shape, and the encryption, audit, and receipt sub-protocols, is identical to ink/0.1.

ink/0.1 remains fully supported. Both versions are major version 0, and a conformant major-0 receiver accepts either.

What a receiver must accept

The shipped envelope schema is strict about which version strings it accepts:

  • The envelope protocol field is a strict enum accepting only ink/0.1 and ink/0.2.
  • A receiver MUST reject any other protocol version, including an unrecognized minor within major 0. There is no “accept any minor” fallthrough.
  • A receiver verifies both body-signature domains, so a ink/0.1 and a ink/0.2 envelope both verify on the same receiver.

Because the body-signature domain is keyed off the signed protocol field, relabelling an envelope from one version to another breaks its signature. A receiver never tries an alternate domain, so a signature minted under one version is never accepted under another.

Will ink/0.1 be dropped?

No, not within major 0. A version is sunset only at the major boundary, with the notice process described in the compatibility policy. There is no plan to drop ink/0.1 while major 0 is supported, and a new receiver that verifies both domains needs no migration when peers move to ink/0.2.

What senders emit today

Sending is receiver-first. A sender emits ink/0.1 by default and only emits ink/0.2 to a receiver that advertises ink/0.2 in its Agent Card supportedProtocolVersions. So adopting ink/0.2 on the receive side is safe and additive: you gain the ability to verify ink/0.2 envelopes without changing what you send.

On npm

The @adastracomputing/ink package publishes 0.12.0 on the next tag; latest is 0.8.0. A bare npm install @adastracomputing/ink resolves to 0.8.0; npm install @adastracomputing/ink@next resolves to 0.12.0. Both verify both signature domains and both accept the ink: agentId alias alongside the canonical tulpa: prefix (see Identity); the alias is an additive inbound-acceptance behavior and does not alter the wire version.

The 0.12.0 release adds a normative raw-body UTF-8 rule to the signed-body profile: a receiver rejects a signed body whose raw bytes are not valid UTF-8 before parsing it, pinned by the new signed-body-utf8 conformance category (see Canonicalization). This is a signed-body rule, not a wire-version change, so it does not alter the protocol field or the version strings a receiver accepts.

For the normative rules, see the compatibility policy.