Discovery & Transport

Discovery Flow

Endpoint Discovery

The DID document is the sole authoritative source for endpoint discovery. Agents locate a target’s INK endpoint by resolving the target DID and finding the TulpaAgentEndpoint service entry:

{
  "id": "#tulpaAgent",
  "type": "TulpaAgentEndpoint",
  "serviceEndpoint": "https://agent.example.com/ink/v1"
}

The agentLink record provides key material and delegation proof but does NOT contain an endpoint field. If no TulpaAgentEndpoint service entry exists in the DID document, the DID is not INK-reachable.

Transport

• Protocol: HTTPS / REST. All INK endpoints MUST be served over TLS 1.2+.
• Content-Type: application/json
• Protocol Version: Every INK message MUST include "protocol": "ink/0.1" at the top level.

Naming Convention: Lexicon IDs vs. Wire Types

INK uses two distinct identifier formats for message types. Implementations MUST distinguish between them:

Purpose	Format	Example
AT Protocol Lexicon ID (schema registry)	camelCase, includes ink namespace segment	network.tulpa.ink.auditQuery
Wire type field (JSON message body)	snake_case, omits ink segment	network.tulpa.audit_query

The lexicon ID follows AT Protocol conventions (camelCase NSID with hierarchical namespacing). The wire type is the value in the "type" field of every INK message — it is what implementations match on when routing messages.

Implementations MUST key off the wire type field, not the lexicon ID.

For single-word types the distinction is invisible (network.tulpa.intent maps to lexicon network.tulpa.ink.intent). For multi-word types it is significant: network.tulpa.audit_query (wire) vs. network.tulpa.ink.auditQuery (lexicon).

See Wire Types Reference for the complete mapping.