bzDiD

your two addresses

one you, two ways to be reached: one on bluesky, one on nostr. both grow from the same root, and neither of them is the root.

the secret half is never shown on this page.
reading this page…
make your real ones in the wallet

never type your recovery words here. any word shows the shape.

two rails

tap a ring · light both
bluesky · did:plcnostr · npubthe root · never here
bzDiD://root → did:plc + npub
custody = self this front reads 0 fields · holds 0 keys
fieldvalue, as this page states it

binding pipeline · one root, two rails

    receipt · read from this page, now

    verify · no trust in this page needed
    1. printf %s bnr.b/did-plc/demo-root | sha256sum | cut -c1-24 equals the shape an empty box draws
    2. wallet.html → npubFromSeed: the real npub is NIP-19 bech32 of the x-only secp256k1 key
    3. view source: this front calls sha256hex on a constant, never on the box
    view source ↗ new tab fork the template ↗ new tab

    the whole binding surface

    🗝 your two addresses

    one bzDiD root · two mailing rails — bsky (did:plc) and nostr (npub) · TASKS 1+2 of the comms ledger

    ① the bsky address — did:plc

    did methoddid:plc (portable, PDS-hosted, ATProto)
    derivation rolebzDiD root ATTESTS the plc signing key (never is it)
    plc documentdid:plc:<rotation-0-hash-of-root>
    also_known_asat://handle.beehive
    escrow event fieldbuyer_did / seller_did: did:plc:…
    law: the plc did is a HANDLE, not the root — lose it and the root re-attests a new one. rotation keys held by the bzDiD ceremony; the escrow fixtures already speak this field.

    ② the nostr address — npub

    key schemesecp256k1 pair, bech32 (npub/nsec)
    derivation rolebzDiD root derives the pair via registered context
    npub (public)npub1<bech32-of-derived-pub>
    nsec (secret)never rendered, never on-chain, client-held only
    NIP-05name@beehive.nature
    DM payloadpointers only (?room ?order ?piece) — never content
    law: the npub is an ADDRESS of the root, not the root itself; relays carry ciphertext (NIP-44 class), and the derivation context is registered so any client can re-derive from the ceremony. secp256k1 vendoring docks with the engine (bzdid-key carries ed25519 today).

    ③ the binding attestation (on-chain row)

    attestation eventdid-bind: {root_fp, plc, npub, ts, sig}
    whereVaulta custom_json lane (the event layer already chosen)
    costHP-only, free forever at stake (measured 17/20 ops are custom_json)
    the interweave: one soul, two mailing addresses, both revocable, both re-derivable. bAccords (TASK 4) stamp both fields on every card and event.
    ⌂ hub