Monthly Archives: March 2026

March 14, 2026 · 10:24 am

Web 7.0 DIDLibOS is a Decentralized, DID-native Polyglot Host Platform

Create your own magic with Web 7.0™ DIDLibOS / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

A polyglot host is a software environment that can execute or embed multiple programming languages within the same process or platform.

Instead of being tied to one language runtime, the host provides infrastructure so different languages can run side-by-side and interact.

Core idea

Host Environment
     │
     ├─ Language Runtime A
     ├─ Language Runtime B
     ├─ Language Runtime C
     └─ Shared APIs / objects

The host provides:

  • memory management
  • object sharing
  • APIs
  • execution control

Each language plugs into that environment.

Example: PowerShell

PowerShell is a practical polyglot host because it can run or embed:

  • .NET languages (C#, F#)
  • JavaScript (via engines like )
  • Python (via )
  • legacy scripting via
  • external runtimes like or Python

PowerShell itself acts as the host orchestrating those runtimes.

Signature: FJpeiIffipEtKth2uSRzp5hJ5XWBwRh4uxc3LavBbQ0lDqQ4xnN3unpEecu9lVvrtItDTRrA/5E5AE5z2AoGXaSBZbQ9LmhcWTKP2uUJY9v/8/K5WilaK/v1A3GvKLdjvlGBjeW4YYHh7l7b53VoQiLzpcYUvySFZThC1SjyABaA3fyd8Z6fH2yB0okT8QUfMYNWI8+t09ye5CZNd0b1l9v2xmHKKzgzjcJjaYYUVWE=

Example: Web 7.0 TDA / Web 7.0 DIDLibOS

Example: Modern polyglot notebook hosts

A well-known example is .NET Interactive which supports:

  • C#
  • F#
  • PowerShell
  • JavaScript
  • SQL

in the same notebook.

Another example is Jupyner Notebooks which runs different languages through kernels.

What makes something a polyglot host

A system qualifies if it supports at least some of these:

CapabilityDescription
Multiple runtimesDifferent languages execute in the same environment
Shared dataLanguages exchange objects or values
Embedded interpretersEngines loaded as libraries
Runtime orchestrationHost decides what runs where

Three common architectures

1. Embedded runtimes

Languages run inside the host process.

Example:

Host
 ├─ Python runtime
 ├─ JavaScript runtime
 └─ shared object model

Example platform:

2. External runtimes

Host launches interpreters as subprocesses.

Example:

Host
 ├─ node
 ├─ python
 └─ Rscript

PowerShell often uses this approach.

3. Plugin scripting engines

Languages implement a host interface.

Example:

Host
 ├─ VBScript engine
 ├─ JScript engine
 └─ PerlScript engine

This was the design of Windows Script Host.

Simple definition

A polyglot host is:

A runtime environment that allows multiple programming languages to run and interact within a single platform.

Why they exist

Polyglot hosts let developers:

  • use the best language for each task
  • reuse existing ecosystems
  • integrate tools without rewriting everything

Leave a comment

Filed under Uncategorized

Tagged as , , , ,

March 1, 2026 · 10:28 am

SDO: Web 7.0 DID Interface Definition Language (DIDIDL) 0.22 — Draft Specification

Create your own magic with Web 7.0™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

Status: Draft
Version: 1.0
License: Apache 2.0
Editors: Michael Herman, Chief Digital Officer, Web 7.0 Foundation
SDO: Web 7.0 Foundation, Bindloss, Alberta, Canada

1. Abstract

DIDIDL defines a transport-neutral, message-type–centric capability description format for agents using using DIDComm.

DIDIDL enables agents to:

  • Publish typed tasks grouped under process capabilities
  • Describe request, response, and error schemas
  • Support machine-readable discovery
  • Enable client generation and validation

1.1 Key Concepts

  • APC Process Classification Framework (PCF)

  • Process Capability DID
    • did7://{authority}/{process-name}_{sedashver}:{capability-name}
  • Process Capability Task DID
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}/{task-name}
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/{task-name}
  • Process Capability Discovery
    • did7://{authority}/{process-name}/query-capabilities
    • did7://{authority}/{process-name}/disclose-capabilities
    • did7://{authority}/{process-name}_{semdashver}/query-capabilities
    • did7://{authority}/{process-name}_{semdashver}/disclose-capabilities
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}/query-capability
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}/disclose-capability
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/query-capability
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/disclose-capability

2. Terminology

TermDefinition
AgentA DIDComm-enabled entity
Process Capability (Capability)A grouping of tasks representing a business or functional process
Process Capability Task (Task)A DIDComm message type representing a callable function
SchemaA JSON Schema definition conforming to JSON Schema
Process DIDIDL Document (DIDIDL Document)JSON object conforming to this specification

Normative keywords MUST, SHOULD, MAY follow RFC 2119.

3. Canonical DID Patterns

Process Capability Task DID PatternPatternExample
Process Capability DIDdid7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}did7://web7/user-onboarding_1-0:enrollment_1-0
Process Capability Task DIDdid7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/{task-name}did7://web7/user-onboarding_1-0:enrollment_1-0/verify-email
Query/Disclose DID Messsage TypesPatternExample
Discovery Query Process Capabilitiesdid7://{authority}/{process-name}_{semdashver}/query-capabilitiesdid7://web7/user-onboarding_1-0/query-capabilities
Discovery Disclose Process Capabilitiesdid7://{authority}/{process-name}_{semdashver}/disclose-capabilitiesdid7://web7/user-onboarding_1-0/disclose-capabilities
Discovery Query Process Capability Tasksdid7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/query-capabilitydid7://web7/user-onboarding_1-0/query-capability
Discovery Disclose Process Capability Tasksdid7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/disclose-capabilitydid7://web7/user-onboarding_1-0:enrollment_1-0/disclose-capability

