extension-posting-to-x

This extension is the mandatory recipe for any Caffeine build that publishes content to an X (Twitter) account. The only supported path is the x-client mops package (generated Motoko bindings for the X API v2, including TweetsApi.createPosts and related calls) driven by an OAuth 2.0 Authorization Code with PKCE flow. Hand-rolling ic.http_request calls to api.x.com endpoints is treated as a forbidden anti-pattern because it leaks the OAuth bearer across replicated outcalls (a security and roughly 13x billing problem) and bypasses x-client's handling of X's null-field semantics, where X returns null for absent fields and rejects explicit null on writes. The skill is scoped to X writes only (tweet, retweet, quote-tweet, status update, live-tweet); reading from X timelines, search, or user lookup stays on the separate extension-http-outcalls path.

The auth model uses per-user bearer tokens rather than a single canister-wide key: each end-user authorises the canister independently, and the canister stores their access_token plus refresh_token keyed by caller Principal. Tokens expire in roughly two hours and are refreshed silently via the refresh_token, which rotates on every refresh and must always be persisted anew. An X Developer App Client ID (a public identifier, not a secret) is required, with three variants the spec can pick from: an admin Client ID registered once by the canister owner and shared by all users (the recommended default), a per-user Client ID where each tenant brings their own app to avoid sharing rate-limit quota, and a fallback that accepts both with an admin default users may override.

The extension-authorization skill is a hard prerequisite for every variant, since X requires a signed-in, non-anonymous caller for each meaningful endpoint and the admin/fallback Client ID setters are gated on the #admin role; it supplies the Internet Identity login flow and the backend caller/role infrastructure. Configuration must pin Config is_replicated = ?false, x-client must be at least version 0.2.3 (added via mops add [email protected]), and the requested OAuth scopes cover both authorise-time consent and posting. Token values must never be returned by a getter or written to logs.