Look up this machine's network keys
Use pear identity to read the seed, blind relay, blind peer, and blind peer client keys this machine presents to the network, and hand the right one to the right peer.
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.
Requires Pear 3.5.0 or newer—run pear versions to check what you're on. On 3.4.0 and earlier only pear blind-peer identity existed, which is now pear identity blind-peer-client; the other three keys had no command at all.
Need the pear CLI? Install it from install.pears.com, or prefix any command below with npx. See Install & upgrade for details.
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 keyWhich one you want depends on what the other side is going to do with it:
| They want to… | Run here | They pass it to |
|---|---|---|
| Wait until this machine has finished syncing a drive | pear identity seed | pear seed --until-sync <key> |
| Seed a drive into a blind peer running here | pear identity blind-peer | pear seed --blind-peer <key> |
| Route connections through a relay running here | pear identity blind-relay | --relay <key> |
| Authorize this machine against a blind peer they run | pear identity blind-peer-client | pear blind-peer start --trusted-peer <peer> |
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 z32 key, then a hint showing the command it is usually pasted into:
pear identity seed4ibhiwr1pstsw8h4gt3gti88m3de4zqb76bzsjjyomc9woipdbto
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.
The key goes to stdout and the hint to stderr, so command substitution captures the key alone:
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-clientt8hosp8paf3aizmm8tdww67qbbau5eatgcpwxkqze1erwsujbwey
Use the key above as a trusted peer for your blind peer
$ pear blind-peer start --trusted-peer=t8hosp8paf3aizmm8tdww67qbbau5eatgcpwxkqze1erwsujbweySend 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=t8hosp8paf3aizmm8tdww67qbbau5eatgcpwxkqze1erwsujbweyTrust is read at start time. A key added to --trusted-peer only takes effect on the next pear blind-peer start, and a blind peer that is already running will keep treating you as untrusted until it restarts.
Publish a blind peer's key
On the machine hosting the blind peer, print the server's own key:
pear identity blind-peerthgsq4d6gcrrmy5m979prx5ymtssq9abriit51p3xixdwfip8y6y
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.
Unlike the other three subcommands, this one is not a pure lookup. If no blind peer is running, it opens one against the platform blind-peer storage directory to read its key, creating that directory on first use. The key is derived from that storage, so it stays the same on every later call and on every pear blind-peer start.
Publish a relay's key
On the machine running the relay:
pear identity blind-relaynjw8bwd3euf4jypwzfrscr7qfz9d33u3w6y3yuodg5dpwcb89t3y
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 identityreference—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.