MindFront Fiber Changelog

v3 → v4

Fiber v4 is a backward-compatible update that adds a business event channel. A module can now stream events into MindFront — new orders, status changes, anything you’d want to surface in the inbox or trigger downstream work on.

Opt-in via /meta

Set "servesEvents": true on your /meta response. Modules that don’t set it are unchanged: MindFront skips the events poll entirely.

{
  "protocolVersion": 4,
  "moduleVersion": "1.2.0",
  "moduleName": "SimpleCRM",
  "description": "...",
  "actions": [ ... ],
  "servesEvents": true
}

The /events endpoint

MindFront polls GET /events. Return a JSON array of events ordered by time ascending. Once written, treat those events as delivered — the endpoint is drain-on-read, and the next call must not return the same events again.

[
  {
    "id": "ev-00012345",
    "time": "2026-05-24T09:14:22.123Z",
    "kind": "DailyVisit",
    "headline": "Acme — Dave Patel",
    "pictogram": "user-multiple",
    "groupKey": "company:12345",
    "externalUrl": "https://your-app.example.com/visits/DV-2526-0042",
    "data": { "visitId": 42, "outcome": "demo scheduled" }
  }
]

Every field is required except externalUrl. The most-load-bearing-and-most-misunderstood is groupKey: it’s the thread / stacking key that collapses related events into one inbox row (typically a company / deal / order id). It is not a dedup key — that’s id.

Why polling, not push

The endpoint is stateful on your side — MindFront sends no cursor, no since-watermark, no acknowledgement call. That means: no inbound webhook for you to expose, no auth dance, no retry queue. You just hold an in-memory queue (or whatever fits your stack) and clear it when MindFront drains it.

For most implementations, the natural pattern is a 60-second DB poll that appends to the queue, so MindFront’s drain frequency is decoupled from your database load.

Key Changes

• ✅ ADDED: servesEvents (optional bool) on /meta, defaulting to false.
• ✅ ADDED: GET /events endpoint when servesEvents: true.
• ✅ UNCHANGED: Full backward compatibility. v3 modules work without any changes.

Developer Actions

• New Modules: Use protocolVersion: 4.
• Existing v3 Modules: No action is required. Opt into events at your own pace.

v3 — Name Change

Module Service Protocol (MSP) is now MindFront Fiber. Same protocol, same spec, same wire format. The name changed because “Fiber” communicates what it actually is — a thin, fast connection between your systems and AI — better than a three-word acronym ever could.

All existing integrations continue to work unchanged. Old URLs redirect automatically.

v2 → v3

Fiber v3 is a backward-compatible update that adds richer UI capabilities and flexible data formats.

New Action Schema Fields

Two optional fields have been added to the action schema in /meta:

{
  "name": "getUser",
  "description": "Retrieves a user by ID.",
  "route": "/action/getUser",
  "riskLevel": "safe",
  "pictogram": "user-profile",
  "typicalHumanProcessTimeInMinutes": 2,
  "input": { "type": "object", "properties": {"id": {"type": "string"}} }
}

• pictogram — A Carbon Design System pictogram name. Displayed as the action’s icon in MindFront.
• typicalHumanProcessTimeInMinutes — Estimated minutes this task takes a human manually. MindFront uses this to communicate time savings.

Action Response: tldr and attachment_urls

Action success responses now support two optional fields:

{
  "status": "success",
  "data": { "name": "Alice", "email": "alice@co.com" },
  "tldr": "Found Alice's contact card",
  "attachment_urls": [ "https://example.com/alice.vcf" ]
}

• tldr — A short human-readable summary of what the action did. Used as the success line in the MindFront UI.
• attachment_urls — An array of URLs MindFront fetches and ingests into the document store as file deliverables on the outcome.

Key Changes

• ✅ ADDED: Optional pictogram field on actions for UI icons.
• ✅ ADDED: Optional typicalHumanProcessTimeInMinutes field on actions.
• ✅ ADDED: Optional tldr and attachment_urls fields on action success responses.
• ✅ UNCHANGED: Full backward compatibility. v2 modules work without any changes.

Developer Actions

• New Modules: Use protocolVersion: 3.
• Existing v2 Modules: No action is required. Add the new fields at your own pace.

v1 → v2

Fiber v2 is a backward-compatible update designed to significantly reduce developer friction.

The Core Change: output Schema Removed

The mandatory output schema for actions has been removed. This increases flexibility and reduces boilerplate.

Before (v1)

{
  "name": "getUser",
  "input": { "type": "object", "properties": {"id": {"type": "string"}} },
  "output": {
    "type": "object",
    "properties": {
      "name": {"type": "string"},
      "email": {"type": "string"}
    }
  }
}

After (v2)

{
  "name": "getUser",
  "input": { "type": "object", "properties": {"id": {"type": "string"}} }
}

Key Changes

• ✅ REMOVED: The output schema is no longer required for actions.
• ✅ UNCHANGED: Full backward compatibility. v1 modules work without any changes.

Developer Actions

• New Modules: Use protocolVersion: 2 and omit the output field.
• Existing v1 Modules: No action is required.