Project Robius Roadmap for 2025
- More Rust abstractions for platform features
- Better, more automated build tooling
- Effortless integration with other UI toolkits
- Organizing more conferences & meet-ups
Robrix Roadmap for 2025 and beyond
Acknowledgments

Our Roadmaps for Project Robius & Robrix in 2025

A look ahead at our future vision, challenges, and goals for Project Robius and Robrix.

Author: Kevin Boos. Last updated January 16th, 2024. Discuss this on Reddit.

‼️ This is a continuation of our previous post.

We've just completed the first full year of work on Project Robius: an open-source decentralized endeavor to enable developers to write immersive, fully-featured apps in pure 🦀 Rust 🦀 that work seamlessly across all major platforms.

In this companion post, we'll take a look at our roadmap for 2025 and beyond, both for Project Robius as a whole and for the Robrix app specifically.

Project Robius Roadmap for 2025

Project Robius in 2025 aims to continue the work we've begun in 2024 to improve the overall app dev experience in Rust.

More Rust abstractions for platform features

As a technical organization, our primary ongoing focus will be to keep creating and publishing as many high-quality platform feature abstraction crates as possible. Now that we have a foundation established with several existing crates, we anticipate being able to make faster progress, especially with the expected addition of more contributors. Our targeted platform features include (in rough priority order):

Better, more automated build tooling

Another topic dear to our hearts is build tooling. We aim to improve the state of build tools such that the app developer themself can be relieved from the burden of managing and figuring out platform-specific details, such as which permissions/entitlements their app requires to build and run properly on mobile platforms. Ideally, we'd like to be able to auto-generate a fully-formed Android XML manifest or Apple Info.plist file with all of the necessary permissions that an app requires, without requiring the app dev to possess expert knowledge about the requirements of their app's dependencies and transitive dependencies.

One such idea for realizing this is to make each robius-* platform feature abstraction crate automatically emit its required permissions during the build process. Exactly how to export and encode this information is still up in the air, but we have discussed leveraging a linker-based approach similar to what Dioxus's manganis project does to encode resource/asset paths into special linker sections. This would allow a top-level tool to run after the cargo build process, and inspect the binary's special linker sections in order to automatically generate a full permissions/entitlements file for the given target platform. We envision that this could also be used for other arbitrary UI toolkits, not just Makepad, as well as emitted by other platform abstraction crates outside of the robius-* organization.

Effortless integration with other UI toolkits

In addition, we wish to explore deeper integration and first-class compatibility (and testing pipelines) with other Rust UI toolkits, e.g., Dioxus, eGUI, and more. Our first year of development has been centered on Makepad, in the sense that we've built two full-size Makepad apps, contributed significantly to Makepad itself, and have focused on test-driving our crates using Makepad apps (see robius-demo-simple). Thus, using Robius components in a Makepad app is quite easy for the app developer. All they need to do is add a dependency on a special "marker" crate that auto-configures all robius-* crates to work with Makepad, as shown below in Robrix's Cargo.toml:

[dependencies]
makepad-widgets = { git = "https://github.com/makepad/makepad", branch = "rik" }
robius-open = "0.1.2"
robius-directories = "5.0.1"
robius-location = { git = "https://github.com/project-robius/robius-location" }

## Including this crate automatically configures all `robius-*` crates to work with Makepad.
robius-use-makepad = "0.1.1"

Now that we have successfully realized several platform feature abstraction crates, we would like to ensure that these can be easily utilized by apps built in other UI toolkits. For example, one specific secondary goal for this year is to explore how robius-* crates could comprise Dioxus's dioxus-std library and fill in the gaps in their mobile platform support.

Another related goal is to design a UI-focused concurrency management library with an interface that helps app devs easily write high-performance apps that never block or bog down the main UI thread with long-running operations. We envision easy interfaces to offload code to background threads or async tasks, as well as for exchanging data between these background contexts and the performance-sensitive the UI main thread. The inability to easily invoke async functions from the UI main thread (without causing performance hiccups) is a long-running frustration we have had when developing Robrix, as many SDKs are written with a hard dependency on an async executor, typically tokio. This serves as strong motivation to ameliorate the overly-complex code patterns shown in the diagram below, in which Robrix's structure of multiple execution contexts with myriad distinct communication mechanisms between them must be manually managed.

Diagram of how Robrix must manually manage mixed concurrency contexts

To understand this concurrency challenge in more detail, watch this presentation on Robrix (starting from 23:10) or check out slides 26-33 here.

A key component of this library is an abstract compile-time token that statically ensures whether code is executing within the context of the main UI thread context. Such a type must be both non-Send and non-Sync, and only possible to construct on the main UI thread. This token is necessary because most platforms require many of their platform-provided APIs to be invoked on the main thread, and it's significantly better to check this at compile time than via a runtime assertion. We have realized this for Makepad via a mutable reference to the context type &mut Cx, which is created only on the main UI thread and then passed as a mutable reference to all of the event handlers and draw routines.

