Telegram
Pairing Telegram is a verification checkpoint: you open a one-time link to ~alter's bot and send the pre-filled /start message, and Telegram's own Bot API tells us who sent it. This is not Telegram's browser Login Widget, ~alter has no browser dashboard to host it on, it is a direct message round-trip with the bot you are already talking to.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Send messages to you, or to anyone else, through the bot beyond the pairing confirmation.
- •Read your other chats, contacts, channels, or groups. The bot only ever sees the one /start message you send it.
- •Post, forward, or react on your behalf anywhere in Telegram.
- •Add you to a channel or group, or use this pairing to contact you again later without your action.
- •Share your Telegram identity 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 Telegram numeric user id, as delivered by the /start message.
- Your @username and display name (first and last name), if set.
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.
- Message content beyond the one-time pairing token itself.
- Phone number, contacts, or chat history.
- Channel or group memberships.
- Any field not present in the /start message that completes pairing.
Where it lives
The account id and display name sit in ~alter's pairing ledger keyed to your ~handle. The one-time pairing token lives only long enough to be matched to your /start message (minutes, not days) and is discarded either way.
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 telegramPairing 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.