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 compatibility rules are deliberately tolerant within a major version:

  • A receiver MUST reject a message whose major version it does not recognize.
  • A receiver SHOULD accept a recognized major version with an unrecognized minor version, ignoring any unknown optional fields.
  • The inbound version check compares only the major version, so every minor within major 0 (including both ink/0.1 and ink/0.2) is accepted.

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.3.0 on the next tag; latest is 0.2.0. Installing either gives a runtime that verifies both signature domains. 0.3.0 additionally accepts the ink: agentId alias alongside the canonical tulpa: prefix (see Identity); this is an additive inbound-acceptance change and does not alter the wire version.

For the normative rules, see the compatibility policy.