Use case: Stuart meets Satoshi

Stuart and Satoshi are peers in a p2p messaging channel, similar to Signal. A did:btcr2 DID identifies each peer. Stuart rotates a key. Satoshi resolves the DID of Stuart and verifies the new key before Satoshi trusts a message.

In the terms of the specification, Stuart is the DID controller and Satoshi is a relying party. The diagrams do not show one implementation. They show the main path only. The other Diagrams pages show the details of each operation. Each diagram links to its Mermaid source file.

Who talks to whom

Stuart announces an update through a BTCR2 Beacon. Stuart gives the update data to Satoshi as Sidecar Data, or publishes it on CAS. Satoshi resolves the DID and trusts the new key only if the DID document contains it.

---
title: Stuart meets Satoshi - who talks to whom
---

%% Stuart and Satoshi are peers in a p2p, Signal-like messaging channel.
%% Stuart rotates a key. Satoshi verifies the new key.
%% Solid arrows: on-chain data. Dashed arrows: off-chain data.

flowchart TD
    Stuart(["Stuart<br/>DID controller"])
    Beacon["BTCR2 Beacon<br/>Singleton, CAS, or SMT"]
    BTC[("Bitcoin")]
    Data[("Sidecar Data<br/>or CAS")]
    Satoshi(["Satoshi<br/>channel peer"])

    Stuart -->|"(1) announce the update"| Beacon
    Beacon -->|"Beacon Signal"| BTC
    Stuart -.->|"(2) update data"| Data
    Stuart -.->|"(3) message signed<br/>with the new key"| Satoshi
    BTC -->|"(4) resolve the DID"| Satoshi
    Data -.-> Satoshi

Source: overview.mmd

Architecture

The components are logical responsibilities, not libraries. Stuart keeps the update data for the life of the DID: each update, and each CAS Announcement, SMT Proof, and nonce.

---
title: Stuart meets Satoshi - architecture
---

%% The components are logical responsibilities, not libraries.
%% Solid arrows: calls and on-chain data. Dashed arrows: off-chain data.

flowchart TD
    subgraph StuartApp["Stuart's application"]
      Ops["DID operations<br/>and signer"]
      Wallet["Bitcoin wallet"]
      Store[("Update data")]
    end
    Agg["Aggregation Service"]
    BTC[("Bitcoin")]
    CAS[("CAS / IPFS")]
    subgraph SatoshiApp["Satoshi's application"]
      Resolver["Resolver"]
      Trust[("Trusted keys")]
    end

    Ops --> Store
    Ops -->|"Singleton Beacon"| Wallet
    Ops -->|"CAS or SMT Beacon"| Agg
    Wallet --> BTC
    Agg --> BTC
    Store -.->|"optional"| CAS
    Store -.->|"Sidecar Data"| Resolver
    CAS -.-> Resolver
    BTC --> Resolver
    Resolver --> Trust

Source: architecture.mmd

First contact

Before a key rotation, the peers exchange DIDs and verify each other. A new DID has no Beacon Signals, so Satoshi gets version 1. Create shows how to create a k1 or an x1 DID.

---
title: Stuart meets Satoshi - first contact
config:
  sequence:
    actorMargin: 20
    width: 110
---

%% Before a key rotation, the peers exchange DIDs and verify each other.
%% The diagram shows one direction: Satoshi verifies Stuart.

sequenceDiagram
    autonumber
    actor Stu as Stuart
    participant BTC as Bitcoin
    actor Sat as Satoshi

    Stu->>Stu: Create the DID<br/>(offline, no cost)
    Stu->>BTC: Fund a Beacon Address<br/>for later updates
    Stu->>Sat: Signed message, did,<br/>Sidecar Data
    Sat->>BTC: Resolve the DID
    BTC-->>Sat: No Beacon Signals<br/>(version 1)
    Sat->>Sat: Verify the message.<br/>Trust the keys of Stuart.

Source: channel-setup.mmd