Here's a simplified example of how we leverage this technique in Robrix to implement an efficient cache for user profile information, while avoiding the need to acquire any locks on the main UI thread.

/// Returns the cached user profile for the given user ID ...
///
/// This function requires passing in a reference to `Cx`,
/// which isn't used, but acts as a guarantee that this function
/// must only be called by the main UI thread.
pub fn get_user_profile(
    _cx: &mut Cx,
    user_id: OwnedUserId,
    fetch_if_missing: bool,
) -> Option<UserProfile> {
    // access the TLS cache, defined below.
    ...
}

thread_local! {
    static USER_PROFILE_CACHE: RefCell<BTreeMap<OwnedUserId, UserProfileCacheEntry>> = const { ... };
}

Robrix also uses this to statically ensure that a location initialization function can only be invoked from the main UI thread:

/// Starts listening for location requests and updates to the latest device location.
/// ...
pub fn init_location_subscriber(_cx: &mut Cx) -> Result<(), robius_location::Error> {
    ...
}

With a proper UI-agnostic abstraction for a statically-known thread context marker, we can do this not just in the Makepad app logic, but also within the robius-* platform feature crates themselves. Finally, while this sort of concurrency library and thread context abstractions are highly desirable, it's also admittedly a longer-term goal that merits major effort beyond just 2025.

Organizing more conferences & meet-ups

On the organizational side, we intend to sponsor two more conferences for open-source Rust development and host informal Rust app dev unconferences co-located with those conferences. These will be scheduled similarly to the ones we hosted in 2024: the first will be RustWeek 2025 (formerly "RustNL") in the Netherlands in May, and the second will be GOSIM China in autumn 2025. With these (un)conferences, we aim to bring community members together again to collaborate, share ideas, and to further advance the state-of-the-art for App Dev and UI in Rust.

Robrix Roadmap for 2025 and beyond

As discussed in our previous post, Robrix is an up-and-coming Matrix chat client for power users, and serves as a "flagship" Robius app to drive the development priorities of various Robius components.

While Robrix iisoff to a strong start, we still have a long way to go, and we have a lot more cool features in mind beyond just Matrix chat support. We have planned several high-level phases of Robrix development over the next 18-24 months:

  1. [Q1 2025]  Release an alpha version of Robrix with most fundamental Matrix features available.
    • Realize sufficient functionality to be usable as a daily driver, but not yet to be a complete replacement for existing clients.
    • This is nearly complete! See Milestone 1 on our GitHub page.
  2. [Summer 2025]  Publish Robrix v1.0 with full Matrix functionality, for "power" users.
    • Offer a responsive UI design with a dockable, multi-tab view of many rooms side-by-side, which also adapts to varying screen sizes (mobile, desktop, etc).
    • Achieve feature parity with existing major clients, including administrative features like a full settings pane, session management, room creation/admin, message search, threads, spaces, etc.
      • See Milestone 2 on our GitHub page for more details.
      • Generally, these features are not drivers of Robius development, as they don't require complex platform features, so they were of a lower priority initially.
    • Distribute Robrix app bundles to platform app stores and package managers.
  3. [Q3 2025]  Integrate local LLM runtimes (like Moly) for powerful, advanced convenience features.
    • LLMs or AI agents can summarize conversations, analyze important topics, and extract key action items from "what you missed" after a holiday. Here's a UI prototype:
      A prototype UI design for AI LLMs alongside Matrix rooms in Robrix
    • AI chatbots can assist newcomers in large open-source projects by auto-answering FAQs, either privately or publicly to allow for additional interaction from real expert users.
    • Key point: fully-local LLM runtimes cannot jeopardize end-to-end encrypted (E2EE) rooms or user data sovereignty, so you can utilize LLMs with confidence that your privacy is being honored.
  4. [Late 2025]  Go beyond Matrix: Robrix as a central "hub" for federated & open-source services
    • Collect multiple services into a unified app view, including ActivityPub-based microblogs (e.g., Mastodon), views of source code and related issues/pull requests, discussion forums (e.g., Lemmy), and more.
      • The exact set of supported services are TBD.
    • The availability of many services in a single app context can enable unique combo features, such as a combined activity feed of notifications + news from various sources, or easy one-click broadcasting of project updates to multiple communities across different services.
  5. [Long-term]  Explore how to use decentralized identity providers like OpenWallet to login to Robrix-supported services.

While many of these are larger endeavors, we anticipate being able to complete at least milestones 1, 2, and 3 by the end of this coming year.

Acknowledgments

I'd like to thank the following key people who have been instrumental to the success of Project Robius over the past year, and who will undoubtedly help it flourish in 2025.

By: Kevin Boos


https://x.com/project_robius
https://mastodon.social/@kevinaboos
https://github.com/kevinaboos

Published: 2025-01-09