Web 7.0 DID Identifier/Message Type Syntax-Semantics Comparions

Web 7.0 Neuromorphic Agent Protocol Long-Term Memory (LTM) Model

4. DIDIDL Document Structure

4a. Process Capabilities

{
  "dididl": "1.0",
  "agent": "did7://agents.org/example:agent123",
  "capabilities": [...],
  "schemas": {...}
}

All tasks MUST be nested under exactly one process capability.

4b. Process Capability Tasks

{
  "id": "did7://web7/user-onboarding_1-0:enrollment",
  "name": "User Onboarding-Enrollment",
  "version": "1.0",
  "description": "Handles user lifecycle initiation",
  "tasks": [
    {
      "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/create-user",
      "request": "#/schemas/CreateUserRequest",
      "response": "#/schemas/UserDto"
    },
        {
      "type": "did7://web7/user-onboarding_1-0:enrollment_2-0/create-user",
      "request": "#/schemas/CreateUserRequest",
      "response": "#/schemas/UserDto"
    },
    {
      "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/verify-email",
      "request": "#/schemas/VerifyEmailRequest",
      "response": "#/schemas/VerifyEmailResponse"
    }
  ]
}

Rules:

  • Process Capability DIDs MUST follow the pattern:
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}
    • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}
  • Task DIDs are capability-scoped:
    • did7://{authority}:{process-name}_{semdashver}:{capability-name}/{task-name}
    • did7://{authority}:{process-name}_{semdashver}:{capability-name}_{semdashver}/{task-name}
  • Each task MUST belong to exactly one capability

4c. Process Capability Task

{
  "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/create-user",
  "request": "#/schemas/CreateUserRequest",
  "response": "#/schemas/UserDto",
  "errors": ["#/schemas/ValidationError"]
}

Rules:

  • Task DIDs MUST be unique within the agent
  • Versioning MUST be encoded in the DID
  • Request and response schemas MUST be referenced by JSON pointer

5. Discovery Protocol

5.1 Query Capabilities

Request

{
  "type": "did7://web7/user-onboarding_1-0/query-capabilities"
}

Response

{
  "type": "did7://web7/user-onboarding_1-0/disclose-capabilities",
  "capabilities": [
    {
      "id": "did7://web7/user-onboarding_1-0:userverification",
      "name": "User Verification",
      "version": "1.0",
      "description": "Handles user verification."
    },
    {
      "id": "did7://web7/credential-issuance_1-0/credentialissuance",
      "name": "Credential Issuance",
      "version": "1.0"
      "description": "Handles credential issuance."
    }
  ]
}

5.2 Query a Specific Capability

Request

{
"type": "did7://web7/user-onboarding_1-0:userverification/query-capability"
}
{
  "type": "did7://web7/user-onboarding_1-0:userverification_1-0/query-capability"
}

Response

{
  "type": "did7://web7/user-onboarding_1-0:userverification/disclose-capability",
  "capability": {
    "id": "did7://web7/user-onboarding_1-0:userverification_1-0",
    "name": "User Verification",
    "version": "1.0",
    "tasks": [
      {
        "type": "did7://web7/user-onboarding_1-0:userverification_1-0/create-user",
        "request": "#/schemas/CreateUserRequest",
        "response": "#/schemas/UserDto"
      },
      {
        "type": "did7://web7/user-onboarding_1-0:userverification_1-0/verify-email",
        "request": "#/schemas/VerifyEmailRequest",
        "response": "#/schemas/VerifyEmailResponse"
      }
    ],
    "schemas": {...}
  }
}

6. Normative Requirements

  1. Each task MUST appear in exactly one process capability.
  2. Process Capability DIDs MUST be unique within the agent.
  3. Task DIDs are capability-scoped and MUST be unique.
  4. Union of all process capabilities MUST form a disjoint partition of tasks.
  5. Schemas included in capability disclosure MUST only include referenced schemas.
  6. DIDComm authentication MUST protect all DIDIDL exchanges.
  7. Version changes that introduce breaking schema modifications MUST increment the major version in the DID.

7. Example Complete DIDIDL Document

{
  "dididl": "1.0",
  "agent": "did7://agents.org/example:agent123",
  "capabilities": [
    {
      "id": "did7://web7/user-onboarding_1-0:useronboarding",
      "name": "User Onboarding",
      "version": "1.0",
      "tasks": [
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_1-0/create-user",
          "request": "#/schemas/CreateUserRequest",
          "response": "#/schemas/UserDto"
        },
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_2-0/create-user",
          "request": "#/schemas/CreateUserRequest",
          "response": "#/schemas/UserDto"
        },
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_1-0/verify-email",
          "request": "#/schemas/VerifyEmailRequest",
          "response": "#/schemas/VerifyEmailResponse"
        }
      ]
    }
  ],
  "schemas": {
    "CreateUserRequest": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "email": { "type": "string" }
      },
      "required": ["email"]
    },
    "VerifyEmailRequest": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "token": { "type": "string" }
      },
      "required": ["token"]
    },
    "VerifyEmailResponse": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "success": { "type": "boolean" }
      },
      "required": ["success"]
    },
    "UserDto": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "id": { "type": "string" },
        "email": { "type": "string" }
      },
      "required": ["id", "email"]
    }
  }
}

Appendix B – APQC Taxonomies

Process Categories and Individual Processes

Appendix C – PowerShell Cmdlet Naming Specifications

Appendix D – Web 7.0™ DID-based, Decentralized Library Operating System (DIDLibOS)

Leave a comment

Filed under Uncategorized

Tagged as , , , ,