Integrate Matrix SDK with Makepad Apps

Robius Matrix SDK Integration is a skill with best practices for integrating external APIs with Makepad applications, based on two codebases: Robrix, for Matrix SDK integration (sliding sync, timeline subscriptions, real-time updates), and Moly, for OpenAI and LLM API integration (SSE streaming, MCP protocol, multi-provider support). Its description marks it as critical for Matrix SDK work with Makepad and lists trigger words such as matrix-sdk, sliding sync, MatrixRequest, timeline, matrix client and robrix.

Robrix uses the matrix-sdk and matrix-sdk-ui crates to connect to Matrix homeservers. The skill lists four architectural decisions: native sliding sync for efficient room list updates, a separate Tokio runtime for Matrix operations while Makepad handles the UI, a request and response pattern where the UI sends requests and receives actions and updates back, and a dedicated timeline subscriber task per room in the background.

The centerpiece is the MatrixRequest pattern. A Rust enum defines every async request the Matrix worker task accepts: login and logout, timeline operations (paginate, send, edit and redact messages), room operations (join, leave, get members), user operations (get profile, ignore user), media fetching for avatars and media, typing notices and read receipts, reactions, and subscriptions to typing notices and pinned events. The UI submits requests from its thread to the async runtime through a global sender:

static REQUEST_SENDER: Mutex<Option<UnboundedSender<MatrixRequest>>> = Mutex::new(None);

A worker task loops over incoming requests and handles each one, spawning a dedicated task per operation so the receiver loop never blocks.

Use it when integrating the Matrix SDK with Makepad, building a Matrix client with Makepad, implementing Matrix features such as rooms, timelines and messages, or handling Matrix SDK async operations in the UI.

It is specific to the Makepad and Matrix combination and to the patterns used in Robrix and Moly. Its limitations say to use it only when the task clearly matches its scope, not to treat output as a substitute for environment-specific validation, testing or expert review, and to ask for clarification if inputs or success criteria are missing.

The input is your Makepad application and the Matrix feature you want to add. The output is the structure to follow: the request enum, the submit function, the worker task, timeline updates, room list updates and client building.

Timeline updates flow through a TimelineUpdate enum sent per room, with a subscriber task that is cleaned up when a room's details are dropped, and the UI handles updates in a RoomScreen widget. Room list updates use a RoomsListUpdate enum and a lock-free SegQueue of pending updates with an enqueue function. The skill also shows a client build pattern.

Seven best practices are listed:

• Always spawn tasks so the worker receiver loop is never blocked.
• Use crossbeam channels for per-room updates, which is more efficient than a global queue.
• Always call SignalToUI::set_ui_signal() after enqueueing any update.
• Handle rooms that are not ready by skipping requests for rooms not yet in ALL_JOINED_ROOMS.
• Abort background tasks on drop when rooms are closed.
• Use Cx::post_action for results, which are handled in App::handle_actions.
• Use SegQueue for high-frequency updates, since it is lock-free.

The skill builds on Makepad, the matrix-sdk and matrix-sdk-ui crates, Tokio and crossbeam channels. Reference files are references/matrix-client.md for client setup and login patterns, references/timeline-handling.md for timeline subscription patterns and references/moly-api-integration.md for Moly API integration patterns.

It is for Rust developers building Matrix chat clients or other API-driven apps on Makepad who want a proven structure for keeping async network work off the UI thread.