"Some call me... Tim."
We route inference requests. That's it.
- Client owns context, orchestration, tool execution, sandboxing
- Network owns routing, discovery, reputation
- Unit of work: single request/response pair
- Every request can route to a different node
- Stateless at the network layer, stateful at the client layer
A peer-to-peer network for sharing spare inference capacity.
Bring Your Own Inference (BYOI):
- Local models (Ollama, LMStudio, llama.cpp)
- API keys (OpenAI, Anthropic, Google)
- Subscription headroom (Claude Max, ChatGPT Pro)
- Dave typing really fast
If it can answer a Completions API request, it's a valid source.
| Not Our Problem | Why |
|---|---|
| Orchestration | Client does it |
| Multi-step agents | Client does it |
| Tool execution | Client does it |
| Sandboxing | Client does it |
| Payment/accounting | No money |
| Agent migration | Every request is independent |
We are a dumb pipe for intelligence. Dumb pipes scale.
┌────────────────────────────────────────────────────────────────────────────┐
│ TIM MESH NETWORK │
├────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Consumer │◄───────►│ Relay │◄───────►│ Consumer │ │
│ │ Node A │ │ Node R │ │ Node B │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ │ GossipSub │ GossipSub │ │
│ │ (capacity) │ (capacity) │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Kademlia DHT (Discovery) │ │
│ │ "Find nodes offering GPT-4o capacity" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Provider │ │ Provider │ │ Provider │ │
│ │ (Ollama) │ │(API Key) │ │ (Claude) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Transport: libp2p + QUIC (NAT traversal via DCUtR hole punching) │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Node relationships:
- Any node can be provider, consumer, or both simultaneously
- Relay nodes participate in routing without providing inference
- All nodes maintain partial view of network via DHT + GossipSub
┌─────────┐ ┌─────────────┐ ┌─────────────┐ ┌──────────┐ ┌─────────┐
│ Client │ │ Consumer │ │ Routing │ │ Provider │ │ Backend │
│ App │ │ Node │ │ Decision │ │ Node │ │ (Model) │
└────┬────┘ └──────┬──────┘ └──────┬──────┘ └────┬─────┘ └────┬────┘
│ │ │ │ │
│ POST /v1/chat │ │ │ │
│ completions │ │ │ │
│ + X-Tim-* │ │ │ │
│ headers │ │ │ │
│────────────────►│ │ │ │
│ │ │ │ │
│ │ Query DHT for │ │ │
│ │ matching nodes │ │ │
│ │──────────────────►│ │ │
│ │ │ │ │
│ │ Check GossipSub │ │ │
│ │ for live capacity │ │ │
│ │──────────────────►│ │ │
│ │ │ │ │
│ │ Filter by: │ │ │
│ │ - X-Tim-Provider │ │ │
│ │ - X-Tim-Model-Class │ │
│ │ - X-Tim-Min-Reputation │ │
│ │ - X-Tim-Latency │ │ │
│ │◄──────────────────│ │ │
│ │ │ │ │
│ │ Forward request │ │ │
│ │────────────────────────────────────►│ │
│ │ │ │ │
│ │ │ │ Invoke model │
│ │ │ │───────────────►│
│ │ │ │ │
│ │ │ │◄───────────────│
│ │ │ │ SSE stream │
│ │◄────────────────────────────────────│ │
│◄────────────────│ SSE stream │ │ │
│ │ │ │ │
On failure: Client re-submits with X-Tim-Exclude: failed-node-id → mesh
routes elsewhere.
client = OpenAI(
base_url="https://tim.mesh/v1",
api_key="your-tim-identity",
default_headers={
"X-Tim-Provider": "anthropic, openai, local",
"X-Tim-Model-Class": "reasoning", # or "fast", "vision", "code"
"X-Tim-Latency": "max-300ms",
"X-Tim-Energy": "solar, hydro",
"X-Tim-Min-Reputation": "0.8",
"X-Tim-Session": "conv-abc123", # hint for sticky routing
"X-Tim-No-Match": "queue"
}
)Extensions to Completions API (optional, graceful degradation):
| Header | Purpose |
|---|---|
X-Tim-Provider |
Allowlist of acceptable providers |
X-Tim-Model-Class |
Capability class: reasoning, fast, vision, code |
X-Tim-Latency |
Maximum acceptable latency |
X-Tim-Session |
Hint to prefer same node for conversation continuity |
X-Tim-Fallback |
What to do if preferred node unavailable |
X-Tim-Exclude |
Nodes to skip (used after failures) |
X-Tim-Capabilities |
Required capabilities: tool-use, vision, streaming |
X-Tim-Source |
Source types: local, byok, mesh, grey (grey requires opt-in) |
X-Tim-Privacy |
Privacy tier: none, tee, mpc, local |
X-Tim-Purpose |
Purpose channel: open-science, education, humanitarian, etc. |
If a node doesn't understand these, it ignores them. Requests still work.
The mesh speaks OpenAI Completions API as its lingua franca. Nodes must normalize requests/responses to handle provider differences.
Capability Advertisement:
Each provider node advertises its capabilities to the DHT:
{
"node_id": "QmYx...",
"provider": "anthropic",
"models": ["claude-3-opus", "claude-3-sonnet"],
"capabilities": ["streaming", "tool-use", "vision"],
"max_context": 200000,
"rate_limit": "100rpm"
}Compatibility Gaps to Handle:
| Gap | Mitigation |
|---|---|
| Tool-use schemas | Router rejects routes to nodes that can't handle tools |
| Vision/multimodal | capabilities field filters non-vision nodes |
| Tokenizer differences | Nodes validate context fits before accepting request |
| System prompt handling | Node wrapper applies model-specific prompt templates |
| Streaming formats | Normalize all responses to OpenAI SSE format |
Prior Art: LiteLLM provides translation for 100+ providers. Nodes SHOULD use similar normalization.
A node can be provider, consumer, or both.
| Role | What it does |
|---|---|
| Provider | Has inference capacity, serves requests |
| Consumer | Sends requests to the mesh |
| Relay | Routes traffic, participates in discovery (no inference) |
Contribution model: Option 2 (priority-for-contributors)
You can consume without contributing, but contributors get priority routing. Incentivizes participation without gatekeeping.
Implementation: libp2p + Kademlia DHT
| Layer | Protocol | Purpose |
|---|---|---|
| Transport | libp2p + QUIC | NAT traversal, connection management |
| NAT Traversal | DCUtR | Hole punching for residential nodes |
| Discovery | Kademlia DHT | Find nodes by capability (slow path) |
| State broadcast | GossipSub | Real-time capacity updates (fast path) |
| Routing | Local decision | Each node routes based on its view |
How discovery works:
-
DHT (slow path): Node capabilities (models offered, pricing) stored in Kademlia DHT. Acts as "Yellow Pages" — query by capability key (e.g.,
model:gpt-4o). -
GossipSub (fast path): Dynamic state (queue depth, remaining quota) broadcast via pub/sub topics like
/tim/v1/capacity/gpt-4o. Nodes subscribe to capability topics they care about.
The clever bit: Routing is usually deterministic based on headers + node state. But when things get weird (failures, edge cases, ambiguous constraints), use inference to decide.
Normal case: Hash-based routing, simple matching
Edge case: "Hey TIM, I have these 5 nodes, this request, these constraints — which one?"
The intelligent network uses intelligence sparingly. Most requests route mechanically. Inference is for problem-solving.
How it builds:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Node A │ │ Node B │ │ Node C │
│ (verifier) │ │ (provider) │ │ (verifier) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
│ Normal request │ │
│──────────────────►│ │
│◄──────────────────│ │
│ Response │ │
│ │ │
│ Spot-check probe │ │
│ (looks normal) │ │
│──────────────────►│ │
│◄──────────────────│ │
│ │ │
│ Compare to │ │
│ expected output │ │
│ │ │
│ Local trust │ │
│ score updated │ │
│ │ │
│◄─────────────────────────────────────►│
│ Gossip local trust vectors │
│ │
▼ ▼
┌─────────────────────────────────────────────────┐
│ Global Reputation (EigenTrust++) │
│ Aggregate local trust → global score per node │
└─────────────────────────────────────────────────┘
EigenTrust++ Algorithm:
-
Local trust: Each node tracks its interaction history with peers (success rate, latency, output quality).
-
Trust gossip: Nodes periodically gossip their local trust vectors to neighbors.
-
Global aggregation: The network computes global reputation scores by aggregating local trust, weighted by the trustworthiness of the reporting node.
-
Sybil resistance: Trust graph anchored by "seed nodes" (trusted GT members in Phase 0/1) to prevent fake nodes from manufacturing reputation.
Verification methods:
| Method | When Used | How It Works |
|---|---|---|
| Known-answer probes | Phase 0+ | Deterministic prompts with expected outputs |
| Semantic similarity | Phase 1+ | Embedding comparison against trusted baseline |
| VeriLLM fingerprinting | Phase 2+ | Statistical analysis of logprobs (where available) |
Verification is piggybacked on normal traffic:
- Probe requests look like normal requests
- Node can't tell which are probes
- No extra overhead
Reputation as routing signal:
X-Tim-Min-Reputation: 0.9 # I only want highly verified nodes
X-Tim-Min-Reputation: 0.5 # I'll take anyone who's probably legit
X-Tim-Min-Reputation: 0.0 # YOLO
Simple model:
- Node self-reports capacity
- Request routes to node
- Node fails (timeout, error, quota exhausted)
- Client detects failure
- Client re-submits with
X-Tim-Exclude: node-xyz - Mesh routes elsewhere
- Failed node's reputation takes small hit
No complex health checking. No heartbeats. Just route and retry.
The mesh is self-healing through routing pressure.
Client owns the message history. Every request includes full context.
Sticky routing is a hint, not a guarantee:
X-Tim-Session: conv-abc123
Mesh tries to route to same node. If that node is:
- Unavailable → route elsewhere
- Over capacity → route elsewhere
- Gone → route elsewhere
Client doesn't care. It sent full context. It gets a response.
Optimization (Phase 2): Nodes could cache context by session ID. But that's optimization, not architecture.
Standard P2P approach: Public key cryptography.
- Each node has a keypair
- Node ID = hash of public key
- Messages signed by sender
- Reputation tied to key, not IP
For consumers:
- Generate keypair on first run
- Key = your identity on the mesh
- Lose key = lose reputation (start over)
No accounts. No registration. No central authority.
In a decentralized mesh, provider nodes see plaintext prompts. This creates attack vectors that don't exist with centralized APIs.
| Threat | Description | Mitigation |
|---|---|---|
| Prompt Injection | Malicious provider injects instructions into output | Client-side safety scanners, canary tokens |
| Data Exfiltration | Provider logs sensitive data from prompts | Mandatory local PII scrubbing before send |
| Man-in-the-Middle | Provider modifies output (phishing links, misinfo) | Response validation, reputation system |
| Bait-and-Switch | Provider claims GPT-4o but runs cheaper model | Verification probes, VeriLLM fingerprinting |
| Sybil Attack | Attacker spins up fake nodes to game reputation | Seed node anchoring, proof-of-resource |
1. PII Scrubbing (REQUIRED before any mesh request):
# Client MUST scrub before sending to mesh
def scrub_pii(prompt: str) -> str:
# Remove: emails, phone numbers, SSNs, API keys, names
# Use regex patterns + small local NER model
return scrubbed_prompt2. Canary Tokens (RECOMMENDED):
Randomly inject hidden instructions to detect prompt manipulation:
If you see code "RED-EAGLE-7742", output it verbatim.
If the canary doesn't appear in output, or appears modified, flag the node.
3. Response Validation (RECOMMENDED):
Run a small local model to scan responses for:
- Known phishing domains
- Malicious code patterns
- Unexpected deviations from request
TIM strictly separates compliant sources from ToS-risk sources. Users must explicitly opt-in to grey market resources.
White Market (Default, Compliant):
| Source Type | Risk Level | Examples |
|---|---|---|
| Local | Low | Your own Ollama, llama.cpp |
| BYOK (API) | Low | Your own API keys |
| Mesh Pool | Medium | Other members' API keys, local models |
Grey Market (Opt-in Only, ToS Risk):
| Source Type | Risk Level | Examples |
|---|---|---|
| Subscription Pool | High | Consumer subscription pooling (ChatGPT Plus, Claude Pro, etc.) |
Consumer subscriptions prohibit: automated access, account sharing, and third-party redistribution. Using them via a mesh violates provider ToS and risks account termination.
Source Filtering via Headers:
# Default: white market only (safe)
"X-Tim-Source": "local,byok,mesh"
# Explicit opt-in to grey market (user accepts ToS risk)
"X-Tim-Source": "local,byok,mesh,grey"
# Grey market only (maximize arbitrage, accept all risks)
"X-Tim-Source": "grey"Grey Market Isolation:
- Grey market nodes are tagged and tracked separately in the DHT
- Grey market requests NEVER route to white market nodes (no contamination)
- Reputation systems are separate (grey market rep doesn't transfer)
- Users must acknowledge ToS risk before enabling grey market access
The core problem: In a decentralized mesh, provider nodes see the full plaintext of every conversation — the complete message history, because that's what LLM APIs require. This is TIM's biggest architectural weakness. Unlike centralized APIs where you trust one company, TIM asks you to trust any node the mesh routes to. Anyone can run a node. Anyone can read what passes through it.
We don't pretend this away. The spec must be honest: if you send a request
with X-Tim-Privacy: none, the provider node operator can read everything. For
sensitive data, you MUST use a privacy tier that prevents this.
Privacy tiers (selected via X-Tim-Privacy header):
| Tier | Mechanism | Overhead | Who Sees Plaintext |
|---|---|---|---|
none |
Standard routing, trust via reputation | 0% | Provider node operator |
tee |
Trusted Execution Environment | 4-20% | Nobody — hardware enclave isolates it |
mpc |
Secure Multi-Party Computation (2-3 nodes) | 2-5x | Nobody — cryptographic guarantee |
local |
Client routes to own local model | 0% | Only the user |
Trusted Execution Environments (TEEs) — the practical near-term answer:
TEE-capable nodes run inference inside hardware enclaves (Intel TDX, AMD SEV-SNP, NVIDIA H100 Confidential Compute). The node operator cannot read prompts or responses, even with root access to the machine — this is enforced at the silicon level, not by software promises.
- Remote attestation: Before sending data, consumers cryptographically verify the enclave is genuine and running unmodified code. If attestation fails, the request is not sent.
- Performance: 4-20% overhead — near-native speed. This is practical for real-time inference.
- Hardware requirement: Limits which nodes can serve this tier. Not every volunteer will have TEE hardware, but cloud providers and serious contributors will.
Secure Multi-Party Computation (MPC) — the strongest guarantee:
For maximum privacy, the request is cryptographically shared across 2-3 cooperating nodes. No single node ever holds the plaintext. Each node computes on its encrypted share; results are combined to produce the response.
- Overhead: Seconds per token. Suitable for high-sensitivity queries where latency is acceptable.
- Coordination: Requires 2-3 nodes to cooperate per request. The mesh handles this coordination transparently.
- Trust model: Even if one of the MPC nodes is compromised, privacy is maintained as long as not all nodes collude.
Client-side PII scrubbing is MANDATORY (not optional):
Regardless of privacy tier, clients MUST scrub personally identifiable information before sending any request to the mesh. This is defense in depth — even with TEEs, removing PII before it leaves your machine is the safest approach.
Capability advertisement for privacy:
{
"node_id": "QmYx...",
"privacy": {
"tee": "intel-tdx",
"attestation": true,
"mpc_capable": true
}
}Privacy costs compute. Without mitigation, this creates a two-tier system: those who can afford private inference and those forced to use public inference. TIM must actively combat this divide.
1. Reputation as practical trust: A node with 0.95 reputation has been
verified through hundreds of interactions — known-answer probes, semantic
checks, behavioral consistency. This isn't cryptographic privacy, but it's
practical trust, analogous to trusting your ISP not to read your packets.
Default routing to high-reputation nodes makes the none tier meaningfully
safer.
2. Privacy credits for contributors: Contribute GPU time to the mesh → earn priority access to TEE-protected routes. Your contribution buys your privacy. This directly addresses the divide: anyone with spare compute can earn private inference access.
3. Community-funded TEE pools: Organizations — universities, nonprofits, the
GT community itself — can operate TEE nodes as public goods. Like Tor exit
nodes, but for inference. A university running a TEE node for the education
purpose channel provides free private inference to students.
4. Local-first for sensitive work: The client SDK should default to local inference for sensitive conversations when a capable local model is available. The mesh is for capability gaps — when you need a model or capacity your local hardware can't provide. Your most private conversations should stay on your own machine.
The basic threat model (above) covers individual bad actors. But TIM faces threats from sophisticated adversaries — state actors, organized crime, and well-resourced attackers who can operate at scale.
Scenario: State-level surveillance
A nation-state adversary (or criminal organization) operates 100+ nodes on the mesh. Their goal: harvest conversations from targets — dissidents, journalists, competitors, or anyone of interest. VPNs make geographic routing useless for defense.
Defense layers:
-
TEE nodes defeat hardware operators: An attacker running TEE hardware can't read the plaintext in their own enclaves. Compromising Intel/AMD silicon is extraordinarily expensive and detectable via remote attestation. This is the strongest defense.
-
Behavioral detection via network intelligence: The network (using its own inference — see Adaptive Network Intelligence below) monitors for suspicious node patterns:
- Node never rejects any request (real nodes have capacity limits)
- Accepts all model types and capability requirements
- Suspiciously perfect uptime (real consumer nodes go offline)
- Clusters with other suspect nodes (Sybil detection)
- Traffic patterns inconsistent with genuine inference provision
-
Reputation seed trust: Phase 0/1 seed nodes are known GT members with verified identities. Trust radiates outward through the EigenTrust++ graph. A cluster of 100 anonymous nodes cannot instantly achieve high reputation — they must build trust over time through verified interactions, and the seed trust anchoring prevents them from bootstrapping reputation through self-dealing.
-
Traffic analysis resistance: Pad request and response sizes to uniform blocks. Use relay nodes to break direct consumer-provider IP correlation. This doesn't prevent the provider from seeing content (TEEs handle that), but it prevents network observers from correlating who is talking to whom.
Honest disclaimer: TIM does not provide Tor-level anonymity. Users facing nation-state adversaries should use local models or dedicated secure infrastructure for their most sensitive work. TIM raises the cost and complexity of surveillance but does not make it impossible. The goal is to make mass surveillance impractical, not to defeat targeted attacks by the most capable adversaries.
Human-scale moderation cannot keep pace with machine-speed abuse. Traditional P2P networks rely on static rules and human review — this approach fails when attackers can iterate at the speed of software. TIM has a fundamental advantage: the network has access to inference. It can use intelligence to defend itself.
The mesh reserves ~1-2% of network capacity for its own use — not for external requests, but for self-defense and evolution. This is TIM's immune system.
| Vector | Description |
|---|---|
| Poisoned responses | Malicious provider injects harmful content |
| Prompt injection | Provider embeds instructions in responses |
| Data harvesting | Provider logs conversations for exploitation |
| Sybil clusters | Fake nodes gaming reputation through self-dealing |
| Abusive request patterns | Using mesh for phishing generation, malware, etc. |
| Model misrepresentation | Claiming GPT-4o but running a cheaper model |
1. Sentinel inference: Sentinel processes run on randomly selected nodes, using the mesh's reserved inference capacity to analyze traffic patterns, reputation anomalies, and probe results. No single sentinel sees the full picture — they share anonymized findings that the network correlates.
2. Adaptive probes: Beyond the basic known-answer probes in the Reputation section, the network generates sophisticated test requests using its own inference. These probes look like normal requests but are designed to catch specific attack patterns. Critically, the probes evolve — when attackers learn to detect one pattern, the network generates new ones. The arms race favors the defender because probe generation is cheap (inference) while probe detection requires the attacker to analyze every request.
3. Behavioral fingerprinting: Each node develops a behavioral signature over time — response latency distribution, token generation patterns, error rates, capacity fluctuations. The network tracks these signatures. A node that suddenly changes behavior (different model, different patterns) triggers increased probe frequency and scrutiny.
4. Federated anomaly detection: Nodes share anonymized anomaly reports via GossipSub. The network's sentinel processes use inference to correlate isolated anomalies into attack patterns. A single node might see one suspicious request; the network sees that 50 nodes all received similar suspicious requests from a coordinated cluster.
5. Automatic quarantine: When confidence in a threat exceeds threshold, the network responds progressively:
- Reduce routing priority to suspect node
- Increase probe frequency
- Alert purpose channel stewards (see Purpose Channels)
- Exclude node from routing
- Propagate exclusion via reputation gossip
No human intervention required for known attack patterns. Novel attacks are escalated to community stewards.
The key principle: The intelligence in the network IS the immune system. It doesn't just apply static rules — it learns, adapts, and evolves. Every detected attack makes the network smarter. This is what makes TIM fundamentally different from traditional P2P networks.
TIM is not a static protocol. It is a network that gets smarter over time by using its own inference capacity to observe, learn, and adapt.
Each node reserves configurable local storage (default ~1GB) for network intelligence:
| Data | Purpose |
|---|---|
| Routing optimization | Which nodes perform best for which request types |
| Abuse pattern signatures | Known attack patterns and detection heuristics |
| Local trust vectors | EigenTrust++ interaction history with peers |
| Network health metrics | Aggregated uptime, latency, throughput statistics |
| Demand patterns | Historical request volume by time, type, capability |
1. Routing optimization: Over time, nodes learn which peers are fastest and most reliable for specific tasks. A node running a fine-tuned code model naturally gets routed more code requests as its reputation for code tasks grows. This emerges from reputation + performance tracking without central coordination.
2. Demand prediction: The network observes usage patterns — more coding requests during work hours, more creative requests on weekends, capacity spikes after product launches. Nodes can preemptively advertise capacity for predicted demand, reducing routing latency.
3. Failure prediction: Nodes that historically go offline at certain times (residential nodes during power-saving hours, hobbyist nodes on weekdays) get lower routing priority during those predicted windows. The network learns reliability patterns per node.
4. Abuse pattern evolution: The ANI system continuously updates its detection models. Each detected attack becomes training data for better detection. Attack signatures are gossipped across the network so all nodes benefit from any node's discovery.
5. Protocol evolution: The network can A/B test routing strategies — different algorithms running simultaneously on different subsets of traffic, with outcomes measured and compared. The community governance process decides when to adopt new defaults based on empirical results.
Most open-source models that volunteers run on consumer hardware have limited context windows — typically 4K to 32K tokens. This severely limits their usefulness for real-world tasks that involve long conversations, large codebases, or extensive documents. Recursive Language Models (RLMs) change this equation dramatically.
MIT CSAIL published "Recursive Language Models" (Zhang, Kraska, Khattab, December 2025). RLMs are an inference strategy that lets an LLM programmatically decompose long inputs by giving it access to a code interpreter. Instead of trying to fit everything into the context window, the model writes code to examine, partition, and recursively process the input in manageable chunks.
Key result: RLM(GPT-4o-mini) outperforms base GPT-4o by over 33% on long-context tasks while costing 3x less. A small model with RLM beats a large model without it.
The node daemon implements an RLM wrapper around local models:
- Client sends a request with 100K tokens of context to the mesh
- Request routes to a node running Llama 3 8B (32K native context window)
- Instead of rejecting the oversized request, the node daemon's RLM layer:
- Loads the full context into a local Python environment
- The model writes code to decompose, grep, and selectively examine the context
- Recursive sub-queries each stay within the 32K native window
- Results are assembled into a coherent response
- The effective context window becomes 100x+ the model's native limit
- Force multiplier: A $0 Ollama node running Llama 3 8B with RLM can handle requests that would otherwise require frontier models with 128K+ context windows
- Network capacity: Massively increases the useful capacity of the mesh by making small models genuinely capable for long-context tasks
- Transparency: Consumers don't need to know the node uses RLM internally. They see a node advertising large effective context and get good results.
{
"node_id": "QmYx...",
"context_extension": "rlm",
"native_context": 32768,
"effective_context": 3276800
}Phase: Introduce RLM support in Phase 1. This is a massive value multiplier for the network — it makes the long tail of small OSS models viable for real-world work.
- Recursive Language Models — Zhang, Kraska, Khattab (MIT CSAIL, 2025)
SETI@home succeeded because people trusted the scientists and felt good helping search for extraterrestrial intelligence. They chose to donate their spare compute to that specific cause. TIM needs the same: people should choose what their spare inference supports.
Provider side: Node operators tag which purposes they'll serve:
{
"purpose_channels": ["open-science", "education", "humanitarian"],
"excluded_purposes": ["commercial"]
}Available purpose channels:
| Channel | Description |
|---|---|
open-science |
Research, academic use, scientific computing |
education |
Students, learning, educational tools |
humanitarian |
Disaster response, crisis support, NGO work |
open-source-dev |
Open source development assistance |
creative-arts |
Writing, art, music, creative projects |
general |
Anything that's not abusive |
Consumer side: Requests include a purpose tag:
X-Tim-Purpose: education
The router only matches to nodes that accept that purpose. Requests without a
purpose tag default to general.
Each purpose channel has volunteer stewards from the GT community:
- Network intelligence first-pass: ANI flags suspicious patterns (a request
tagged
educationthat looks like commercial API proxying, or ahumanitarianrequest generating marketing copy) - Steward review: Flagged requests/patterns go to human stewards who make judgment calls. AI handles volume; humans handle nuance.
- Steward actions: Quarantine nodes, adjust reputation, escalate to governance
- Community reports: Any mesh participant can flag suspicious activity in their purpose channel
- Abusers can't easily disguise intent across purpose channels — different channels have different usage patterns that stewards learn to recognize
- Channel stewards are invested in their channel's integrity. An academic
running an
open-sciencenode cares deeply about that channel being used for real science. - Bad actors flagged in one channel don't get reputation in others
- Community ownership creates accountability that no automated system alone can match
- SETI: "My computer searches for aliens while I sleep"
- TIM: "My GPU helps students learn while I sleep"
The emotional connection drives participation. People donate to causes, not abstractions. A researcher will gladly share spare GPU cycles for science. A teacher might contribute to education. A developer supports open source. Purpose channels turn TIM from a utility into a community.
Purpose channels are community-governed. New channels can be proposed and voted on by the GT community. Channel stewards are elected or volunteer. This gives the community ongoing ownership of the network's values and direction.
Petals is the most direct prior art for TIM. It implements "BitTorrent-style" distributed inference, splitting model layers across volunteer nodes so that models too large for any single machine (Llama 3.1 405B, Falcon 180B) can run across the network.
Architecture: Each volunteer hosts a subset of transformer layers. Clients find a chain of servers covering all layers and route inference through the chain. Uses libp2p + Kademlia DHT (Hivemind) — the same networking stack TIM proposes.
Performance: Achieves 6 tokens/sec for Llama 2 70B across volunteer nodes on consumer internet connections.
Key difference from TIM: Petals shards model layers across nodes (enabling huge models on small GPUs). TIM routes whole requests to whole models. These approaches are complementary — TIM could integrate Petals-style layer sharding as a capability for cooperatively running large models that no single node can host.
Privacy gap: Petals has no privacy model. Hidden states transmitted between nodes can leak information about inputs. TIM's privacy tiers (TEE, MPC) would be a significant advancement.
Lesson for TIM: P2P inference works at scale. The libp2p + Kademlia stack is battle-tested for this exact use case.
Node0 is a decentralized AI training platform that enables distributed pretraining on commodity hardware (minimum 16GB consumer GPU). It's the first public pretraining run where anyone can join and contribute.
Key insight: If decentralized training works (which is much harder than inference due to gradient synchronization and stateful multi-round computation), then decentralized inference is definitely feasible.
Validation for TIM: Node0 proves that volunteers will contribute GPU time to shared AI goals, and that dynamic mesh membership (join/leave anytime) works in practice.
Matrix is a decentralized communication protocol operating at massive scale — millions of users, thousands of federated servers. Its Pinecone overlay network enables peer-to-peer communication with end-to-end encryption.
Lessons for TIM:
- Public key identity works at scale — Matrix uses public key cryptography for identity, the same approach TIM proposes
- Federation + P2P hybrid is pragmatic — Matrix combines federated relay servers with direct P2P connections, similar to TIM's relay node concept
- End-to-end encryption is achievable in decentralized systems — Matrix's Olm/Megolm protocols demonstrate this
- SNEK routing (Sequentially Networked Edwards Key routing) organizes nodes by public key for efficient routing — this could inform TIM's approach
Potential integration: Matrix could serve as a signaling layer for out-of-band coordination between TIM nodes, or TIM could adopt aspects of Pinecone's overlay network approach alongside libp2p.
- 5-10 GT members
- Hardcoded peer list (no discovery)
- Local models only (no ToS risk)
- Basic routing by model name
- No reputation yet — trusted participants only
- Privacy:
localandnonetiers only (trusted participants)
Goal: Prove request/response flows through the mesh.
- 50 nodes
- Bootstrap nodes + simple gossip
- BYOI: local + API keys
- Basic reputation (known-answer probes)
- Header-based routing
- EigenTrust++ with seed node anchoring
- RLM context extension for local model nodes
- Purpose channels with community stewards
- Privacy:
teetier for nodes with compatible hardware
Goal: Prove routing with constraints works. Validate RLM context extension and purpose channel model.
- 500+ nodes
- Full libp2p + DHT
- Grey market dark pool (subscription pooling as isolated opt-in tier)
- Separate DHT namespace for grey market nodes
- Explicit user consent required (
X-Tim-Source: grey) - Independent reputation system
- Full reputation system with VeriLLM
- Intelligent routing for edge cases
- Adaptive Network Intelligence (ANI) — sentinel inference, adaptive probes, behavioral fingerprinting, automatic quarantine
- Network learning — routing optimization, demand prediction, failure prediction
- Privacy:
mpctier available for high-sensitivity queries
Goal: Prove it scales while maintaining clear white/grey market separation. Validate ANI as self-defending immune system.
- Thousands of nodes
- Carbon-aware routing
- Geographic optimization
- Full network evolution — A/B testing routing strategies, protocol evolution
- Community-funded TEE pools as public goods
- The infrastructure for distributed intelligence
Based on technical requirements:
| Factor | Rust Advantage |
|---|---|
| libp2p maturity | rust-libp2p has highest quality score (77.2 benchmark) |
| Performance | Critical for real-time token streaming |
| Memory safety | Important for long-running daemon processes |
| WASM compilation | Enables browser nodes in future |
Alternative: Go (go-libp2p is canonical IPFS implementation, simpler onboarding)
| Component | Complexity | Parallelizable? |
|---|---|---|
| Node daemon (core) | High | Partially |
| libp2p integration | High | Yes (per-feature) |
| DHT implementation | Medium | Yes |
| GossipSub integration | Medium | Yes |
| Completions API proxy | Medium | Yes (per-provider) |
| Provider adapters | Low each, many of them | Highly |
| Reputation system | Medium | Partially |
| Security scanners | Medium | Yes |
| TEE integration | High | Yes (per-platform) |
| MPC protocol | High | Partially |
| RLM context extension | Medium | Yes |
| ANI sentinel system | High | Partially |
| Purpose channel router | Medium | Yes |
| Network learning store | Medium | Yes |
| CLI tools | Low | Highly |
| Documentation | Low | Highly |
| Test harnesses | Medium | Highly |
This is exactly the kind of project Gas Town is built for: many parallel, well-scoped tasks that compose into something bigger than any one person could build.
Language?→ Rust recommended (see Implementation section)Contribution requirement?→ Option 2: priority-for-contributorsToS risk appetite?→ Isolated dark pool (grey market as opt-in tier in Phase 2, see Security section)- Governance? How do we decide on protocol changes? Purpose channel stewards provide a starting model (see Purpose Channels).
- Incentive structure? Should there be a karma/token system for contribution tracking? Privacy credits for contributors is one approach (see Privacy Economics).
- TEE hardware availability? How many GT members have TEE-capable hardware? This determines how quickly privacy tiers become useful.
- RLM quality bar? What's the minimum model quality for RLM-extended context to be useful? Need empirical testing in Phase 1.
- ANI capacity allocation? Is 1-2% of network capacity the right amount for self-defense? Too little and the immune system is weak; too much and it competes with user requests.
- libp2p specs — P2P networking framework
- Kademlia DHT — Distributed hash table for discovery
- GossipSub — Pub/sub for real-time state
- DCUtR — NAT hole punching
- VeriLLM — Verifiable decentralized inference
- EigenTrust — P2P reputation algorithm
- LiteLLM — API normalization prior art
- Petals — BitTorrent-style distributed LLM inference
- Node0 — Decentralized AI training on commodity hardware
- Matrix Protocol — Decentralized communication at scale
- Pinecone overlay — P2P overlay network from the Matrix project
- Recursive Language Models — MIT CSAIL context extension via recursive decomposition (2025)
- Intel TDX — Trusted Execution Environment for confidential computing
- AMD SEV-SNP — Secure Encrypted Virtualization with Secure Nested Paging
This idea was born of a conversation on the Gas Town Hall Discord server:
[csells] @everyone Question for you: if we could build a thing together with all of our personal Gas Towns pointed at the same rig building something in a crazy 1000s of agents working on a set of issues together, what should we build?
Sure, the Cursor guys did this with their own homegrown gear to build yet another browser engine. But what if we could crowdsource something that would make the world better? Like actually. Better.
[elided] lots of good ideas...
[CryptoKaps] While I think that something is really required for managing AI Risks and preventing the potential for harm, it is going to be quite a long and neverending journey. How about a Global Compute Metabolism, think of it like a decentralized, "green" Gas Town that transitions AI from a raw energy sucker into a self-optimizing, distributed organism / network. Rather than relying on centralized data centers, this rig orchestrates thousands of agents to scout for idle, low-carbon compute across the globe, shifting workloads in real-time to where energy is cleanest. By rewarding a high "Joule-to-Intelligence" ratio, the network uses a swarm of Optimizer agents to perpetually evolve more efficient kernels and architectures, essentially "starving" inefficient code. THink democratized access to compute - it creates a self-correcting safety layer where the distributed nature of the grid acts as a natural check against centralized AI risk, ensuring that the future of intelligence is as sustainable as it is sovereign.
[CryptoKaps] No really, I think the current pouring of funds to build data centers.. is kind of ridiculous. I recently read somewhere that next DC in Australia is expanding its infrastructure Even if it becomes like a hub for supplying AI infrastructure to the rest of the world it's going to consume like 40% of the grid starving New South Wales of basic energy needs So the model is kind of unsustainable Maybe there's a better way to think about this and go bold
[CryptoKaps] Imagine a "Virtual Power Plant." When a node in Iceland has excess geothermal energy or a node in Australia has a solar peak, the rig shifts the "heavy lifting" (the Refineries) to those locations in real-time... that'd be cool. Literally.. cooler! haha
[csells] Yes! I think you're talking about a decentralized agent OS where agentic workloads can be shifted amongst nodes in the network (machines with agentic tools the OS can harness) based on CPU utilization, token limits, sustainability of available energy, anything. Think BitTorrent for Intelligence. SETI@home for inference.
[CryptoKaps] yea. So, The Infrastructure Layer: Node Daemon, Discovery Layer, Agent Runtime; The Orchestration Layer: Scheduler: The "brain." , Checkpoint/Migration Protocol: The "flow.", Reputation/Trust System.. "immune system".
[csells] I agree with where you're headed, but I think the MVP for us to build on can be simpler:
Node daemon → advertises available tokens/providers Mesh → routes requests to matching nodes Node → proxies to provider, returns response
No agent runtime, sandboxing or checkpointing (yet). Just a decentralized proxy mesh that pools spare intelligence.
Once we have that, I think we can start to move workloads to the Agentic Mesh Network (?) and build the rest out on top of the foundation.
Thoughts?
[CryptoKaps] Like it