Skip to main content
API Preview
Build

Mastodon

Attesting Mastodon proves you hold an account by putting a one-time string somewhere public on your profile, then letting ~alter read it back. There is no login step and ~alter registers no application on your instance, so an instance admin is never asked to approve anything. It is the same move Mastodon's own verified-links feature already asks of you.

What pairing does not authorise

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

  • •Post, boost, reply, or send a direct message from your account.
  • •Follow or unfollow anyone, or read who follows you privately.
  • •Sign in to your instance, or hold any token against it.
  • •Change your display name, bio, or profile fields. You place the string yourself.
  • •Surface your Mastodon 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 account address you provide, in the form user@instance.
  • Your public actor record, found by the standard WebFinger lookup that address resolves through.
  • Your public bio and profile fields, read once to find the one-time string you placed there.

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, boosts, replies, and favourites.
  • Your followers, follows, and blocks.
  • Direct messages and followers-only posts, which the public actor record does not carry.
  • Your email address or anything held privately by your instance.
  • Other accounts you hold on the same instance or elsewhere in the fediverse.

Where it lives

The attested address and tier badge sit in ~alter's pairing ledger keyed to your ~handle. Both fetches are public and read-only, and nothing is ever written to your instance. You can remove the one-time string from your profile once pairing completes. Revoking removes the address 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 mastodon

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.