Nostr (NIP-05)
Attesting Nostr composes two proofs that need nothing from ~alter and nothing from a relay. You sign a one-time challenge with your Nostr key, which shows you hold it, and your name@domain identifier is checked against the mapping the domain owner publishes, which shows somebody else vouches for the pairing. ~alter registers no app and holds no key.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Publish a note, reaction, or zap from your key.
- •Post to, or read from, any relay on your behalf.
- •Follow or mute anyone, or change your relay list.
- •Reconstruct your private key. Signature verification never touches it.
- •Surface your Nostr pairing to any third party without a separate consent row scoped to that recipient.
The OAuth or attestation scope we request is the minimum required to recognise the pattern described in What we read. Anything beyond that is structurally refused at the connector boundary, not promised by trust. How pairing works.
What we read
- The public key you declare, in its 32-byte x-only form.
- A signature over a single-use challenge ~alter minted, verified once and then discarded.
- The public NIP-05 mapping file at the domain in your identifier, read to confirm it names your key.
What we don't read
~Alter explicitly refuses these fields even when the OAuth scope or API permits them. Every refusal is enforced at the connector boundary, not by trust.
- Your notes, reactions, zaps, and anything else you have published.
- Your relay list, follows, mutes, and direct messages.
- Any other key you hold, or any other identifier pointing at the same key.
- Your private key or seed. Neither is ever requested or transmitted.
- Lightning addresses or wallet balances associated with your profile.
Where it lives
The attested pubkey, identifier and tier badge sit in ~alter's pairing ledger keyed to your ~handle. Because the domain owner can repoint your identifier at a different key at any time, this pairing re-checks every seven days rather than the usual ninety. Revoking removes it from your pairing surface immediately.
How to revoke
Revocation is immediate. Ask the AI client you paired through to revoke this connector, or revoke it from your consent surface over the same connection. Either path revokes the provider token, stops all further reads, and purges the derived signals this connector fed into your identity vector. An audit row records the revocation.
One thing is kept on purpose. The connector retains a record that this account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your identity vector. That cooldown record holds the raw profile snapshot until the window passes. It is never read into a new signal while disconnected, and it is not shared with anyone.
Prefer the command line? The CLI is the optional deeper path and revokes the same connector:
CLI (optional)
alter unpair nostrPairing this connector does not enrol you in any matching, ranking, or matching surface. Every downstream use requires its own consent row. See the consent model.