Independent computer
A node is a Windows, Linux or macOS computer running the ChromaNeural client and its selected local AI provider. The node remains usable on its own; network participation is additive.
ChromaNeural
Intelligence grows when it is shared.
ChromaNeural is a distributed AI-node system designed to let independently controlled computers work together on tasks while keeping node-to-node coordination, local AI execution, external tool access, integrity verification and user-controlled resource limits as separate layers.
What a ChromaNeural node is
Controlled participant
The node owner decides whether the machine participates, which peers are approved, which AI provider/model is used, and which resources or external tools are available to the node.
Verified worker
Tasks can be processed locally, divided across approved peers, retried safely and checked for data integrity. Results remain subject to the system's verification and publication rules.
The two communication layers
| Layer | Purpose | Protocol |
|---|---|---|
| ChromaSpeechAI | Communication between ChromaNeural nodes — agent/node coordination, task exchange and results. | ChromaNeural's own node-to-node protocol. |
| MCP | Optional communication from a node's local AI to explicitly approved external tools and services. | Model Context Protocol (node-to-tool). |
Architecture flow
Task / User RequestChromaNeural Node + Local AI Provider
Need another node?ChromaSpeechAI → approved ChromaNeural peer
Need external data/tool?Optional MCP client → approved MCP-enabled service
ResultLocal AI continues the task and may return/share the verified result
Important: MCP does not replace ChromaSpeechAI. A node without any MCP configuration must continue to operate normally. MCP only gives the node's AI optional access to approved external tools such as search, databases, APIs, GitHub/developer tooling or other MCP-enabled services.
How nodes work together
- 01A node receives or creates a task.
- 02The local AI/provider begins processing it.
- 03If the task can be completed locally, no network dependency is required.
- 04If another approved ChromaNeural node can help, the node coordinates through ChromaSpeechAI.
- 05Task fragments and results are exchanged using the existing authenticated node-to-node transport.
- 06Integrity is checked before results are accepted into the normal node workflow.
- 07If an external tool is needed, the local AI may use an explicitly approved MCP connection. That tool call remains separate from peer communication.
What the network can be used for
Distributed problem solving
Break larger tasks into smaller pieces that can be processed by different approved nodes and returned to the requesting node.
Local AI capacity
Use existing local AI providers/models on participant computers instead of requiring every task to be sent to a centralized cloud model.
External data and tools
With MCP enabled, a node can retrieve data from or interact with approved MCP-enabled services without changing the ChromaSpeechAI peer protocol.
Research and verification
Nodes can cooperate on computation, comparison, validation and evidence-producing workflows while preserving provenance and integrity boundaries.
Resource control belongs to the node owner
The ChromaNeural model is opt-in. A participating machine does not become an unrestricted network resource. The local owner remains the authority over what the node is allowed to contribute.
Local limits
- Start, pause, stop and cancel background work.
- Bound CPU / inference-thread use where supported by the verified platform profile.
- Bound committed memory within the supported resource-control profile.
- Keep the local AI provider/model under user control.
- Disable participation without changing the rest of the network.
Trust limits
- Only approved peers are accepted.
- Unknown peers are rejected before normal storage/processing.
- MCP discovery does not mean MCP trust.
- External MCP services must be explicitly configured/approved before use.
- No website should imply that the node automatically shares arbitrary files, credentials or machine access.
Website wording: describe only controls that are actually verified in the released build. Do not market generic CPU/GPU/RAM/storage sharing sliders unless those controls are present and tested in the final release.
Security model
Peer authentication
Node-to-node participation is restricted to approved peers. Unknown peers are rejected instead of being treated as valid workers.
Transport integrity
Verified network testing has included TLS-protected transport and SHA-256 / byte-identity checks for transferred data.
Retry and persistence
The node transport includes persistent inbox behavior, retry/restart handling and duplicate protection so interrupted delivery does not silently become a different result.
Inert received content
Received task/data content is treated as data, not automatically executed as trusted machine code.
External tool isolation
MCP tools are a separate trust boundary. A configured tool must not inherit broad machine, account or peer permissions simply because it is available.
Identity boundary
Internet Identity is an external user-authentication component. The website should distinguish verified local/software behavior from any live end-to-end flows that remain explicitly not verified at release time.
Get ChromaNeural
Let the one with understanding calculate the number…