@indexnetwork/protocol 4.3.1-rc.299.1 → 4.3.2-rc.300.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +98 -0
- package/IMPLEMENTATION.md +255 -0
- package/README.md +380 -206
- package/STABILITY.md +92 -0
- package/package.json +5 -2
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to `@indexnetwork/protocol` are documented here.
|
|
4
|
+
|
|
5
|
+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
|
|
6
|
+
and this project adheres to [Semantic Versioning](https://semver.org/).
|
|
7
|
+
See [STABILITY.md](./STABILITY.md) for the public-contract and tier definitions.
|
|
8
|
+
|
|
9
|
+
> History before `2.0.0` was reconstructed from git and is summarized rather than
|
|
10
|
+
> itemized. From `2.0.0` onward, keep this file updated as part of every release
|
|
11
|
+
> (bump `package.json` and the `[Unreleased]` section before promoting to `main`).
|
|
12
|
+
|
|
13
|
+
## [Unreleased]
|
|
14
|
+
|
|
15
|
+
### Changed
|
|
16
|
+
- Reframed `README.md` as the public-facing Index Network Protocol document and moved package integration details into `IMPLEMENTATION.md`.
|
|
17
|
+
- Included protocol documentation files in the published package tarball so README links remain available to package consumers.
|
|
18
|
+
|
|
19
|
+
## [4.3.0] - 2026-06-21
|
|
20
|
+
|
|
21
|
+
### Added
|
|
22
|
+
- `STABILITY.md` defining the public contract, stability tiers (Stable vs
|
|
23
|
+
`@experimental`), SemVer policy, and the deprecation path.
|
|
24
|
+
- Port-contract doc-comments on the `ChatSessionReader`, `DiscoveryRunStore`/
|
|
25
|
+
`DiscoveryRunQueue`, `EnrichmentRunStore`/`EnrichmentRunQueue`, and `Embedder`
|
|
26
|
+
interfaces (ownership scoping, null-vs-empty-array, lifecycle idempotency).
|
|
27
|
+
- Tier annotations and an entry-point header in `src/index.ts`.
|
|
28
|
+
|
|
29
|
+
### Changed
|
|
30
|
+
- Replaced all `export type *` wildcard re-exports in `src/index.ts` with explicit
|
|
31
|
+
named exports so the public surface is fully enumerated and reviewable. No
|
|
32
|
+
symbols added or removed — the exported surface is unchanged.
|
|
33
|
+
- Expanded `README.md` to document the full public surface (graph factories,
|
|
34
|
+
agents, MCP, tools) and link the stability policy.
|
|
35
|
+
|
|
36
|
+
## [4.2.0] - 2026-06-19
|
|
37
|
+
|
|
38
|
+
### Added
|
|
39
|
+
- Opportunity legibility: cards explain *why* an opportunity surfaced.
|
|
40
|
+
- Negotiation trace links on surfaced opportunities.
|
|
41
|
+
|
|
42
|
+
## [4.1.0] - 2026-06
|
|
43
|
+
|
|
44
|
+
### Added
|
|
45
|
+
- Canonical user-context / enrichment MCP tools; `discoverySource` rename
|
|
46
|
+
(IND-372, IND-371, IND-374).
|
|
47
|
+
- Context-derived `read_user_profiles` payload (IND-364).
|
|
48
|
+
|
|
49
|
+
### Changed
|
|
50
|
+
- Category A prompt consumers repointed at the global `user_context` (IND-361).
|
|
51
|
+
- Premise pipeline ownership: dedup, LLM validity, richer provenance (IND-359).
|
|
52
|
+
|
|
53
|
+
## [4.0.0] - 2026-06-18
|
|
54
|
+
|
|
55
|
+
### Changed
|
|
56
|
+
- **BREAKING:** Eliminated the "profile" concept — the pipeline, files, service,
|
|
57
|
+
controller, adapter, and exported types were renamed to `enrichment`
|
|
58
|
+
(`ProfileDocument` → `UserIdentity`, `read_user_profiles` returns a flat
|
|
59
|
+
identity+context payload, questioner `profile` mode → `enrichment`). Update any
|
|
60
|
+
imports of the removed `Profile*` exports. (IND-368)
|
|
61
|
+
|
|
62
|
+
### Removed
|
|
63
|
+
- **BREAKING:** `user_profiles` table and the profile generate/aggregate/save path
|
|
64
|
+
retired (IND-365).
|
|
65
|
+
|
|
66
|
+
## [3.6.0] - 2026-06-12
|
|
67
|
+
|
|
68
|
+
### Added
|
|
69
|
+
- `read_pending_questions` MCP tool, registered in the tool registry.
|
|
70
|
+
|
|
71
|
+
## [2.0.1] - 2026-06
|
|
72
|
+
|
|
73
|
+
### Fixed
|
|
74
|
+
- Post-`2.0.0` fixes and stabilization.
|
|
75
|
+
|
|
76
|
+
## [2.0.0] - 2026-06-08
|
|
77
|
+
|
|
78
|
+
### Changed
|
|
79
|
+
- **BREAKING:** Removed `configureProtocol` startup call — model configuration is
|
|
80
|
+
read from the environment and `ModelConfig` is injected per-request via
|
|
81
|
+
`ToolContext`. See README for migration.
|
|
82
|
+
|
|
83
|
+
## [1.0.0 - 1.23.3] - 2026-04 to 2026-06
|
|
84
|
+
|
|
85
|
+
Pre-2.0 line: established the adapter-injected LangGraph architecture (chat,
|
|
86
|
+
intent, opportunity, negotiation, premise, enrichment domains), the MCP server,
|
|
87
|
+
the matching/opportunity/premise eval harnesses, premise source tracking and
|
|
88
|
+
cascade retraction, network-scoped agents, and the agent registry. Reconstructed
|
|
89
|
+
from git history; not itemized.
|
|
90
|
+
|
|
91
|
+
[Unreleased]: https://github.com/indexnetwork/protocol/compare/v4.3.0...HEAD
|
|
92
|
+
[4.3.0]: https://github.com/indexnetwork/protocol/compare/v4.2.0...v4.3.0
|
|
93
|
+
[4.2.0]: https://github.com/indexnetwork/protocol/compare/v4.1.0...v4.2.0
|
|
94
|
+
[4.1.0]: https://github.com/indexnetwork/protocol/compare/v4.0.0...v4.1.0
|
|
95
|
+
[4.0.0]: https://github.com/indexnetwork/protocol/compare/v3.6.0...v4.0.0
|
|
96
|
+
[3.6.0]: https://github.com/indexnetwork/protocol/compare/v2.0.1...v3.6.0
|
|
97
|
+
[2.0.1]: https://github.com/indexnetwork/protocol/compare/v2.0.0...v2.0.1
|
|
98
|
+
[2.0.0]: https://github.com/indexnetwork/protocol/releases/tag/v2.0.0
|
|
@@ -0,0 +1,255 @@
|
|
|
1
|
+
# @indexnetwork/protocol Implementation Guide
|
|
2
|
+
|
|
3
|
+
This guide covers the technical package surface for implementers embedding the canonical Index Network Protocol implementation. For the public protocol overview, see [README.md](./README.md).
|
|
4
|
+
|
|
5
|
+
The package implements LangGraph-based workflows for signal processing, opportunity discovery, negotiation, and chat — decoupled from any specific infrastructure via adapter injection.
|
|
6
|
+
|
|
7
|
+
## Stability & versioning
|
|
8
|
+
|
|
9
|
+
This package follows [Semantic Versioning](https://semver.org/). The **only**
|
|
10
|
+
supported entry point is the package root (`import { ... } from "@indexnetwork/protocol"`);
|
|
11
|
+
deep imports are not part of the contract. Every symbol is re-exported explicitly from
|
|
12
|
+
`src/index.ts` and tagged with a stability tier:
|
|
13
|
+
|
|
14
|
+
- **Stable** — interfaces, graph factories, agents, `createChatTools`, the
|
|
15
|
+
tool/runtime helpers, and shared schemas. Breaking changes require a major bump.
|
|
16
|
+
- **Experimental** (`@experimental`) — advanced graph-state types and internal
|
|
17
|
+
helpers; may change in a minor release.
|
|
18
|
+
|
|
19
|
+
See [STABILITY.md](./STABILITY.md) for the full policy and the deprecation path,
|
|
20
|
+
and [CHANGELOG.md](./CHANGELOG.md) for release history.
|
|
21
|
+
|
|
22
|
+
## Install
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
npm install @indexnetwork/protocol
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
## Setup
|
|
29
|
+
|
|
30
|
+
### 1. Configure the LLM
|
|
31
|
+
|
|
32
|
+
The package reads `OPENROUTER_API_KEY` (required), `CHAT_MODEL`, and `CHAT_REASONING_EFFORT` from environment variables. No startup call is needed.
|
|
33
|
+
|
|
34
|
+
To override the chat model or reasoning effort when using the built-in chat runtime (`ChatGraphFactory` / `ChatAgent`), pass `modelConfig` on `ToolContext`. `ChatAgent` reads these fields when the chat graph runs; the tools themselves do not consume `modelConfig`:
|
|
35
|
+
|
|
36
|
+
```typescript
|
|
37
|
+
import { createChatTools } from "@indexnetwork/protocol";
|
|
38
|
+
|
|
39
|
+
const tools = await createChatTools({
|
|
40
|
+
// ... other deps ...
|
|
41
|
+
modelConfig: {
|
|
42
|
+
chatModel: "google/gemini-2.5-flash", // optional — has a default
|
|
43
|
+
chatReasoningEffort: "low", // optional: minimal | low | medium | high | xhigh
|
|
44
|
+
},
|
|
45
|
+
});
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
`apiKey` and `baseURL` can also be overridden this way. All other protocol agents (evaluators, generators, etc.) rely on `OPENROUTER_API_KEY` set in the environment regardless of `modelConfig`.
|
|
49
|
+
|
|
50
|
+
### 2. Implement the adapters
|
|
51
|
+
|
|
52
|
+
The package defines interfaces — your application provides the concrete implementations.
|
|
53
|
+
|
|
54
|
+
**Required** (always needed by `createChatTools`):
|
|
55
|
+
|
|
56
|
+
| Interface | Responsibility |
|
|
57
|
+
|---|---|
|
|
58
|
+
| `ChatGraphCompositeDatabase` | Core data access (users, intents, indexes/networks, opportunities) |
|
|
59
|
+
| `UserDatabase` / `SystemDatabase` | Context-bound databases built by `createUserDatabase` / `createSystemDatabase` |
|
|
60
|
+
| `Embedder` | Vector embeddings for semantic search |
|
|
61
|
+
| `Scraper` | Web content extraction |
|
|
62
|
+
| `Cache` / `HydeCache` | Result caching (HyDE may share the general cache) |
|
|
63
|
+
| `IntegrationAdapter` | OAuth and external tool actions |
|
|
64
|
+
| `IntentGraphQueue` | Background intent processing queue |
|
|
65
|
+
| `ContactServiceAdapter` | Contact management |
|
|
66
|
+
| `ChatSessionReader` | Load conversation history |
|
|
67
|
+
| `ProfileEnricher` | Enrich profiles from external sources |
|
|
68
|
+
| `NegotiationGraphDatabase` | Negotiation state persistence |
|
|
69
|
+
|
|
70
|
+
**Optional** (enable specific capabilities; omit to run without that feature):
|
|
71
|
+
|
|
72
|
+
| Interface | Responsibility |
|
|
73
|
+
|---|---|
|
|
74
|
+
| `AgentDatabase` | Agent registry CRUD (agents, transports, permissions) |
|
|
75
|
+
| `AgentDispatcher` | Resolves and invokes personal agents during negotiation turns — required to register the negotiation tools |
|
|
76
|
+
| `McpAuthResolver` | Resolves `{ userId, agentId }` from an incoming MCP HTTP request (MCP server only) |
|
|
77
|
+
| `DeliveryLedger` | Commits OpenClaw opportunity-delivery rows |
|
|
78
|
+
| `DiscoveryRunStore` / `DiscoveryRunQueue` | Persist and execute async MCP discovery runs |
|
|
79
|
+
| `EnrichmentRunStore` / `EnrichmentRunQueue` | Persist and execute async MCP enrichment runs |
|
|
80
|
+
| `MintConnectLink` | Mints short connect links for opportunity accepts |
|
|
81
|
+
| `ChatSummaryReader` | Read-through chat-session digest |
|
|
82
|
+
| `ChatMessageWriter` | Writes user messages into the most-recent chat session (MCP elicitation) |
|
|
83
|
+
| `QuestionGeneratorReader` / `QuestionerDatabase` | Decision-question generation and persistence |
|
|
84
|
+
| `NegotiationSummaryReader` | Negotiation-digest summarization (falls back to deterministic digests) |
|
|
85
|
+
|
|
86
|
+
All interfaces are exported from the package root — import them with `import type { ... } from "@indexnetwork/protocol"`.
|
|
87
|
+
|
|
88
|
+
### 3. Create tools
|
|
89
|
+
|
|
90
|
+
Pass your adapter implementations to `createChatTools` to get a set of LangChain-compatible tools bound to a user session:
|
|
91
|
+
|
|
92
|
+
```typescript
|
|
93
|
+
import { createChatTools } from "@indexnetwork/protocol";
|
|
94
|
+
|
|
95
|
+
const tools = await createChatTools({
|
|
96
|
+
userId: "user-uuid",
|
|
97
|
+
|
|
98
|
+
// ── Required adapters ──
|
|
99
|
+
database, // ChatGraphCompositeDatabase
|
|
100
|
+
embedder, // Embedder
|
|
101
|
+
scraper, // Scraper
|
|
102
|
+
cache, // Cache
|
|
103
|
+
hydeCache, // HydeCache
|
|
104
|
+
integration, // IntegrationAdapter
|
|
105
|
+
intentQueue, // IntentGraphQueue
|
|
106
|
+
contactService, // ContactServiceAdapter
|
|
107
|
+
chatSession, // ChatSessionReader
|
|
108
|
+
enricher, // ProfileEnricher
|
|
109
|
+
negotiationDatabase, // NegotiationGraphDatabase
|
|
110
|
+
integrationImporter, // bulk contact import
|
|
111
|
+
createUserDatabase, // (db, userId) => UserDatabase
|
|
112
|
+
createSystemDatabase, // (db, userId, indexScope, embedder?) => SystemDatabase
|
|
113
|
+
|
|
114
|
+
// ── Optional scoping ──
|
|
115
|
+
networkId: "optional-network-uuid", // scope tools to a specific index/network
|
|
116
|
+
sessionId: "chat-session-id", // enables draft opportunities with conversation context
|
|
117
|
+
|
|
118
|
+
// ── Optional capabilities (enable when the host supports them) ──
|
|
119
|
+
agentDatabase, // AgentDatabase — agent registry
|
|
120
|
+
agentDispatcher, // AgentDispatcher — routes negotiation turns to personal agents
|
|
121
|
+
deliveryLedger, // DeliveryLedger — OpenClaw delivery commits
|
|
122
|
+
discoveryRuns, // DiscoveryRunStore (+ discoveryRunQueue) — async MCP discovery
|
|
123
|
+
enrichmentRuns, // EnrichmentRunStore (+ enrichmentRunQueue) — async MCP enrichment runs
|
|
124
|
+
mintConnectLink, // short connect links for opportunity accepts
|
|
125
|
+
modelConfig, // override chat model / reasoning effort (see above)
|
|
126
|
+
});
|
|
127
|
+
|
|
128
|
+
// tools is an array of LangChain Tool objects ready to bind to an agent
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
`createChatTools` accepts a single `ToolContext` object. The required adapters
|
|
132
|
+
above are always needed; the optional capabilities default to a degraded-but-
|
|
133
|
+
functional mode when omitted (e.g. without `agentDispatcher` the negotiation
|
|
134
|
+
tools are not registered, and without `discoveryRuns` MCP discovery runs
|
|
135
|
+
synchronously).
|
|
136
|
+
|
|
137
|
+
## Graphs
|
|
138
|
+
|
|
139
|
+
For direct graph invocation (bypassing the tool layer), a `*GraphFactory` class is exported for each workflow:
|
|
140
|
+
|
|
141
|
+
```typescript
|
|
142
|
+
import {
|
|
143
|
+
ChatGraphFactory,
|
|
144
|
+
IntentGraphFactory,
|
|
145
|
+
OpportunityGraphFactory,
|
|
146
|
+
EnrichmentGraphFactory,
|
|
147
|
+
PremiseGraphFactory,
|
|
148
|
+
NegotiationGraphFactory,
|
|
149
|
+
HydeGraphFactory,
|
|
150
|
+
NetworkGraphFactory,
|
|
151
|
+
NetworkMembershipGraphFactory,
|
|
152
|
+
IntentNetworkGraphFactory,
|
|
153
|
+
HomeGraphFactory,
|
|
154
|
+
MaintenanceGraphFactory,
|
|
155
|
+
} from "@indexnetwork/protocol";
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
Each factory takes its typed dependencies in the constructor and exposes a
|
|
159
|
+
`.createGraph()` method that returns a compiled LangGraph ready for `.invoke()`.
|
|
160
|
+
|
|
161
|
+
| Factory | Workflow |
|
|
162
|
+
|---|---|
|
|
163
|
+
| `ChatGraphFactory` | ReAct chat loop — LLM calls tools, responds to the user |
|
|
164
|
+
| `IntentGraphFactory` | Clarify, infer, verify felicity, reconcile, and persist intents |
|
|
165
|
+
| `OpportunityGraphFactory` | HyDE-based discovery: search, evaluate (valency), rank, persist |
|
|
166
|
+
| `EnrichmentGraphFactory` | Enrich users (scrape + embed) and decompose into premises |
|
|
167
|
+
| `PremiseGraphFactory` | Decompose and index a user's premises |
|
|
168
|
+
| `NegotiationGraphFactory` | Multi-turn bilateral negotiation flows |
|
|
169
|
+
| `HydeGraphFactory` | Generate hypothetical documents and embed them (cache-aware) |
|
|
170
|
+
| `NetworkGraphFactory` | Manage index/network CRUD |
|
|
171
|
+
| `NetworkMembershipGraphFactory` | Manage index/network member join/leave |
|
|
172
|
+
| `IntentNetworkGraphFactory` | Evaluate and assign/unassign intents to indexes |
|
|
173
|
+
| `HomeGraphFactory` | Categorize and curate home-feed content |
|
|
174
|
+
| `MaintenanceGraphFactory` | Periodic maintenance (feed health, opportunity expiration) |
|
|
175
|
+
|
|
176
|
+
## MCP server
|
|
177
|
+
|
|
178
|
+
The package exports a factory that registers every chat tool over the Model Context Protocol and attaches a canonical `instructions` block (`MCP_INSTRUCTIONS`) that every connecting runtime follows. The factory takes three arguments:
|
|
179
|
+
|
|
180
|
+
```typescript
|
|
181
|
+
import { createMcpServer, type McpAuthResolver } from "@indexnetwork/protocol";
|
|
182
|
+
|
|
183
|
+
const authResolver: McpAuthResolver = {
|
|
184
|
+
async resolveIdentity(req) {
|
|
185
|
+
// Look up the API key in `x-api-key` and return { userId, agentId? }.
|
|
186
|
+
// `agentId` should come from Better Auth token metadata so downstream
|
|
187
|
+
// tool handlers can attribute every call to a concrete agent identity.
|
|
188
|
+
return resolveFromApiKey(req);
|
|
189
|
+
},
|
|
190
|
+
};
|
|
191
|
+
|
|
192
|
+
const server = createMcpServer(
|
|
193
|
+
deps,
|
|
194
|
+
authResolver,
|
|
195
|
+
{
|
|
196
|
+
// Per-request factory for scoped user/system databases.
|
|
197
|
+
create: (userId, indexScope) => createScopedDeps(userId, indexScope),
|
|
198
|
+
},
|
|
199
|
+
);
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
On every tool call the server:
|
|
203
|
+
|
|
204
|
+
1. Extracts the HTTP request from the MCP `ServerContext`.
|
|
205
|
+
2. Calls `authResolver.resolveIdentity(req)` to get `{ userId, agentId }`.
|
|
206
|
+
3. Gates access: MCP callers without a resolved `agentId` are blocked from every tool except `register_agent`, `read_docs`, and `scrape_url` until they register.
|
|
207
|
+
4. Builds per-request scoped databases via `scopedDepsFactory` and invokes the tool handler through the shared runtime.
|
|
208
|
+
|
|
209
|
+
### Runtime controls
|
|
210
|
+
|
|
211
|
+
MCP tools are bounded by `ToolInvocationRuntime`:
|
|
212
|
+
|
|
213
|
+
| Class | Default | Class override |
|
|
214
|
+
|---|---:|---|
|
|
215
|
+
| `fast` | 10 s | `MCP_TOOL_TIMEOUT_FAST_MS` |
|
|
216
|
+
| `bounded_slow` | 45 s | `MCP_TOOL_TIMEOUT_BOUNDED_SLOW_MS` |
|
|
217
|
+
| `async_candidate` | 50 s | `MCP_TOOL_TIMEOUT_ASYNC_CANDIDATE_MS` |
|
|
218
|
+
|
|
219
|
+
Per-tool timeout overrides use `MCP_TOOL_TIMEOUT_<TOOL_NAME>_MS`, such as `MCP_TOOL_TIMEOUT_DISCOVER_OPPORTUNITIES_MS`. Tool outputs are capped by `MCP_TOOL_MAX_OUTPUT_BYTES` (default `1000000`) or `MCP_TOOL_MAX_OUTPUT_<TOOL_NAME>_BYTES`; inbound MCP request bodies are capped by the backend with `MCP_MAX_REQUEST_BYTES` (default `1000000`). Runtime failures return JSON text envelopes with stable `code` values: `TOOL_TIMEOUT`, `TOOL_CANCELLED`, or `TOOL_OUTPUT_TOO_LARGE`.
|
|
220
|
+
|
|
221
|
+
For MCP callers, `discover_opportunities` is async: it returns a `discoveryRunId` immediately, and clients poll `get_discovery_run` or request cancellation with `cancel_discovery_run`. Non-MCP chat/web paths stay synchronous.
|
|
222
|
+
|
|
223
|
+
### `MCP_INSTRUCTIONS`
|
|
224
|
+
|
|
225
|
+
The instructions string is the single canonical behavioral contract for every runtime that connects to Index Network — voice, entity model, discovery-first rule, output rules, and the **Negotiation turn mode** block that tells a silent subagent how to handle a live negotiation turn when its session key is prefixed `index:negotiation:`. Plugin skills and bootstrap scripts do **not** redefine this guidance; they defer to whatever ships in `MCP_INSTRUCTIONS`.
|
|
226
|
+
|
|
227
|
+
### Negotiation-facing tools
|
|
228
|
+
|
|
229
|
+
Personal agents participate in bilateral negotiation via a small set of MCP tools:
|
|
230
|
+
|
|
231
|
+
| Tool | Purpose |
|
|
232
|
+
|---|---|
|
|
233
|
+
| `get_negotiation` | Fetch the full turn history and assessment seed for a negotiation |
|
|
234
|
+
| `list_negotiations` | List negotiations awaiting a response from this agent's user |
|
|
235
|
+
| `respond_to_negotiation` | Submit a turn (propose / counter / accept / reject / question) |
|
|
236
|
+
|
|
237
|
+
## Publishing
|
|
238
|
+
|
|
239
|
+
Publishing is handled via CI:
|
|
240
|
+
|
|
241
|
+
```bash
|
|
242
|
+
# dev pushes publish an rc prerelease
|
|
243
|
+
git push <remote> dev
|
|
244
|
+
|
|
245
|
+
# main pushes publish the stable release if the package version is new
|
|
246
|
+
git push <remote> main
|
|
247
|
+
```
|
|
248
|
+
|
|
249
|
+
`dev` publishes prerelease versions derived from `package.json` using npm's `rc` tag, for example `3.6.3-rc.123.1`. `main` publishes the base version from `package.json` to `latest` only when that version is not already on npm.
|
|
250
|
+
|
|
251
|
+
Or publish manually from `packages/protocol/`:
|
|
252
|
+
|
|
253
|
+
```bash
|
|
254
|
+
npm publish --access public
|
|
255
|
+
```
|
package/README.md
CHANGED
|
@@ -1,253 +1,427 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Index Network Protocol
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
## Status
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
This document describes the public protocol model for Index Network: the entities, state transitions, agent obligations, privacy boundaries, and discovery semantics that define interoperable participation in the network.
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
supported entry point is the package root (`import { ... } from "@indexnetwork/protocol"`);
|
|
9
|
-
deep imports are not part of the contract. Every symbol is re-exported explicitly from
|
|
10
|
-
`src/index.ts` and tagged with a stability tier:
|
|
7
|
+
The canonical reference implementation is published as `@indexnetwork/protocol`. Implementation details, package installation, exported APIs, adapter contracts, graph factories, and release mechanics are documented separately in [IMPLEMENTATION.md](./IMPLEMENTATION.md). Public API stability is defined in [STABILITY.md](./STABILITY.md).
|
|
11
8
|
|
|
12
|
-
|
|
13
|
-
tool/runtime helpers, and shared schemas. Breaking changes require a major bump.
|
|
14
|
-
- **Experimental** (`@experimental`) — advanced graph-state types and internal
|
|
15
|
-
helpers; may change in a minor release.
|
|
9
|
+
Normative terms such as **MUST**, **MUST NOT**, **SHOULD**, and **MAY** are used in their ordinary protocol-documentation sense.
|
|
16
10
|
|
|
17
|
-
|
|
18
|
-
and [CHANGELOG.md](./CHANGELOG.md) for release history.
|
|
11
|
+
## Abstract
|
|
19
12
|
|
|
20
|
-
|
|
13
|
+
Index Network is a private, intent-driven discovery protocol for agent-mediated opportunity discovery.
|
|
21
14
|
|
|
22
|
-
|
|
23
|
-
npm install @indexnetwork/protocol
|
|
24
|
-
```
|
|
15
|
+
Participants express **signals**: structured statements of what they seek, offer, are open to, or can credibly support. Agents interpret those signals against participant **context**, constrain discovery to bounded **communities**, evaluate candidate overlaps, negotiate fit when appropriate, and surface **opportunities** only through consent-gated state transitions.
|
|
25
16
|
|
|
26
|
-
|
|
17
|
+
The protocol is designed for high-signal human and agent coordination. It is not a public people database, keyword search engine, advertising channel, or automated introduction machine. Its purpose is to discover meaningful overlap while preserving context, scope, and human approval.
|
|
27
18
|
|
|
28
|
-
|
|
19
|
+
## Protocol overview
|
|
29
20
|
|
|
30
|
-
|
|
21
|
+
```mermaid
|
|
22
|
+
flowchart LR
|
|
23
|
+
Participant[Participant] --> Agent[Authorized agent]
|
|
24
|
+
Participant --> Context[Context]
|
|
25
|
+
Participant --> Signal[Signal]
|
|
31
26
|
|
|
32
|
-
|
|
27
|
+
Premises[Premises] --> Context
|
|
28
|
+
Context --> Scope[Effective scope]
|
|
29
|
+
Signal --> Scope
|
|
30
|
+
Community[Community membership and norms] --> Scope
|
|
31
|
+
AgentScope[Agent permissions] --> Scope
|
|
33
32
|
|
|
34
|
-
|
|
35
|
-
|
|
33
|
+
Scope --> CandidateGeneration[Candidate generation]
|
|
34
|
+
CandidateGeneration --> Evaluation[Evaluation]
|
|
35
|
+
Evaluation -->|plausible but uncertain| Opportunity[Draft or negotiating opportunity]
|
|
36
|
+
Evaluation -->|clear fit| Opportunity[Draft or pending opportunity]
|
|
37
|
+
Opportunity -->|needs agent clarification| Negotiation[Bounded negotiation]
|
|
38
|
+
Negotiation -->|fit established| Opportunity
|
|
39
|
+
Negotiation -->|human judgment required| Questions[Structured questions]
|
|
40
|
+
Questions --> Participant
|
|
41
|
+
Participant --> Signal
|
|
36
42
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
chatModel: "google/gemini-2.5-flash", // optional — has a default
|
|
41
|
-
chatReasoningEffort: "low", // optional: minimal | low | medium | high | xhigh
|
|
42
|
-
},
|
|
43
|
-
});
|
|
43
|
+
Opportunity --> Consent{Participant consent?}
|
|
44
|
+
Consent -->|yes| Connection[Connection]
|
|
45
|
+
Consent -->|no| Terminal[Declined or expired]
|
|
44
46
|
```
|
|
45
47
|
|
|
46
|
-
|
|
48
|
+
The graph is intentionally consent-centered: agents can construct context, discover candidates, evaluate fit, and negotiate constraints, but relationship-forming transitions require participant approval before a connection is opened.
|
|
47
49
|
|
|
48
|
-
|
|
50
|
+
## Design goals
|
|
49
51
|
|
|
50
|
-
|
|
52
|
+
1. **Intent as the primary primitive** — discovery begins from a participant's current signal, not from static identity alone.
|
|
53
|
+
2. **Bounded visibility** — communities define the scope in which signals and context may be evaluated.
|
|
54
|
+
3. **Semantic discovery** — matching is based on role fit, constraints, complementarity, and contextual relevance rather than exact keyword overlap.
|
|
55
|
+
4. **Explainable surfacing** — every surfaced opportunity SHOULD include a legible reason: why these participants, why now, and what the next action might be.
|
|
56
|
+
5. **Consent at relationship boundaries** — agents MAY discover and negotiate, but MUST NOT create or accept a relationship without explicit participant approval.
|
|
57
|
+
6. **Agent interoperability** — first-party agents, personal agents, community agents, and external MCP clients SHOULD be able to participate under the same behavioral contract.
|
|
51
58
|
|
|
52
|
-
|
|
59
|
+
## Non-goals
|
|
53
60
|
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
|
66
|
-
| `NegotiationGraphDatabase` | Negotiation state persistence |
|
|
67
|
-
|
|
68
|
-
**Optional** (enable specific capabilities; omit to run without that feature):
|
|
69
|
-
|
|
70
|
-
| Interface | Responsibility |
|
|
61
|
+
The protocol does not attempt to be:
|
|
62
|
+
|
|
63
|
+
- a global directory of people,
|
|
64
|
+
- a public search index,
|
|
65
|
+
- a social feed ranking protocol,
|
|
66
|
+
- a marketplace listing format,
|
|
67
|
+
- a replacement for human judgment,
|
|
68
|
+
- or a mechanism for bypassing consent, membership, or community boundaries.
|
|
69
|
+
|
|
70
|
+
## Terminology
|
|
71
|
+
|
|
72
|
+
| Term | Definition |
|
|
71
73
|
|---|---|
|
|
72
|
-
|
|
|
73
|
-
|
|
|
74
|
-
|
|
|
75
|
-
|
|
|
76
|
-
|
|
|
77
|
-
|
|
|
78
|
-
|
|
|
79
|
-
|
|
|
80
|
-
|
|
|
81
|
-
|
|
|
82
|
-
|
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
// tools is an array of LangChain Tool objects ready to bind to an agent
|
|
74
|
+
| **Participant** | A human principal represented in the network. A participant may act directly or through one or more agents. |
|
|
75
|
+
| **Agent** | A software actor authorized to act for a participant or community within a declared scope. |
|
|
76
|
+
| **Signal** | A participant's actionable expression of intent: what they seek, offer, need, are building, are exploring, or can support. |
|
|
77
|
+
| **Premise** | An atomic contextual claim about a participant, used to ground what signals are plausible or relevant. |
|
|
78
|
+
| **Context** | A synthesized representation of premises, history, constraints, and community-specific relevance. |
|
|
79
|
+
| **Community** | A bounded discovery scope with membership, purpose, norms, and relevance criteria. |
|
|
80
|
+
| **Membership** | The relationship between a participant and a community. Agents receive community authority through separate scoped permissions. |
|
|
81
|
+
| **Candidate** | A possible counterpart or opportunity component identified during discovery but not yet surfaced. |
|
|
82
|
+
| **Opportunity** | A candidate overlap that has passed evaluation and may be shown to one or more participants. |
|
|
83
|
+
| **Negotiation** | A bounded agent-to-agent exchange used to test fit, constraints, timing, or consent before surfacing or advancing an opportunity. |
|
|
84
|
+
| **Connection** | A participant-approved communication channel or introduction resulting from an accepted opportunity. |
|
|
85
|
+
|
|
86
|
+
Some implementation APIs may expose historical names such as `intent`, `index`, `network`, `latent`, `pending`, `accepted`, `rejected`, `negotiating`, or `stalled`. Public-facing agents SHOULD translate stable participant states into protocol terms such as **signal**, **community**, **draft**, **sent**, **connected**, and **declined**, while treating negotiating or stalled states as internal process state unless the participant needs to act on them.
|
|
87
|
+
|
|
88
|
+
## Object relationship model
|
|
89
|
+
|
|
90
|
+
```mermaid
|
|
91
|
+
erDiagram
|
|
92
|
+
PARTICIPANT ||--o{ AGENT : authorizes
|
|
93
|
+
PARTICIPANT ||--o{ SIGNAL : expresses
|
|
94
|
+
PARTICIPANT ||--o{ PREMISE : asserts
|
|
95
|
+
PARTICIPANT ||--o{ CONTEXT : represented_by
|
|
96
|
+
PARTICIPANT ||--o{ MEMBERSHIP : holds
|
|
97
|
+
AGENT ||--o{ AGENT_PERMISSION : receives
|
|
98
|
+
COMMUNITY ||--o{ MEMBERSHIP : contains
|
|
99
|
+
COMMUNITY ||--o{ AGENT_PERMISSION : scopes
|
|
100
|
+
COMMUNITY ||--o{ SIGNAL : scopes
|
|
101
|
+
COMMUNITY ||--o{ CONTEXT : lenses
|
|
102
|
+
SIGNAL ||--o{ CANDIDATE : generates
|
|
103
|
+
CONTEXT ||--o{ CANDIDATE : generates
|
|
104
|
+
CANDIDATE ||--o| OPPORTUNITY : promotes_to
|
|
105
|
+
OPPORTUNITY ||--o{ NEGOTIATION : may_require
|
|
106
|
+
OPPORTUNITY ||--o| CONNECTION : accepted_as
|
|
107
|
+
|
|
108
|
+
PARTICIPANT {
|
|
109
|
+
string principal
|
|
110
|
+
string consent_source
|
|
111
|
+
}
|
|
112
|
+
AGENT {
|
|
113
|
+
string authorization
|
|
114
|
+
string effective_scope
|
|
115
|
+
}
|
|
116
|
+
COMMUNITY {
|
|
117
|
+
string purpose
|
|
118
|
+
string membership_policy
|
|
119
|
+
}
|
|
120
|
+
SIGNAL {
|
|
121
|
+
string constraints
|
|
122
|
+
string lifecycle_state
|
|
123
|
+
}
|
|
124
|
+
OPPORTUNITY {
|
|
125
|
+
string explanation
|
|
126
|
+
string lifecycle_state
|
|
127
|
+
}
|
|
127
128
|
```
|
|
128
129
|
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
130
|
+
This model is conceptual rather than storage-prescriptive. Implementations MAY choose different table names or internal representations, but MUST preserve the same attribution, scope, and consent semantics.
|
|
131
|
+
|
|
132
|
+
## System model
|
|
133
|
+
|
|
134
|
+
### Principals
|
|
135
|
+
|
|
136
|
+
The protocol distinguishes human principals from software actors.
|
|
137
|
+
|
|
138
|
+
- A **participant** is the source of consent and personal context.
|
|
139
|
+
- An **agent** is an authorized actor. Every agent action MUST be attributable to a participant, a community, or both.
|
|
140
|
+
- A **community** may define local discovery norms, but it does not override participant consent.
|
|
141
|
+
|
|
142
|
+
### Scope
|
|
143
|
+
|
|
144
|
+
All discovery is scope-bound. A protocol operation MUST resolve an effective scope before cross-participant discovery, candidate generation, or opportunity evaluation. Implementations MAY read the requesting participant's own signals or context while preparing that operation.
|
|
145
|
+
|
|
146
|
+
A scope may include:
|
|
147
|
+
|
|
148
|
+
- a participant's personal community,
|
|
149
|
+
- one or more shared communities,
|
|
150
|
+
- an agent's assigned community scope,
|
|
151
|
+
- or a narrower request-time scope selected by the participant.
|
|
152
|
+
|
|
153
|
+
Agents MUST NOT use access to one community to infer, reveal, or act on information from another community unless the effective scope explicitly permits it.
|
|
154
|
+
|
|
155
|
+
Effective scope is the intersection of all applicable authority boundaries:
|
|
156
|
+
|
|
157
|
+
```mermaid
|
|
158
|
+
flowchart TD
|
|
159
|
+
Request[Request-time scope] --> Intersect[Intersect scopes]
|
|
160
|
+
ParticipantMemberships[Participant memberships] --> Intersect
|
|
161
|
+
AgentPermissions[Agent permissions] --> Intersect
|
|
162
|
+
CommunityPolicy[Community rules where implemented] --> Intersect
|
|
163
|
+
PersonalCommunity[Personal community boundary] --> Intersect
|
|
164
|
+
|
|
165
|
+
Intersect --> Empty{Empty intersection?}
|
|
166
|
+
Empty -->|yes| Deny[Deny discovery]
|
|
167
|
+
Empty -->|no| EffectiveScope[Effective scope]
|
|
168
|
+
EffectiveScope --> Reads[Permitted reads]
|
|
169
|
+
EffectiveScope --> Writes[Permitted writes]
|
|
170
|
+
EffectiveScope --> Evaluation[Permitted evaluation]
|
|
171
|
+
|
|
172
|
+
Reads --> Audit[Attributable audit trail]
|
|
173
|
+
Writes --> Audit
|
|
174
|
+
Evaluation --> Audit
|
|
154
175
|
```
|
|
155
176
|
|
|
156
|
-
|
|
157
|
-
`.createGraph()` method that returns a compiled LangGraph ready for `.invoke()`.
|
|
177
|
+
A broader credential MUST NOT expand a narrower request. A narrower agent permission MUST clamp a broader participant membership. Community-specific policy checks MAY further reduce effective scope where an implementation defines them.
|
|
158
178
|
|
|
159
|
-
|
|
179
|
+
### Public and private surfaces
|
|
180
|
+
|
|
181
|
+
The protocol separates internal state from participant-facing language.
|
|
182
|
+
|
|
183
|
+
Internal records MAY contain IDs, embeddings, scores, graph state, and tool names. Participant-facing responses MUST NOT expose these implementation details unless an identifier is directly actionable by the participant, such as a conversation identifier needed to open an accepted connection.
|
|
184
|
+
|
|
185
|
+
## Core objects
|
|
186
|
+
|
|
187
|
+
### Signal
|
|
188
|
+
|
|
189
|
+
A signal is an actionable statement of direction. It may represent a need, offer, collaboration interest, hiring intent, funding goal, research direction, introduction request, or other future-oriented constraint.
|
|
190
|
+
|
|
191
|
+
A signal SHOULD contain enough specificity to support discovery. Underspecified signals SHOULD enter clarification before they are persisted or used for broad discovery.
|
|
192
|
+
|
|
193
|
+
Signals have the following conceptual lifecycle:
|
|
194
|
+
|
|
195
|
+
| State | Meaning |
|
|
160
196
|
|---|---|
|
|
161
|
-
|
|
|
162
|
-
|
|
|
163
|
-
|
|
|
164
|
-
|
|
|
165
|
-
|
|
|
166
|
-
| `NegotiationGraphFactory` | Multi-turn bilateral negotiation flows |
|
|
167
|
-
| `HydeGraphFactory` | Generate hypothetical documents and embed them (cache-aware) |
|
|
168
|
-
| `NetworkGraphFactory` | Manage index/network CRUD |
|
|
169
|
-
| `NetworkMembershipGraphFactory` | Manage index/network member join/leave |
|
|
170
|
-
| `IntentNetworkGraphFactory` | Evaluate and assign/unassign intents to indexes |
|
|
171
|
-
| `HomeGraphFactory` | Categorize and curate home-feed content |
|
|
172
|
-
| `MaintenanceGraphFactory` | Periodic maintenance (feed health, opportunity expiration) |
|
|
173
|
-
|
|
174
|
-
## MCP server
|
|
175
|
-
|
|
176
|
-
The package exports a factory that registers every chat tool over the Model Context Protocol and attaches a canonical `instructions` block (`MCP_INSTRUCTIONS`) that every connecting runtime follows. The factory takes three arguments:
|
|
177
|
-
|
|
178
|
-
```typescript
|
|
179
|
-
import { createMcpServer, type McpAuthResolver } from "@indexnetwork/protocol";
|
|
180
|
-
|
|
181
|
-
const authResolver: McpAuthResolver = {
|
|
182
|
-
async resolveIdentity(req) {
|
|
183
|
-
// Look up the API key in `x-api-key` and return { userId, agentId? }.
|
|
184
|
-
// `agentId` should come from Better Auth token metadata so downstream
|
|
185
|
-
// tool handlers can attribute every call to a concrete agent identity.
|
|
186
|
-
return resolveFromApiKey(req);
|
|
187
|
-
},
|
|
188
|
-
};
|
|
189
|
-
|
|
190
|
-
const server = createMcpServer(
|
|
191
|
-
deps,
|
|
192
|
-
authResolver,
|
|
193
|
-
{
|
|
194
|
-
// Per-request factory for scoped user/system databases.
|
|
195
|
-
create: (userId, indexScope) => createScopedDeps(userId, indexScope),
|
|
196
|
-
},
|
|
197
|
-
);
|
|
198
|
-
```
|
|
197
|
+
| **Proposed** | A participant or agent supplied raw intent-like input. |
|
|
198
|
+
| **Clarifying** | The protocol requires additional constraints before discovery. |
|
|
199
|
+
| **Active** | The signal is valid, scoped, and eligible for discovery. |
|
|
200
|
+
| **Updated** | The participant refined or replaced constraints. |
|
|
201
|
+
| **Archived / expired** | The signal should no longer produce new opportunities. |
|
|
199
202
|
|
|
200
|
-
|
|
203
|
+
A signal MUST NOT be treated as active if it is outside the participant's authority, obviously insincere, unsafe to act on, or too vague to evaluate.
|
|
201
204
|
|
|
202
|
-
|
|
203
|
-
2. Calls `authResolver.resolveIdentity(req)` to get `{ userId, agentId }`.
|
|
204
|
-
3. Gates access: MCP callers without a resolved `agentId` are blocked from every tool except `register_agent`, `read_docs`, and `scrape_url` until they register.
|
|
205
|
-
4. Builds per-request scoped databases via `scopedDepsFactory` and invokes the tool handler through the shared runtime.
|
|
205
|
+
### Premise and context
|
|
206
206
|
|
|
207
|
-
|
|
207
|
+
A premise is a small claim about a participant: background, role, current work, capability, location, affiliation, constraint, or declared preference. Premises ground discovery by determining whether a signal is plausible and which communities or counterparts are relevant.
|
|
208
208
|
|
|
209
|
-
|
|
209
|
+
Context is derived from premises. Context MAY be global to a participant or specific to a community. Community-specific context SHOULD emphasize facts relevant to that community's purpose and suppress irrelevant detail.
|
|
210
210
|
|
|
211
|
-
|
|
212
|
-
|---|---:|---|
|
|
213
|
-
| `fast` | 10 s | `MCP_TOOL_TIMEOUT_FAST_MS` |
|
|
214
|
-
| `bounded_slow` | 45 s | `MCP_TOOL_TIMEOUT_BOUNDED_SLOW_MS` |
|
|
215
|
-
| `async_candidate` | 50 s | `MCP_TOOL_TIMEOUT_ASYNC_CANDIDATE_MS` |
|
|
211
|
+
Premise and context updates SHOULD cause downstream discovery representations to refresh. Stale context SHOULD NOT be used when fresher participant-approved context exists.
|
|
216
212
|
|
|
217
|
-
|
|
213
|
+
### Community
|
|
218
214
|
|
|
219
|
-
|
|
215
|
+
A community is a bounded discovery environment. It defines who can participate, what kinds of signals are relevant, and which discovery operations are legitimate.
|
|
220
216
|
|
|
221
|
-
|
|
217
|
+
A community SHOULD have:
|
|
222
218
|
|
|
223
|
-
|
|
219
|
+
- a purpose or prompt,
|
|
220
|
+
- membership rules,
|
|
221
|
+
- agent permissions,
|
|
222
|
+
- relevance expectations,
|
|
223
|
+
- and privacy expectations.
|
|
224
224
|
|
|
225
|
-
|
|
225
|
+
The participant's personal community represents trusted contacts and direct relationships. It is not equivalent to a public audience.
|
|
226
226
|
|
|
227
|
-
|
|
227
|
+
### Opportunity
|
|
228
228
|
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
229
|
+
An opportunity is an evaluated overlap between participants. It is not merely a candidate returned by retrieval. It must be specific enough to explain and safe enough to surface.
|
|
230
|
+
|
|
231
|
+
An opportunity SHOULD include:
|
|
232
|
+
|
|
233
|
+
- participating roles,
|
|
234
|
+
- the relevant signal or context on each side,
|
|
235
|
+
- a concise explanation of fit,
|
|
236
|
+
- a recommended next action,
|
|
237
|
+
- lifecycle state,
|
|
238
|
+
- and visibility rules for each participant.
|
|
239
|
+
|
|
240
|
+
Opportunity states are participant-facing as follows:
|
|
241
|
+
|
|
242
|
+
| State | Participant-facing term | Meaning |
|
|
243
|
+
|---|---|---|
|
|
244
|
+
| **Draft** | Draft | The protocol found a plausible opportunity, but it has not been sent to the other side. |
|
|
245
|
+
| **Sent** | Sent | One side has sent or received the opportunity and a response is pending. |
|
|
246
|
+
| **Connected** | Connected | Required participants accepted and a conversation or introduction may proceed. |
|
|
247
|
+
| **Declined** | Declined | A participant rejected the opportunity. |
|
|
248
|
+
| **Expired** | Expired | The opportunity is no longer actionable. |
|
|
249
|
+
|
|
250
|
+
A conforming agent MUST NOT present a received opportunity as **Connected** without explicit approval from the receiving participant. The reference implementation enforces actor authorization and valid source statuses for acceptance, while current-approval capture is handled by the agent or user-interface flow invoking the transition.
|
|
251
|
+
|
|
252
|
+
### Opportunity lifecycle
|
|
253
|
+
|
|
254
|
+
```mermaid
|
|
255
|
+
stateDiagram-v2
|
|
256
|
+
[*] --> Draft: candidate promoted
|
|
257
|
+
Draft --> Sent: sender approves send
|
|
258
|
+
Draft --> Connected: direct acceptance or connection link
|
|
259
|
+
Draft --> Declined: sender declines
|
|
260
|
+
Draft --> Expired: TTL or invalidated
|
|
261
|
+
|
|
262
|
+
Sent --> Connected: recipient explicitly accepts
|
|
263
|
+
Sent --> Declined: recipient declines
|
|
264
|
+
Sent --> Expired: TTL or invalidated
|
|
234
265
|
|
|
235
|
-
|
|
266
|
+
Connected --> [*]
|
|
267
|
+
Declined --> [*]
|
|
268
|
+
Expired --> [*]
|
|
236
269
|
|
|
237
|
-
|
|
270
|
+
note right of Draft
|
|
271
|
+
Plausible but not sent.
|
|
272
|
+
Only visible under role and scope rules.
|
|
273
|
+
end note
|
|
238
274
|
|
|
239
|
-
|
|
240
|
-
|
|
241
|
-
|
|
275
|
+
note right of Sent
|
|
276
|
+
One side is waiting.
|
|
277
|
+
Acceptance requires participant approval.
|
|
278
|
+
end note
|
|
242
279
|
|
|
243
|
-
|
|
244
|
-
|
|
280
|
+
note right of Connected
|
|
281
|
+
Relationship boundary crossed.
|
|
282
|
+
Conversation or introduction may proceed.
|
|
283
|
+
end note
|
|
245
284
|
```
|
|
246
285
|
|
|
247
|
-
|
|
286
|
+
## Discovery procedure
|
|
287
|
+
|
|
288
|
+
A conforming discovery flow has seven phases.
|
|
289
|
+
|
|
290
|
+
```mermaid
|
|
291
|
+
sequenceDiagram
|
|
292
|
+
autonumber
|
|
293
|
+
participant P as Participant
|
|
294
|
+
participant A as Agent
|
|
295
|
+
participant PR as Protocol runtime
|
|
296
|
+
participant C as Community scope
|
|
297
|
+
participant N as Counterparty agent
|
|
298
|
+
|
|
299
|
+
P->>A: Provide context and signal
|
|
300
|
+
A->>PR: Admit signal and construct context
|
|
301
|
+
PR->>C: Resolve effective scope
|
|
302
|
+
C-->>PR: Permitted communities
|
|
303
|
+
PR->>PR: Generate candidates inside scope
|
|
304
|
+
PR->>PR: Evaluate role fit and constraints
|
|
305
|
+
alt Fit is clear
|
|
306
|
+
PR-->>A: Draft opportunity with explanation
|
|
307
|
+
else Fit is uncertain
|
|
308
|
+
PR->>N: Start bounded negotiation
|
|
309
|
+
N-->>PR: Propose, counter, accept, reject, or question
|
|
310
|
+
PR-->>A: Draft opportunity or structured question
|
|
311
|
+
end
|
|
312
|
+
A->>P: Explain strongest reason and ask for approval
|
|
313
|
+
P-->>A: Approve, decline, or refine signal
|
|
314
|
+
A->>PR: Advance lifecycle only if approved
|
|
315
|
+
```
|
|
316
|
+
|
|
317
|
+
### 1. Context construction
|
|
318
|
+
|
|
319
|
+
The protocol collects participant-provided or participant-authorized material and turns it into premises and context. Context construction MUST preserve provenance and SHOULD prefer participant-approved information over inferred information.
|
|
320
|
+
|
|
321
|
+
### 2. Signal admission
|
|
322
|
+
|
|
323
|
+
The protocol evaluates a proposed signal for specificity, sincerity, authority, and safety. If the signal is too broad, ambiguous, or missing critical constraints, the agent SHOULD ask focused clarification questions before running discovery.
|
|
324
|
+
|
|
325
|
+
### 3. Scope resolution
|
|
326
|
+
|
|
327
|
+
The protocol determines the effective communities in which the signal can operate. Scope resolution MUST intersect participant membership, agent permissions, and request-time constraints. If the intersection is empty, discovery MUST NOT proceed.
|
|
328
|
+
|
|
329
|
+
### 4. Candidate generation
|
|
330
|
+
|
|
331
|
+
The protocol generates candidates by comparing signals and context inside the effective scope. Candidate generation MAY use multiple strategies, including signal-to-signal, context-to-signal, premise-to-premise, semantic retrieval, and directed target construction.
|
|
332
|
+
|
|
333
|
+
Candidate generation is not surfacing. Candidate data MUST remain internal until evaluation and visibility checks pass.
|
|
334
|
+
|
|
335
|
+
### 5. Evaluation
|
|
336
|
+
|
|
337
|
+
The protocol evaluates candidates for role fit, constraint satisfaction, credibility, reciprocity, timing, and explainability. A candidate SHOULD be rejected or retained as internal evidence if the protocol cannot produce a clear reason for surfacing it.
|
|
338
|
+
|
|
339
|
+
### 6. Negotiation
|
|
340
|
+
|
|
341
|
+
When fit is plausible but uncertain, agents MAY negotiate. Negotiation MUST be bounded. It SHOULD clarify constraints, test mutual relevance, and decide among a small set of actions: propose, counter, accept, reject, or ask a question. Implementations MAY persist an opportunity before negotiation completes and then update its public state from the negotiation outcome.
|
|
342
|
+
|
|
343
|
+
If negotiation requires human judgment, the agent SHOULD stop and ask the participant a small number of structured questions rather than fabricating preferences.
|
|
344
|
+
|
|
345
|
+
### 7. Surfacing and acceptance
|
|
346
|
+
|
|
347
|
+
The protocol surfaces the opportunity according to role and lifecycle visibility. Participant-facing presentation SHOULD include the strongest reason for relevance and a clear next action. Sending, accepting, or connecting MUST require participant consent at the relevant boundary.
|
|
348
|
+
|
|
349
|
+
## Agent requirements
|
|
248
350
|
|
|
249
|
-
|
|
351
|
+
A conforming agent MUST:
|
|
250
352
|
|
|
251
|
-
|
|
252
|
-
|
|
353
|
+
- act only within its authenticated participant and community scope,
|
|
354
|
+
- preserve participant consent at send, accept, and connection boundaries,
|
|
355
|
+
- avoid exposing internal IDs, raw tool results, embeddings, scores, or database field names,
|
|
356
|
+
- distinguish known facts from inferred context,
|
|
357
|
+
- ask for clarification when required information is missing,
|
|
358
|
+
- use the protocol vocabulary in participant-facing output,
|
|
359
|
+
- avoid fabricating participants, opportunities, constraints, or outcomes,
|
|
360
|
+
- and provide concise explanations for surfaced opportunities.
|
|
361
|
+
|
|
362
|
+
A conforming agent SHOULD:
|
|
363
|
+
|
|
364
|
+
- surface the top one to three relevant points by default,
|
|
365
|
+
- prefer first names unless disambiguation is required,
|
|
366
|
+
- explain why an opportunity is relevant before asking for action,
|
|
367
|
+
- treat silence, timeouts, or failed negotiation as uncertainty rather than consent,
|
|
368
|
+
- and record enough trace information for later audit by authorized operators.
|
|
369
|
+
|
|
370
|
+
A conforming agent MUST NOT:
|
|
371
|
+
|
|
372
|
+
- describe discovery as public search,
|
|
373
|
+
- use community access to leak out-of-scope participant information,
|
|
374
|
+
- accept a received opportunity without explicit current approval,
|
|
375
|
+
- present internal confidence scores as objective truth,
|
|
376
|
+
- or continue negotiation after a terminal decision.
|
|
377
|
+
|
|
378
|
+
## Privacy and safety invariants
|
|
379
|
+
|
|
380
|
+
The following invariants define the protocol's trust boundary:
|
|
381
|
+
|
|
382
|
+
1. **Scope invariant** — discovery reads and writes MUST remain inside the effective scope.
|
|
383
|
+
2. **Consent invariant** — relationship-forming transitions MUST be participant-approved.
|
|
384
|
+
3. **Attribution invariant** — every agent action MUST be attributable to an authorized principal.
|
|
385
|
+
4. **Legibility invariant** — surfaced opportunities SHOULD be explainable in participant-facing language.
|
|
386
|
+
5. **Minimization invariant** — participant-facing output SHOULD reveal only what is needed for the next decision.
|
|
387
|
+
6. **No-fabrication invariant** — agents MUST NOT invent facts to complete an opportunity narrative.
|
|
388
|
+
7. **Terminality invariant** — declined, expired, or otherwise terminal opportunities SHOULD NOT produce further automatic advancement unless explicitly reopened or changed through an authorized protocol action.
|
|
389
|
+
|
|
390
|
+
## Interoperability
|
|
391
|
+
|
|
392
|
+
The reference implementation exposes the protocol to agents through a Model Context Protocol (MCP) server and typed package APIs. MCP is the preferred interoperability surface for external agents because it provides tool discovery, runtime instructions, identity resolution, and bounded tool invocation.
|
|
393
|
+
|
|
394
|
+
```mermaid
|
|
395
|
+
flowchart LR
|
|
396
|
+
ExternalAgent[External agent] -->|MCP tools| McpServer[Index Network MCP server]
|
|
397
|
+
FirstPartyAgent[First-party agent] -->|typed runtime| Runtime[Protocol runtime]
|
|
398
|
+
PersonalAgent[Personal agent] -->|MCP tools or REST polling| McpServer
|
|
399
|
+
|
|
400
|
+
McpServer --> Identity[Identity resolution]
|
|
401
|
+
Identity --> AgentGate[Agent registration and scope]
|
|
402
|
+
AgentGate --> ScopedDeps[Scoped protocol dependencies]
|
|
403
|
+
ScopedDeps --> Runtime
|
|
404
|
+
|
|
405
|
+
Runtime --> Tools[Protocol tools]
|
|
406
|
+
Tools --> Graphs[Discovery, context, signal, negotiation graphs]
|
|
407
|
+
Graphs --> Results[Bounded results]
|
|
408
|
+
Results --> Runtime
|
|
409
|
+
Runtime --> ParticipantOutput[Participant-facing output rules]
|
|
253
410
|
```
|
|
411
|
+
|
|
412
|
+
|
|
413
|
+
Implementations MAY expose additional transports, but they SHOULD preserve the same protocol semantics:
|
|
414
|
+
|
|
415
|
+
- authenticated principal resolution,
|
|
416
|
+
- scoped access,
|
|
417
|
+
- consent-gated opportunity transitions,
|
|
418
|
+
- structured discovery and negotiation operations,
|
|
419
|
+
- and participant-facing output rules.
|
|
420
|
+
|
|
421
|
+
## Reference implementation
|
|
422
|
+
|
|
423
|
+
The canonical TypeScript implementation is `@indexnetwork/protocol`.
|
|
424
|
+
|
|
425
|
+
- [IMPLEMENTATION.md](./IMPLEMENTATION.md) — package installation, adapters, graph factories, MCP server usage, and publishing.
|
|
426
|
+
- [STABILITY.md](./STABILITY.md) — public API contract and SemVer policy.
|
|
427
|
+
- [CHANGELOG.md](./CHANGELOG.md) — release history.
|
package/STABILITY.md
ADDED
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
# Stability & Versioning Policy
|
|
2
|
+
|
|
3
|
+
`@indexnetwork/protocol` is a published, versioned package consumed by the Index
|
|
4
|
+
Network backend and by external integrators. This document defines what the
|
|
5
|
+
public contract **is**, which parts are stable, and what counts as a breaking
|
|
6
|
+
change. It is the reference behind the tier annotations in `src/index.ts`.
|
|
7
|
+
|
|
8
|
+
## The public contract
|
|
9
|
+
|
|
10
|
+
- The **only** supported entry point is the package root:
|
|
11
|
+
`import { ... } from "@indexnetwork/protocol"`.
|
|
12
|
+
- Deep imports (`@indexnetwork/protocol/dist/...` or `/src/...`) are **not** part
|
|
13
|
+
of the contract and may change or disappear in any release — do not rely on them.
|
|
14
|
+
- The contract is exactly the set of symbols re-exported from `src/index.ts`.
|
|
15
|
+
Exports are listed explicitly (no `export *` wildcards), so the surface is
|
|
16
|
+
reviewable and additions are always intentional.
|
|
17
|
+
|
|
18
|
+
## Stability tiers
|
|
19
|
+
|
|
20
|
+
Each section of the barrel carries one of two tiers.
|
|
21
|
+
|
|
22
|
+
### Stable
|
|
23
|
+
|
|
24
|
+
Covered by SemVer below. Breaking changes require a **major** bump.
|
|
25
|
+
|
|
26
|
+
| Barrel section | What it is |
|
|
27
|
+
|---|---|
|
|
28
|
+
| **Public API** | `createChatTools`, model config helpers, tool/runtime helpers (`ToolContext`, `ToolDeps`, `invokeToolRuntime`, …), `requestContext`. |
|
|
29
|
+
| **Interfaces** | Every `*.interface.ts` port you implement to inject infrastructure (databases, embedder, cache, scraper, queues, integration, agent dispatcher, …). |
|
|
30
|
+
| **Shared schemas** | Zod schemas + inferred types that cross the boundary (questions, identity, network-assignment, chat-context, …). |
|
|
31
|
+
| **Graph factories** | `*GraphFactory` classes (`ChatGraphFactory`, `OpportunityGraphFactory`, `NegotiationGraphFactory`, …). |
|
|
32
|
+
| **Agents** | Structured LLM agents (`UserContextGenerator`, `IndexNegotiator`, `OpportunityEvaluator`, …). |
|
|
33
|
+
| **MCP** | `createMcpServer` and its supporting types. |
|
|
34
|
+
|
|
35
|
+
### Experimental
|
|
36
|
+
|
|
37
|
+
Marked `@experimental` in `src/index.ts`. May change in a **minor** release without
|
|
38
|
+
a major bump. Use at your own risk and pin a version if you depend on them.
|
|
39
|
+
|
|
40
|
+
| Area | What it is |
|
|
41
|
+
|---|---|
|
|
42
|
+
| **States** | Advanced graph-state shapes (`UserNegotiationContext`, `NegotiationTurn`, `NegotiationGraphLike`, …) exposed for advanced graph consumers. |
|
|
43
|
+
| **Internal helpers** | Low-level support utilities re-exported for the backend's own use (selection/eval/evidence helpers) that are not part of the recommended integration surface. |
|
|
44
|
+
|
|
45
|
+
> Most symbols in the barrel are consumed by the Index Network backend itself; a
|
|
46
|
+
> symbol being absent from the backend's imports does **not** make it dead — it may
|
|
47
|
+
> serve external integrators. Removal therefore follows the deprecation path below,
|
|
48
|
+
> never an ad-hoc delete.
|
|
49
|
+
|
|
50
|
+
## SemVer policy
|
|
51
|
+
|
|
52
|
+
This package follows [Semantic Versioning 2.0.0](https://semver.org/).
|
|
53
|
+
|
|
54
|
+
**MAJOR** — incompatible changes to the Stable surface:
|
|
55
|
+
- Removing or renaming a stable export.
|
|
56
|
+
- Adding a required method/field to an implemented interface, or tightening a
|
|
57
|
+
return type (e.g. `T | null` → `T` is fine; `T` → `T | null` is breaking).
|
|
58
|
+
- Changing the runtime behavior a documented port contract guarantees
|
|
59
|
+
(ownership scoping, null-vs-throw semantics, lifecycle idempotency).
|
|
60
|
+
|
|
61
|
+
**MINOR** — backward-compatible additions:
|
|
62
|
+
- New exports; new **optional** interface members; new graph factories/agents.
|
|
63
|
+
- Any change to an `@experimental` symbol.
|
|
64
|
+
|
|
65
|
+
**PATCH** — backward-compatible fixes:
|
|
66
|
+
- Bug fixes, performance, prompt/model tuning, doc and type-comment changes that
|
|
67
|
+
do not alter the contract.
|
|
68
|
+
|
|
69
|
+
### Port-contract semantics count
|
|
70
|
+
|
|
71
|
+
Interface ports document invariants in their TSDoc/banner comments — ownership
|
|
72
|
+
scoping (return `null` for missing **or** non-owned rows), null-vs-empty-array
|
|
73
|
+
conventions, and lifecycle idempotency (`mark*` transitions are no-ops once
|
|
74
|
+
terminal). These guarantees are part of the Stable contract: breaking them is a
|
|
75
|
+
**major** change even if the TypeScript signature is unchanged.
|
|
76
|
+
|
|
77
|
+
## Deprecation path
|
|
78
|
+
|
|
79
|
+
1. Mark the symbol `@deprecated` in TSDoc with the replacement and target removal version.
|
|
80
|
+
2. Note it under `### Deprecated` in `CHANGELOG.md`.
|
|
81
|
+
3. Keep it working for at least one minor release.
|
|
82
|
+
4. Remove only in a subsequent **major** release.
|
|
83
|
+
|
|
84
|
+
## Release & publish
|
|
85
|
+
|
|
86
|
+
- Pushes to `dev` publish an `-rc.<n>` prerelease under the npm `rc` tag.
|
|
87
|
+
- Pushes to `main` publish the stable version under `latest` when the
|
|
88
|
+
`package.json` version is new (already-published versions are skipped).
|
|
89
|
+
- Bump `package.json` and update `CHANGELOG.md` **before** promoting to `main`.
|
|
90
|
+
|
|
91
|
+
See `.github/workflows/publish.yml` for the automation and `CHANGELOG.md` for the
|
|
92
|
+
release history.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@indexnetwork/protocol",
|
|
3
|
-
"version": "4.3.
|
|
3
|
+
"version": "4.3.2-rc.300.1",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"main": "./dist/index.js",
|
|
6
6
|
"types": "./dist/index.d.ts",
|
|
@@ -11,7 +11,10 @@
|
|
|
11
11
|
}
|
|
12
12
|
},
|
|
13
13
|
"files": [
|
|
14
|
-
"dist"
|
|
14
|
+
"dist",
|
|
15
|
+
"IMPLEMENTATION.md",
|
|
16
|
+
"STABILITY.md",
|
|
17
|
+
"CHANGELOG.md"
|
|
15
18
|
],
|
|
16
19
|
"scripts": {
|
|
17
20
|
"build": "tsc",
|