Add MIP-07: AI Inference Pool#56
Conversation
Defines an AI inference pool for Marmot groups. A designated executor forwards member prompts to an AI provider and relays results back to the group. Members gain shared access to models while individual authorship remains obscured. Three message kinds (9706-9708) reusing existing Marmot primitives. Stateless protocol: multi-turn handled at client level. Optional executor rotation for cost and risk distribution.
WalkthroughIntroduces MIP-07, a new protocol specification document defining an AI inference pool system for Marmot groups. Establishes three MLS-based event kinds, workflow specifications, privacy mechanisms, threat model, and executor behavior guidelines with versioning and implementation requirements. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
MIP-07.md (1)
223-230: Attachment support is underspecified.Clients are asked to support encrypted file attachments, but the 9707/9708 schemas above never define how an attachment reference is encoded or which tags are required. That leaves implementations guessing about the wire format. Please add the tag shape and whether attachments are allowed on submissions, results, or both.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@MIP-07.md` around lines 223 - 230, The MIP asks clients to support encrypted file attachments but the 9707/9708 schemas (and the MIP-04 media encryption reference) never define the attachment reference shape or where attachments may appear; update the spec to add a concrete attachment tag shape (e.g., an "attachment" object with fields: media_type, url_or_cid, encryption_metadata {alg, key_id, iv, tag}, size, and optional filename) and explicitly state whether attachments are permitted on "submission" messages, "result" messages, or both; reference the 9707/9708 schema sections and MIP-04 for encryption field definitions and add required/optional tag semantics and validation rules for the attachment object so implementers know the wire format and placement.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@MIP-07.md`:
- Around line 78-79: The statement claiming “duplicate discard by `pool_id`
prevents duplicate results” is too strong; update the wording around
`rotation_order`, executor handoff, and handling of kind 9708 to indicate
duplicates MAY occur during rotation races (outgoing and incoming executors can
both emit kind 9708 before seeing each other’s event) and therefore clients and
executors MUST treat `pool_id` idempotently and de-duplicate results on receipt;
explicitly replace absolute language with “may produce duplicates” and add a
requirement that handlers of kind 9708 and any rotation-related logic use
`pool_id`-based idempotency.
- Around line 30-32: In MIP-07.md replace all plain MIP cross-references (e.g.
"MIP-01", "MIP-03", "MIP-04") with markdown links in the format [MIP-XX](XX.md)
so references become navigable (for example "MIP-03" → "[MIP-03](03.md)");
update every occurrence noted in the review (including the blocks around lines
30-32, 74, 216-229, and 237-239) and any other occurrences in the file to use
the [MIP-XX](XX.md) pattern consistently. Ensure you do not alter other text or
code (keep event-kind text like 9706/9707/9708 intact) and only convert plain
MIP identifiers to the linked form.
- Line 146: Update the normative sentence in MIP-07.md to use RFC 2119 wording:
replace lowercase “should publish a result with `status: "rejected"`” with the
appropriate RFC 2119 term (e.g., “SHOULD publish a result with `status:
"rejected"`” or “MUST publish a result with `status: "rejected"`”) to make the
requirement normative and consistent with spec guidelines.
- Line 74: Replace the rule that selects the "most recent valid configuration
(by `created_at` timestamp)" with a deterministic conflict-resolution policy:
require admins to include a monotonic sequence/version field (e.g., `version` or
`sequence_number`) in Pool Configuration messages and specify that clients must
prefer higher sequence numbers and use `created_at` only as a last resort, or
alternatively specify that the MLS delivery order within the enclosing kind 445
event is the authoritative tie-breaker; update the text around `created_at`,
`admin_pubkeys`, and "kind 445" to mandate and describe this deterministic
secondary rule so all clients resolve conflicts identically.
---
Nitpick comments:
In `@MIP-07.md`:
- Around line 223-230: The MIP asks clients to support encrypted file
attachments but the 9707/9708 schemas (and the MIP-04 media encryption
reference) never define the attachment reference shape or where attachments may
appear; update the spec to add a concrete attachment tag shape (e.g., an
"attachment" object with fields: media_type, url_or_cid, encryption_metadata
{alg, key_id, iv, tag}, size, and optional filename) and explicitly state
whether attachments are permitted on "submission" messages, "result" messages,
or both; reference the 9707/9708 schema sections and MIP-04 for encryption field
definitions and add required/optional tag semantics and validation rules for the
attachment object so implementers know the wire format and placement.
| All pool messages are MLS Application Messages within Group Events (kind: 445) per MIP-03. **CRITICAL:** Per MIP-03 security requirements, all inner events MUST remain unsigned (no `sig` field) and MUST NOT include `h` tags or other group identifiers. | ||
|
|
||
| This MIP uses event kinds 9706, 9707, and 9708. These kinds exist exclusively within MLS-encrypted group events and are never published directly to relays. Implementations SHOULD ignore unrecognized kinds in the 9700–9799 range gracefully. |
There was a problem hiding this comment.
Use linked MIP references consistently.
The document still references MIP-01, MIP-03, and MIP-04 as plain text in several places. Please switch those to [MIP-01](01.md), [MIP-03](03.md), etc., so cross-references are consistent and navigable. As per coding guidelines, *.md: Reference other MIPs using [MIP-XX](XX.md) format in cross-references.
Also applies to: 74-74, 216-229, 237-239
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@MIP-07.md` around lines 30 - 32, In MIP-07.md replace all plain MIP
cross-references (e.g. "MIP-01", "MIP-03", "MIP-04") with markdown links in the
format [MIP-XX](XX.md) so references become navigable (for example "MIP-03" →
"[MIP-03](03.md)"); update every occurrence noted in the review (including the
blocks around lines 30-32, 74, 216-229, and 237-239) and any other occurrences
in the file to use the [MIP-XX](XX.md) pattern consistently. Ensure you do not
alter other text or code (keep event-kind text like 9706/9707/9708 intact) and
only convert plain MIP identifiers to the linked form.
|
|
||
| #### Configuration Authority | ||
|
|
||
| **CRITICAL:** Only group admins (as defined in `admin_pubkeys` per MIP-01) MAY publish Pool Configuration messages. Clients MUST verify admin status before processing configuration updates. The most recent valid configuration (by `created_at` timestamp) takes precedence. |
There was a problem hiding this comment.
Don't use created_at as the sole conflict resolver.
created_at is sender-controlled and can collide or skew across admins/executors, so different clients can pick different “latest” configs or different “first” results. The spec needs a deterministic secondary rule here (for example MLS delivery order within the enclosing kind 445 event, or an explicit monotonically increasing sequence/version tag).
Also applies to: 221-221
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@MIP-07.md` at line 74, Replace the rule that selects the "most recent valid
configuration (by `created_at` timestamp)" with a deterministic
conflict-resolution policy: require admins to include a monotonic
sequence/version field (e.g., `version` or `sequence_number`) in Pool
Configuration messages and specify that clients must prefer higher sequence
numbers and use `created_at` only as a last resort, or alternatively specify
that the MLS delivery order within the enclosing kind 445 event is the
authoritative tie-breaker; update the text around `created_at`, `admin_pubkeys`,
and "kind 445" to mandate and describe this deterministic secondary rule so all
clients resolve conflicts identically.
| When rotation is configured, the admin cycles through `rotation_order`, publishing a new config for each transition. When a new configuration is published, the outgoing executor is expected to complete or reject pending prompts. The incoming executor picks up any that remain unresolved — duplicate discard by `pool_id` prevents duplicate results. Unavailable executors are skipped based on rejection messages, unanswered prompts, or out-of-band communication. | ||
|
|
There was a problem hiding this comment.
Rotation handoff can still publish duplicate results.
“Duplicate discard by pool_id prevents duplicate results” is stronger than the protocol can actually guarantee. During executor rotation, the outgoing and incoming executors can race and both emit kind 9708 before seeing each other’s event. Please reword this so duplicates MAY occur and clients/executors MUST handle pool_id idempotently.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@MIP-07.md` around lines 78 - 79, The statement claiming “duplicate discard by
`pool_id` prevents duplicate results” is too strong; update the wording around
`rotation_order`, executor handoff, and handling of kind 9708 to indicate
duplicates MAY occur during rotation races (outgoing and incoming executors can
both emit kind 9708 before seeing each other’s event) and therefore clients and
executors MUST treat `pool_id` idempotently and de-duplicate results on receipt;
explicitly replace absolute language with “may produce duplicates” and add a
requirement that handlers of kind 9708 and any rotation-related logic use
`pool_id`-based idempotency.
| | `reason` | Machine-readable reason code for rejections or errors. Values: `tos_violation`, `rate_limited`, `model_unavailable`, `prompt_too_long`, `quota_exhausted`, `other`. Present when `status` is `"rejected"` or `"error"`. | Conditional | | ||
| | `detail` | Human-readable explanation providing additional context. Present when `status` is `"rejected"` or `"error"`. | No | | ||
|
|
||
| Rejection is always preferable to silent drops. If the executor cannot run a prompt for any reason, they should publish a result with `status: "rejected"` rather than ignoring the prompt. |
There was a problem hiding this comment.
Use RFC 2119 wording for this requirement.
This is normative executor behavior, so lowercase “should” weakens the spec. Use SHOULD publish or MUST publish here, depending on how strict you want rejection handling to be. As per coding guidelines, *.md: Use RFC 2119 terminology (MUST/SHOULD/MAY) for requirements in protocol specifications.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@MIP-07.md` at line 146, Update the normative sentence in MIP-07.md to use RFC
2119 wording: replace lowercase “should publish a result with `status:
"rejected"`” with the appropriate RFC 2119 term (e.g., “SHOULD publish a result
with `status: "rejected"`” or “MUST publish a result with `status: "rejected"`”)
to make the requirement normative and consistent with spec guidelines.
|
@RogueFantasy appreciate the PR but this isn't going to be a priority for now. it's unlikely we'll have a chance to really dig into this proposal for a few weeks/months. |
2 participants
Defines an AI inference pool for Marmot groups. A designated executor forwards member prompts to an AI provider and relays results back to the group. Members gain shared access to models while individual authorship remains obscured.
Three message kinds (9706-9708) reusing existing Marmot primitives. Stateless protocol: multi-turn handled at client level. Optional executor rotation for cost and risk distribution.
Summary by CodeRabbit