Skip to main content
API Preview
Developers

How pairing works

Pairing is the act of letting ~Alter recognise that an existing surface of your life (a code platform, a research identifier, a domain you own, a wallet) already speaks for some part of who you are. It is not delegation, account-linking, or sign-in. It is a one-direction read attached to an explicit consent row that you can sever at any moment.

Pairing a data source is not signing in

You sign in by adding ~Alter as a connector in your AI client and choosing your ~handle. That is the way in, and it is the only thing that signs you in. Pairing a data source comes after, and never stands in for it.

The word “connector” is used two ways across these docs, and the difference matters here:

  • The connector you sign in with. This is the connection between your AI client and ~Alter. You add ~Alter as a custom connector at mcp.truealter.com, sign in through the browser, and choose your ~handle. This is how you are known.
  • The data sources you pair. These are surfaces (GitHub, Obsidian, Discord, X) you pair to deepen your identity vector. Pairing one grants a one-direction read of a pattern you already show. It does not sign you in and never could.

Why this is not the shape of a scam

Phishing and account-takeover schemes share a tell: they ask for write power and they conceal what they will do with it. Pairing inverts both properties on purpose.

  • The scope we request from every OAuth provider is the smallest read-only grant that lets us recognise the pattern we describe. Each data-source connector page lists it.
  • ~Alter never sees, holds, or transmits write credentials. The OAuth token is held in a single rotating slot scoped to the connector and never reused.
  • For non-OAuth pairings (DNS, .well-known, wallet attestations), the proof is a public artefact you create (a TXT record you publish, a file you sign), never a credential you hand over.
  • Each pairing carries a revoke command. Revocation is immediate, tears down the OAuth grant on the provider side, and writes an audit row that you can inspect.

What pairing means, in plain language

When you pair a data-source connector, you are saying:

  • “The pattern this surface shows of me (the rhythm, the collaborators, the public artefacts) is part of who I am.”
  • “~Alter may read that pattern at a defined cadence and feed the derived recognition into my identity record.”
  • “Anything beyond reading that pattern is a separate decision, with its own consent row, that I make later.”

You are not saying “~Alter may act on my behalf,” “~Alter may share this with third parties,” or “~Alter may enrol me in matching, ranking, or third-party surfaces.” Each of those requires its own deliberate consent step.

What stays safe after you pair

  • Your accounts. Pairing cannot post, push, message, modify settings, or change membership anywhere. The connector pages enumerate what each pairing structurally cannot do.
  • Your private contents. Private repositories, direct messages, unpublished works, and wallet contents are out of scope at the connector boundary, refused even when the provider would technically permit access.
  • Your decisional surface. Pairings feed recognition, not delegation. No agent or organisation can query a derived signal without a separate consent row scoped to that recipient. Sharing is never transitive.
  • Your right to leave. Every pairing is revocable. Revocation revokes the OAuth grant where one exists, stops all further reads, purges the derived signals the pairing fed into your identity vector, and writes an audit entry. The identity record remembers that a recognition was withdrawn. One record is kept on purpose: that the account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your vector. That cooldown record holds the raw snapshot until the window passes, is never read into a new signal while disconnected, and is shared with no one.

How these guarantees are enforced

The data-source connector boundary is the enforcement layer. Each connector implements a fixed allowlist of fields and a fixed refusals list; anything outside the allowlist is dropped before storage, even when an upstream API returns it. This is structural, not policy-and-trust.

On top of that, the broader return commitment in our Privacy Policy and the consent model documented in the consent docs mean every derived signal carries its own revocable consent row. Pairing is the first floor; nothing rests on it without a deliberate step above it.

Per-source trust pages

For the exact reads, refusals, “what we cannot do” list, storage, and revoke command of each data-source connector:

Code

  • GitHub
  • GitLabsoon
  • ORCID iDsoon
  • ISNIsoon

Social

  • Discord
  • Xsoon
  • Blueskysoon
  • LinkedInsoon

Identity

Local