Skip to main content
API Preview
Build

Bluesky

Pairing Bluesky lets ~Alter recognise the shape of your presence on a decentralised social graph: your home PDS, the feeds you take part in, the rough rhythm of your posting. Content stays in your repo; only the structure is read.

What pairing does not authorise

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

  • •Post, repost, quote, reply, or like anything on your behalf.
  • •Send direct messages or read existing message threads.
  • •Follow, unfollow, block, or mute any account.
  • •Change your profile, handle, or any account setting on your PDS.
  • •Read content you have not made publicly visible.
  • •Share your social-graph data with 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

  • Your AT-Protocol DID, ~handle, home PDS, display name, and public bio.
  • Public follower / following counts: magnitudes, not lists.
  • Public posting cadence aggregated to weekly buckets: when you contribute, not the prose.
  • Custom-feed memberships you have made public. Recognises the shape of communities you take part in.

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.

  • Direct messages of any kind, sent or received.
  • Post bodies, replies, or quote-text. Only timing and presence are read.
  • Per-account follow / follower lists (only the counts).
  • Muted accounts, blocked accounts, or labeller-source state.
  • Email address tied to the account, even when the OAuth scope exposes it.

Where it lives

Evidence is stored in ~alter's pairing ledger keyed to your ~handle, encrypted at rest, with a tier badge (T1 OAuth-attested or T2 ownership-confirmed). Your AT-Protocol DID is the binding identifier. If you migrate PDS, the pairing carries. Aggregated patterns feed your identity vector only after a separate consent row is granted.

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 bluesky

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.