Skip to main content
API Preview
Build

IndieAuth

IndieAuth signs you in as your own website. You give ~alter a profile URL you control, ~alter discovers the authorisation endpoint that URL advertises, and you approve the pairing at your own server rather than at any platform's. Nobody issues ~alter a credential in this flow, because the identity being proven is a domain, not an account.

What pairing does not authorise

Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:

  • •Publish, edit, or delete anything on your site.
  • •Read pages on your domain that are not publicly served.
  • •Act as you against any other IndieAuth client or service.
  • •Reach any account you sign into elsewhere with the same domain.
  • •Surface your IndieAuth 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 profile URL you supply.
  • The discovery links that URL publishes, read to find your authorisation and token endpoints.
  • The verified profile URL your own authorisation server returns when you approve the pairing.

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.

  • Page content, posts, or markup beyond the discovery links themselves.
  • Any profile detail your server may offer alongside the URL, since no scope is requested.
  • Other domains you own, or other URLs on the same domain.
  • Your visitors, analytics, or anything about who reads your site.
  • Credentials of any kind. You authenticate at your server, never to ~alter.

Where it lives

The verified profile URL and tier badge sit in ~alter's pairing ledger keyed to your ~handle. If you move the domain or retire it, re-pair from the new URL to keep the binding live. 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 indieauth

Pairing 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.