Skip to content

Reviewed announcement crossposts

Announcement crossposting has no immediate-call path. Set capabilities.announcementCrossposts: true and list every eligible direct announcement channel by exact ID in scopes.announcementCrosspostChannelIds. This allowlist must be a subset of readScope.channelIds when the read allowlist exists. A thread, its parent scope, a general text channel, or ordinary message-read authority never grants crosspost authority.

The Discord application must expose confirmed Message Content intent so planning can require and bind all content-bearing message fields. Only an exact default message in a direct GUILD_ANNOUNCEMENT channel is eligible. Polls, forwarded references, system messages, threads, batches, fuzzy selection, destination selection, and follower management are rejected. The bot requires View Channel, Read Message History, and Send Messages; it additionally requires Manage Messages when another user authored the message. An already-crossposted message is a record-free no-op.

  1. Call plan_announcement_crosspost with the exact direct announcement-channel ID, exact message ID, and a unique one-shot operation key.
  2. Review the verified application and bot IDs, exact guild and channel, untrusted message preview, current flags, Message Content intent, authorship class, complete permissions, unknown-fanout warnings, operation-key hash, and keyed digest.
  3. If the action is none, the message is already crossposted and no confirmation, reservation, activity record, or request is needed.
  4. Call execute_announcement_crosspost with identical inputs plus the digest.
  5. Approve the signed MCP confirmation only if every exact identity, message, permission, warning, operation-key hash, and digest remains intended.
  6. Review the returned response-snapshot match, readback-snapshot match, exact message URL, activity ID, and outcome before any follow-up.

Discord does not return the follower count or follower destination channels to the crosspost operation, so the connector cannot enumerate or constrain fanout before approval. Destination channels can lie outside the source guild's administrative boundary, and this connector has no crosspost rollback operation. The execute tool therefore advertises both destructive and non-idempotent annotations even though one-shot receipts and an already-crossposted no-op defend against replay.

The process-keyed HMAC digest binds the exact normalized request, operation-key hash, application and bot identities, Message Content intent, guild, connector membership, relevant roles, channel overwrites, effective permissions, authorship class, full review-relevant message snapshot, and current flags. Message content, attachment metadata, embeds, components, and references enter only the transient plan and opaque HMAC. They never enter activity records, receipts, diagnostics, telemetry, errors, or operator output. A connector restart invalidates the digest.

Execution rebuilds the plan before approval and again before mutation, durably coordinates the exact channel and message across connector processes sharing the activity-state root, atomically reserves the one-shot key, and appends a pending content-free activity record. It then sends exactly one non-retried POST /channels/{channel.id}/messages/{message.id}/crosspost, validates the complete returned message, fetches the exact message again, and accepts only the CROSSPOSTED bit being set while the identity, author, content, attachments, embeds, components, reference, timestamps, type, and unrelated flags remain unchanged.

A known pre-response Discord 4xx is failed. A transport failure, Discord 5xx response, malformed or mismatched success response, failed or drifting readback, or any other indeterminate state is uncertain. Every reserved key remains permanently spent, and an uncertain outcome retains the durable exact claims until credential-free operator review resolves them. The connector never retries, compensates, rolls back, or claims delivery to follower channels. See Discord's crosspost endpoint, message flags, and permission flags.

Canonical source: docs/reference.md

Documentation generated for guildcontrol@0.0.0. Canonical source and edit history remain in the public repository. GuildControl is an independent project and is not affiliated with or endorsed by Discord Inc. Discord is used only to identify the platform that GuildControl connects to.