2. Cross-Mesh Communication

DIDComm, subscriptions, and relationship classes.

Learning objectives

By the end of this lesson you will be able to:

  • Explain how a subscription becomes a cryptographic relationship.
  • Describe when DIDComm is used versus when local engine traffic is kept local.
  • Distinguish family relationships (parent/child via ECI) from external relationships (subscriptions via did:peer).
  • Author a subscription configuration and a DIDComm message envelope in YAML.

Prerequisites

Subscriptions become cryptographic relationships

Picos that are not related through the parent/child hierarchy communicate using subscriptions. A subscription is a pairwise relationship represented on both sides.

In Pico Engine 1.6, a Pico can initiate a subscription using the recipient’s did:webvh:

Pico A
   │
   │ recipient did:webvh
   ▼
Resolve Pico B identity
   │
   ▼
Introduction handshake
   │
   ▼
Create peer DIDs
   │
   ▼
Establish subscription
   │
   ▼
Encrypted relationship

Once the relationship exists, events and queries use that peer relationship rather than repeatedly relying on the public identity.

DIDComm

Cross-mesh and cross-engine Pico communication now uses DIDComm:

Mesh A                          Mesh B
┌──────────────────┐          ┌──────────────────┐
│ Pico Engine A    │          │ Pico Engine B    │
│                  │          │                  │
│   Pico A         │ DIDComm  │   Pico B         │
│   did:peer:A ───────────────►│   did:peer:B    │
│                  │ encrypted│                  │
└──────────────────┘          └──────────────────┘

When communication occurs within the same mesh, the engine can keep the traffic local. When it crosses meshes or engines, DIDComm provides encrypted communication using the peer relationship.

Two relationship classes

Not every Pico relationship requires a DID. Legacy ECIs remain relevant. Parent and child Picos continue communicating over their family channels using ECIs.

Pico relationships
├── Family relationship
│   ├── parent
│   └── child
│
│   Identity/addressing:
│   ECI
│
└── External relationship
    └── subscription
    Identity:
    did:webvh → introduction
    did:peer  → established relationship

A full DID-based introduction would be unnecessary overhead for relationships already established structurally within a Pico family.

Lesson pages

  • Exercise — a short, guided task you complete inline.
  • Lab — author a subscription and a DIDComm envelope.
  • Summary — the key takeaways of the lesson.
  • Quiz — a short knowledge check.

Next

Continue with the Exercise.