Discord
Pairing Discord lets ~Alter recognise the community shape of your life: the rooms you keep, the cadence of your presence, the affinity clusters you sit inside. The content of your conversations is never read.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Send messages on your behalf in any guild, DM, or thread.
- •Read your direct-message threads or anyone else’s, ever.
- •Join, leave, or change your membership in any guild.
- •Add, remove, or modify any role you hold; assign roles to others; modify channel permissions.
- •Surface your Discord guild list to other ~alter members, agents, or organisations without a separate consent row scoped to that recipient.
- •Re-share Discord-derived signals with any third party beyond what is publicly visible on your Discord profile.
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 Discord ~handle and display name as the OAuth provider returns them.
- The count of servers you belong to. Server names and IDs are never collected.
- Account-creation age and public profile flags, as Discord returns them.
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 contents. The connector never holds read-message scope.
- Direct-message threads or DM metadata.
- Voice-channel transcripts or speaking time.
- Friend list or connections graph.
- Email or phone tied to the Discord account.
Where it lives
Evidence is stored in ~alter's pairing ledger keyed to your ~handle, encrypted at rest, refreshed on each successful re-auth. Only the count of servers you belong to is read from the guild list; server names are never collected or stored, so they cannot appear in matching, recognition, or any external query.
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 pair revoke discordPairing 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.