Look up this machine's network keys

Several Pear workflows need a key that only exists on another machine: a blind peer operator needs yours before they will announce your drive, and you need theirs before you can seed to it. pear identity prints those keys on the machine you run it on, one subcommand per key.

The four keys are different values and are not interchangeable—handing over the wrong one produces a service that silently does less than you expect rather than an error.

Pick the key you need

Run pear identity with no subcommand to see the list:

pear identity

  pear identity [flags] [command]

  Show local network public keys

  Flags:
    --json              Newline delimited JSON output
    --help|-h           Show help

  Commands:
    seed                Show seed key
    blind-relay         Show blind relay key
    blind-peer          Show blind peer key
    blind-peer-client   Show blind peer client key

Which one you want depends on what the other side is going to do with it:

The last two rows are the ones to get right: blind-peer is the key of a blind peer you host, and blind-peer-client is how you appear to someone else's blind peer. They are different key pairs and each is useless in the other's place.

Read a key

Every subcommand prints one key, z32-encoded like the key in every pear:// link, then a hint showing the command it is usually pasted into:

pear identity seed

4ibhiwr1pstsw8h4gt3gti88m3de4zqb76bzsjjyomc9woipdbto

Use the key above to wait until this peer has synced
  $ pear seed --until-sync=4ibhiwr1pstsw8h4gt3gti88m3de4zqb76bzsjjyomc9woipdbto <link>

The key is the same value pear seed reports in its Whoami: row, so you no longer need a seed session running to read it.

KEY=$(pear identity seed)

Authorize this machine with a blind peer

A blind peer only announces cores for peers its operator trusts. Untrusted requests are still stored and served, but never announced—so peers looking for a source will not discover it through that blind peer, and nothing in your own output says so. Getting authorized is what avoids that.

On your machine, print the identity the blind peer will see:

pear identity blind-peer-client

t8hosp8paf3aizmm8tdww67qbbau5eatgcpwxkqze1erwsujbwey

Use the key above as a trusted peer for your blind peer
  $ pear blind-peer start --trusted-peer=t8hosp8paf3aizmm8tdww67qbbau5eatgcpwxkqze1erwsujbwey

Send that key to the blind peer's operator. On their machine they restart the blind peer with it—--trusted-peer is repeatable, one per authorized client:

pear blind-peer start --trusted-peer=t8hosp8paf3aizmm8tdww67qbbau5eatgcpwxkqze1erwsujbwey

Publish a blind peer's key

On the machine hosting the blind peer, print the server's own key:

pear identity blind-peer

thgsq4d6gcrrmy5m979prx5ymtssq9abriit51p3xixdwfip8y6y

Use the key above as a blind peer for seeding
  $ pear seed --blind-peer=thgsq4d6gcrrmy5m979prx5ymtssq9abriit51p3xixdwfip8y6y <link>

This is the same key pear blind-peer start prints as Blind peer started listening using public key:, so you can hand it out before ever starting the server—handy when you are writing down connection details for a host that is not up yet.

Publish a relay's key

On the machine running the relay:

pear identity blind-relay

njw8bwd3euf4jypwzfrscr7qfz9d33u3w6y3yuodg5dpwcb89t3y

Use the key above as a blind relay for your swarm
  $ pear --relay njw8bwd3euf4jypwzfrscr7qfz9d33u3w6y3yuodg5dpwcb89t3y seed <link>

The relay key pair is derived from the platform corestore, so it is stable across restarts—note it down once. See Relay connections through a blind relay for the end-to-end setup this key slots into.

Read a key from a script

--json is declared on pear identity itself, so it goes before the subcommand:

pear identity --json seed

{"cmd":"identity","tag":"final","data":{"success":true,"publicKey":"4ibhiwr1pstsw8h4gt3gti88m3de4zqb76bzsjjyomc9woipdbto"}}

Read .data.publicKey. --json also suppresses the hint entirely, so there is nothing else on either stream to filter out.

Putting the flag after the subcommand is rejected rather than ignored:

{"cmd":"identity","tag":"error","data":{"success":false,"code":"UNKNOWN_FLAG","message":"Unrecognized Flag: --json"}}

Troubleshooting

✖ Unrecognized Argument at index 0 with value identity — you ran pear blind-peer identity, which was removed in 3.5.0. Use pear identity blind-peer-client; it prints the same key.

✖ Unrecognized Flag: --json — --json went after the subcommand. Move it in front: pear identity --json seed.

The blind peer accepted your request but peers still cannot find the drive — the announce was downgraded because the blind peer does not trust you. Check that its operator started it with your blind-peer-client key, not your seed key, and that they restarted it after adding you.

Two machines report the same key — they are sharing a platform directory. Each machine derives these keys from its own platform corestore, so identical keys mean the same storage is mounted in both places.

See also

• pear identity reference—every subcommand, the JSON shape, and each key's origin.
• Keep data available with blind peering—what the blind peer keys are for.
• Relay connections through a blind relay—what the relay key is for.
• Availability and blind peering—why a blind peer distinguishes trusted from untrusted clients at all.