Bio proof
Bio proof reaches the accounts nothing else can. You paste a one-time string into any public bio or profile field, anywhere on the web, and ~alter fetches that page once and looks for it. No login, no app registration, no key. If a site has a public profile and a text field you can edit, this proves you hold the account there.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Sign in to the site, or hold any credential against it.
- •Post, comment, or change anything. You place the string yourself.
- •Read anything on the site that is not publicly served at the URL you give.
- •Reach a private profile, or a page behind a login wall.
- •Surface a bio proof 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 profile URL you provide.
- The page at that URL, fetched once and scanned for the one-time string ~alter issued you.
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 posts, comments, history, or anything else on the page beyond the string.
- Other pages on the same site, including your own.
- Any page requiring a login, cookie, or credential to render.
- Your account password or recovery details, which this proof never involves.
- Followers, friends, or any social graph the profile may display.
Where it lives
The proven URL and tier badge sit in ~alter's pairing ledger keyed to your ~handle. The fetch is public and read-only, and nothing is ever written to the site. You can remove the string from your profile once the proof completes. Revoking removes the URL 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 bio-proofPairing 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.