- Home
- Skills
- Zhanghandong
- Makepad Skills
- Robius Matrix Integration
robius-matrix-integration_skill
- Shell
715
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill zhanghandong/makepad-skills --skill robius-matrix-integration- SKILL.md13.7 KB
Overview
This skill provides a practical pattern for integrating the Matrix SDK into Makepad apps using Robrix and Moly-inspired approaches. It focuses on non-blocking async architecture: sliding sync for room lists, per-room timeline subscribers, and a request/response worker pattern that keeps UI and networking separate. The goal is reliable real-time room/timeline handling, media fetches, pagination, and UI notifications for Makepad-based clients.
How this skill works
The UI thread submits MatrixRequest enum variants into a single async worker via an unbounded sender. The worker task matches requests and spawns dedicated Tokio tasks for long-running operations (pagination, joins, media fetch). Per-room state stores a timeline and a crossbeam channel sender; timeline.subscribe streams diffs which are converted into TimelineUpdate messages sent to the UI. A SegQueue holds high-frequency room list updates and SignalToUI::set_ui_signal() notifies the UI to drain pending updates.
When to use it
- Building a Matrix client UI in Makepad that must stay responsive while performing async Matrix operations
- Implementing sliding sync and efficient room list updates for large accounts
- Managing per-room timeline subscriptions and real-time message flows
- Handling media downloads, avatars, typing/read indicators, reactions, and pagination without blocking the main loop
- Coordinating results from async workers back into the app action loop
Best practices
- Never block the central request receiver—spawn a new task for each long operation
- Use crossbeam channels per room for timeline updates to avoid global contention
- Always call SignalToUI::set_ui_signal() after enqueueing updates so the UI can poll safely
- Skip or defer requests for rooms not yet present in the joined-rooms map
- Abort and clean up background tasks when room state is dropped to avoid leaks
- Use a lock-free queue (SegQueue) for very high-frequency room-list updates
Example use cases
- Paginating a room timeline: submit PaginateRoomTimeline and spawn a task that sends PaginationRunning / PaginationIdle updates
- Joining a room: submit JoinRoom, let the worker spawn a task to join, then post a JoinRoomResultAction back to the UI
- Real-time timeline: spawn_timeline_subscriber subscribes to timeline.stream and emits NewItems and diffs to the view
- Media fetch: request FetchMedia with a callback and update per-message timeline entry on completion
- Unread counts and room list changes: enqueue RoomsListUpdate entries and signal UI to process them
FAQ
Spawn each long-running operation from the worker loop so the receiver remains free; send progress via TimelineUpdate messages and call SignalToUI::set_ui_signal() to wake the UI.
Why use per-room crossbeam channels instead of a single global queue?
Per-room channels reduce contention, simplify backpressure, and make it easy to target updates to the correct room view without filtering a global stream.