DomainGroup Variants for DomainSet Runtime Gating in OpenHuman

The DomainGroup enum in OpenHuman defines 21 distinct variants—from Agent and Memory to Web3 and Inference—that enable modular runtime gating via the DomainSet builder, allowing developers to selectively enable or disable entire functional families at startup.

The tinyhumansai/openhuman repository implements a sophisticated capability system centered on the DomainSet struct, which controls which functional domains are active during runtime. Understanding the available DomainGroup variants for DomainSet runtime gating is essential for configuring lightweight, security-hardened, or feature-specific deployments of the OpenHuman core.

What is DomainSet Runtime Gating?

DomainSet runtime gating allows the OpenHuman core to enable or disable whole families of functionality at startup. Rather than compiling out features, the system uses the DomainGroup enum variants as flags within a DomainSet instance. The builder pattern in src/core/runtime/builder.rs maps each variant to a dedicated field, creating a configuration that the runtime enforces throughout the application lifecycle. This architecture supports flexible deployments where agents, memory systems, or Web3 tools can be selectively excluded based on environment requirements.

Complete List of DomainGroup Variants

The DomainGroup enum, defined in src/core/all.rs, contains 21 variants representing distinct functional families. Each variant corresponds to a specific subsystem that can be independently gated.

• Agent: Core agent-harness tools and orchestration
• Memory: Persistent memory stores and retrieval
• Threads: Thread-level goal and todo management
• Config: Global configuration handling
• Security: Credential, device and policy enforcement
• Flows: Automation workflow engine
• Skills: SKILL.md catalog and runtime
• Mcp: MCP (Model-Control-Protocol) server integration
• Channels: External messaging providers (Telegram, Discord, etc.)
• Web3: Crypto wallet, X-402 payments and blockchain tools
• Voice: Speech-to-text / text-to-speech services
• Media: Media generation (image, audio, etc.)
• Medulla: Medulla-specific back-end orchestration
• Inference: Inference back-ends (LLM, embeddings, etc.)
• Integrations: Third-party integrations (Composio, etc.)
• Automation: Cron-based automation and scheduled jobs
• Runtimes: Runtime environments (Node, Python, etc.)
• Desktop: Desktop-specific UI and window management
• Hosted: Hosted back-end services
• Modules: Dynamically loaded native modules
• Platform: Core platform services (logging, health, etc.)

Source Code Implementation

Enum Definition in src/core/all.rs

The canonical definition of the DomainGroup enum resides in src/core/all.rs. This file enumerates all 21 variants, establishing the complete set of functional families available for runtime gating. Each variant is a unit variant (no associated data), serving as a typed identifier that the rest of the codebase uses to check permissions and capabilities.

Builder Integration in src/core/runtime/builder.rs

The DomainSet builder pattern is implemented in src/core/runtime/builder.rs. According to the source code, each DomainGroup variant maps to a dedicated boolean field within the builder, confirming the complete list of gateable domains. The .with() method enables specific variants, while the internal structure ensures that only explicitly enabled domains are available to the runtime context.

Runtime Enforcement

Gating logic is enforced through multiple files:

• src/core/runtime/context.rs: Contains the runtime context implementation where stores and subsystems check the DomainSet to determine if their corresponding DomainGroup is active before executing operations.
• src/openhuman/tools/ops.rs: Classifies agent tools into their respective DomainGroup variants for runtime filtering, ensuring that tools belonging to disabled domains cannot be invoked.

Practical Implementation Examples

To create a custom DomainSet that enables only the agent, memory, and threads families:

use openhuman_core::core::runtime::builder::DomainSet;

let domains = DomainSet::new()
    .with(openhuman_core::core::all::DomainGroup::Agent)
    .with(openhuman_core::core::all::DomainGroup::Memory)
    .with(openhuman_core::core::all::DomainGroup::Threads);

Checking whether a particular domain is enabled at runtime:

let enabled = domains.allows(openhuman_core::core::all::DomainGroup::Web3);
println!("Web3 enabled? {}", enabled);

Applying the DomainSet when building a core instance:

let core = openhuman_core::core::CoreBuilder::new()
    .domains(domains)          // ← applies the gating
    .services(ServiceSet::full())
    .build()
    .await?;

Summary

• The DomainGroup enum in src/core/all.rs defines 21 distinct variants representing functional families like Agent, Memory, Web3, and Inference.
• DomainSet runtime gating is configured via the builder pattern in src/core/runtime/builder.rs, mapping each variant to a dedicated field.
• Runtime enforcement occurs in src/core/runtime/context.rs and src/openhuman/tools/ops.rs, ensuring disabled domains cannot be accessed.
• Developers create gated configurations using .with() for specific variants and check permissions with .allows().
• This system enables lightweight, specialized OpenHuman builds by excluding unnecessary subsystems at startup.

Frequently Asked Questions

Where is the DomainGroup enum defined in OpenHuman?

The DomainGroup enum is defined in src/core/all.rs. This file serves as the central registry for all 21 functional family variants used throughout the runtime gating system.

How do I check if a specific domain is enabled at runtime?

Use the .allows() method on a DomainSet instance, passing the DomainGroup variant you want to check. For example: domains.allows(DomainGroup::Web3) returns a boolean indicating whether Web3 functionality is active.

Can I modify the DomainSet after building the Core?

No. The DomainSet is configured at build time via CoreBuilder::new().domains(domains) and applied when .build() is invoked. Once the Core instance is created, the domain gating is fixed for that runtime session.

What is the difference between DomainGroup and DomainSet?

DomainGroup is an enum variant (e.g., Agent, Web3) representing a single functional family, while DomainSet is a collection struct that tracks which variants are enabled. The DomainSet acts as the runtime gate, using the DomainGroup variants as keys to determine available capabilities.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}