An open standard for distributed AI inference, peer governance, and conversation portability.
tore is a five-spec family defining the full stack for decentralized AI collaboration — from compute infrastructure at the base to conversation portability at the top. It is vendor-neutral, transport-agnostic, and designed to be implementable by any team in any language.
Reference implementation: imece — a decentralized AI compute cooperative built on the tore standard.
Each spec depends only on lower-numbered specs. Read from bottom to top to follow the dependency order.
| Spec | Title | Layer | Status |
|---|---|---|---|
| tore-0001 | Distributed Inference Protocol | Compute foundation | Draft 1 |
| tore-0002 | Peer Governance and Capability Handshake | Trust and discovery | Draft 1 |
| tore-0003 | Group Session Layer | Collaborative work | Draft 1 |
| tore-0004 | Project Layer | Multi-conversation organization | Draft 1 |
| tore-0005 | Open Conversation Interchange Protocol | Conversation portability | Draft 1 |
The compute foundation. Defines how contributor nodes register hardware, declare transformer layer shards, form inference pipelines, pass activations between nodes, respond to reliability challenges, and earn GigaFLOP-Tokens (GFT). The token economy is opt-in — deployments that do not require a token economy MAY disable GFT issuance and redemption while remaining fully tore-0001 conformant. The coordination API is standardized HTTP/JSON. Activation passing between shard nodes is transport-agnostic — implementations may use HTTP, gRPC, WebSocket, or any other transport.
The trust layer. Defines how nodes discover each other via a structured capability taxonomy, how two parties run an optional mutual challenge-and-evaluation handshake, and how a formalized CollaborationAgreement is produced when both parties independently accept. Challenges are quota-controlled and sovereign — each party evaluates responses against their own expectations with no central judge. Supports three governance modes: anonymous contribution, voluntary handshake, and institution-governed handshake.
The collaboration layer. Defines multi-participant, multi-platform conversation sessions where each participant uses their own AI model. Supports async and live sync modes. Turns are attributed to participants, globally sequenced, and optionally carry settled inference cost records (InferenceCost) linked to the tore-0001 token ledger via ledger_ref. Sessions may reference an tore-0002 CollaborationAgreement to declare their governance basis.
The organization layer. Defines a portable container grouping related conversations, system instructions, and file attachments into a single transferable unit. Instructions support both single-block and multi-block forms. Attachments use a tiered inline/reference model with mandatory checksums. Projects may reference an tore-0002 CollaborationAgreement via project.metadata.
The portability layer. Defines a single portable conversation object that can be moved between AI platforms mid-conversation, shared between users on different platforms, or handed off between models. The Handoff object carries not just what was said but why the switch happened and what the receiving model needs next. The ContextSnapshot orients the receiving model without requiring it to reprocess the full history.
┌─────────────────────────────────────────────────┐
│ tore-0005: Conversation Portability │ ← Single conversation, model handoff
├─────────────────────────────────────────────────┤
│ tore-0004: Project Layer │ ← Multi-conversation, attachments
├─────────────────────────────────────────────────┤
│ tore-0003: Group Session Layer │ ← Multi-participant, inference cost
├─────────────────────────────────────────────────┤
│ tore-0002: Peer Governance & Handshake │ ← Discovery, challenges, agreements
├─────────────────────────────────────────────────┤
│ tore-0001: Distributed Inference Protocol │ ← Compute, tokens, pipelines
└─────────────────────────────────────────────────┘
tore is designed to support three distinct deployment modes. The same specs apply in all three — what changes is configuration and which features are active.
The full token economy is active. Anonymous volunteers globally contribute idle compute and earn GFT tokens redeemable for AI inference. tore-0001 governs compute contribution. tore-0002 is optional. This is the model implemented by imece.
An institution — a university, research lab, or enterprise — pools its own resources for internal use. GPU clusters, lab servers, and idle workstations all participate. The GFT token economy is disabled or used only for internal accounting. tore-0002 Mode 3 (institution-governed handshake) governs access within the boundary. No external network required.
Example: A university research department deploys an internal tore-0001 coordinator. Every machine in the department — including idle faculty workstations — registers as a contributor node. Researchers run tore-0003 group sessions for collaborative work, with inference served by the department’s own pooled hardware. Session history is packaged as tore-0004 projects and archived or shared with collaborators.
Two or more institutions share compute resources with each other for joint research. Each brings their own hardware and runs their own internal coordinator. tore-0002 governs the trust handshake between institutions — each independently evaluates the other’s capabilities and produces a CollaborationAgreement. tore-0003 group sessions span both institutions, with inference costs tracked against the agreement terms. Tokens may or may not be used depending on the agreement.
Example: Two universities collaborate on a pharmaceutical research project. University A contributes a GPU cluster running a specialized medical model. University B contributes CPU nodes and a general-purpose model. An tore-0002 CollaborationAgreement defines the terms. Researchers from both institutions work in a shared tore-0003 session. Each inference operation served by University A’s model records a settled cost — in GFT or in any unit the agreement defines — linked to the session via ledger_ref.
Token economy is opt-in. tore-0001 defines the GFT token model but does not require it. Deployments operating within a trusted boundary — an institution’s private network or a bilateral federation agreement — MAY operate without token issuance and redemption. The compute infrastructure, shard registry, pipeline scheduler, and reliability challenge system all function independently of the token economy.
Transport agnosticism. tore-0001 defines the message contract for activation passing between shard nodes but leaves transport to the implementation. HTTP/JSON is the mandatory baseline. gRPC, WebSocket, and other transports are declared and negotiated per pipeline.
Sovereign evaluation. tore-0002 capability challenges have no central judge. Each party evaluates responses against their own expectations and signals accept or reject independently. The protocol does not define what “good enough” means — that is each party’s decision.
Settled costs only. tore-0003 InferenceCost records are only written after the tore-0001 token ledger confirms a transaction. Pending or estimated costs never appear in session records.
Optional governance. Anonymous compute contribution (tore-0001) requires no identity, no declaration, and no agreement. tore-0002 governance is a layer on top — opt-in for individuals, enforceable at institutional boundaries.
Taxonomy extensibility. The tore-0002 capability taxonomy is structured (two-level domain/subdomain) but open. Unknown domain and subdomain values MUST be accepted by conforming parsers. The taxonomy grows through community contribution.
| Use Case | Specs involved |
|---|---|
| Anonymous volunteer contributes idle GPU to public AI network | tore-0001 |
| University pools idle workstations for internal research inference | tore-0001, tore-0002 |
| Two research institutions share GPU clusters for joint project | tore-0001, tore-0002, tore-0003 |
| Research team collaborates in shared AI session across platforms | tore-0003, tore-0005 |
| Institution archives collaborative research as portable project | tore-0003, tore-0004 |
| User moves conversation from one AI platform to another | tore-0005 |
| Enterprise runs private internal AI inference with usage accounting | tore-0001, tore-0002 |
imece is the reference implementation of the tore standard. It implements:
- tore-0001 — coordination API, shard registry, pipeline scheduler, reliability challenge system, and GFT token ledger
- tore-0002 — discovery index integrated into the imece coordination layer
- tore-0003 — group session support with imece-settled
InferenceCostrecords - tore-0004 — project portability for imece-hosted collaborative work
- tore-0005 — conversation export and import for imece session history
imece supports all three deployment modes above. The same imece_client daemon points to either the public coordinator or an institution’s internal coordinator — the deployment mode is a configuration choice, not a code change.
tore is an independent open standard. imece is one implementation. Any team may implement tore independently.
| Standard | Relationship |
|---|---|
| MCP (Anthropic) | Complementary. MCP connects AI to external tools. tore moves conversations and compute context between humans and platforms. |
| A2A (Google) | Complementary. A2A is agent-to-agent communication. tore is human-to-human and human-to-platform. |
| MBOX | Inspirational. tore-0005 aims to be for AI conversations what MBOX is for email archives. |
| iCalendar (RFC 5545) | Structural inspiration. A single portable object, transport-agnostic, widely adopted via community standardization. |
| SETI@home / BOINC | Conceptual inspiration for tore-0001 volunteer compute model. |
All tore documents are UTF-8 encoded JSON (RFC 8259). Each document includes an tore_spec field identifying which spec it conforms to.
| tore_spec | Document type | Extension |
|---|---|---|
"tore-0001" |
Not applicable (API protocol, not a document format) | — |
"tore-0002" |
Discovery record or collaboration agreement | .tore2-discovery.json, .tore2-agreement.json |
"tore-0003" |
Group session | .tore3.json |
"tore-0004" |
Project | .tore4.json |
"tore-0005" |
Conversation | .tore5.json or .tore.json |
Implementations may conform to any subset of the spec family. Conformance to a higher-numbered spec does not require conformance to all lower-numbered specs — only to those the higher spec explicitly depends on.
| Implementation type | Required specs |
|---|---|
| Compute node only | tore-0001 |
| Governed compute node | tore-0001, tore-0002 |
| Collaborative session platform | tore-0001, tore-0002, tore-0003 |
| Full project platform | tore-0001 through tore-0004 |
| Full stack | tore-0001 through tore-0005 |
tore is an open standard. Contributions are welcome via GitHub Issues and Pull Requests.
Read the specs first:
spec/tore-0001.md— Distributed Inference Protocolspec/tore-0002.md— Peer Governance and Capability Handshakespec/tore-0003.md— Group Session Layerspec/tore-0004.md— Project Layerspec/tore-0005.md— Open Conversation Interchange Protocol
Open areas for contribution:
- JSON Schema files for all five specs (
schemas/) - Reference node implementation (Python, Go, Rust) for tore-0001
- Platform converters (ChatGPT → tore-0005, Gemini → tore-0005, Claude → tore-0005)
- Reference WebSocket host for tore-0003 live sync
- tore-0002 capability taxonomy extension proposals (new domains and sub-domains)
- imece discovery index integration for tore-0002
- Cryptographic signing reference implementation for tore-0002
- FLOPs measurement reference implementation for tore-0001
- Federated coordinator protocol (multi-coordinator federation) for tore-0001
- Governance policy templates for institutions implementing tore-0002 Mode 3
- Private institutional deployment guide (tore-0001 tokenless mode)
- Inter-institutional federation deployment guide (tore-0001 + tore-0002)
Apache 2.0. See .
Aslan Kose github.com/jstdv
tore is an independent open standard. It is not affiliated with Anthropic, OpenAI, Google, or any AI platform vendor.