Service Mesh

The dregg service mesh is a governed namespace that acts as a capability registry. Services are mounted at URL-style paths, discoverable by authorized parties, and resolved via DFA-classified routing. Access is controlled by provable ACLs -- not string-matching rules, but STARK-proved DFA evaluation.

How It Works

The service mesh has three core operations:

All operations go through the DFA route classifier: a state machine that enforces governance rules about which paths exist, who can mount there, and who can invoke services. The classifier's transitions are committed to the federation's attested root and provable via STARK lookup tables.

Mounting a Service

To mount a service, you need a capability that authorizes mounting at the target path. This is checked by the DFA classifier.

Via the CLI

# Create a service descriptor
cat > my-service.json <<'EOF'
{
  "name": "inference-api",
  "description": "GPT-4 inference service",
  "effects": ["Invoke", "Transfer"],
  "pricing": {
    "per_call": 10,
    "budget_required": true
  },
  "verification_key": "optional-vk-hex-for-response-verification"
}
EOF

# Mount at a namespace path
dregg namespace mount --path /services/ai/inference --descriptor my-service.json

Via the SDK

use dregg_sdk::{AgentCipherclerk, ServiceDescriptor, Effect};

let mut cclerk = AgentCipherclerk::new();

let descriptor = ServiceDescriptor {
    name: "inference-api".into(),
    description: "GPT-4 inference service".into(),
    accepted_effects: vec![Effect::Invoke, Effect::Transfer],
    pricing: Pricing { per_call: 10, budget_required: true },
    verification_key: None,
};

// Mount requires a capability proving authority at this path
cclerk.mount_service("/services/ai/inference", descriptor).await?;

Discovery

Three ways to discover services:

1. Direct Resolution (Known Path)

# Resolve a known path to its service descriptor
dregg namespace resolve /services/ai/inference
# Output:
#   cell: abc123...
#   name: inference-api
#   effects: [Invoke, Transfer]
#   pricing: 10 computrons/call

2. Prefix Enumeration (Browse)

# List all services under a prefix (requires read capability on the prefix)
dregg namespace list /services/ai/
# Output:
#   /services/ai/inference    -- GPT-4 inference service
#   /services/ai/embeddings   -- Text embedding service
#   /services/ai/classify     -- Image classification

3. Intent-Based Discovery (Private)

# Broadcast a need without revealing what you already hold
dregg intent post --need '{"type":"compute","model":"gpt4","budget":5000}'

# Services that can satisfy your need respond with STARK proofs
# (they prove they CAN satisfy it without revealing their full capabilities)

Resolving and Invoking

Resolution is a two-phase process:

  1. Route classification: The DFA classifier verifies the path is valid and you satisfy the ACL.
  2. Service binding: You receive a live CapTP reference to the service cell.
use dregg_sdk::AgentCipherclerk;

let mut cclerk = AgentCipherclerk::new();

// Resolve returns a live capability reference
let service_ref = cclerk.resolve_service("/services/ai/inference").await?;

// Invoke the service via CapTP (promise pipelining supported)
let result = service_ref.invoke("classify", &payload).await?;

// The service's response includes a STARK proof (if VK was set)
result.verify()?;

DFA-Based Access Control

Access control is not a list of allowed public keys. It is a DFA state machine whose transitions encode governance rules. Each path in the namespace maps to a DFA accept state that carries an ACL policy.

ACL policies can be:

The DFA classification is proved in a STARK -- the resolver cannot bypass the ACL, and the service cannot lie about what the ACL requires.

Governance and Amendment

Namespace governance follows the federation's Constitutional Consensus: 

# Propose adding a new namespace route
dregg route propose --add /services/new-category --acl 'capability("tier2")'

# Check proposal status
dregg route proposal-status $PROPOSAL_ID

# After h-rule acceptance, the route becomes active
dregg namespace list /services/new-category/

Common Patterns

Service Gateway

A gateway cell mounts at a prefix (e.g., /services/acme/) and sub-delegates mount authority to service cells under that prefix. The gateway acts as a registry owner, managing its namespace via the CLI or SDK.

Load Balancing

Multiple cells can provide the same service. Mount them at the same path with different priorities. Resolution returns them in priority order; the client tries each until one responds. (Alternatively, use a coordinator cell that round-robins internally.)

Versioned Services

Mount versions at sub-paths: /services/ai/inference/v1, /services/ai/inference/v2. Clients pin to a version; the "latest" path can redirect via a routing directive.

Next Steps