Skip to main content

ruma/
lib.rs

1#![doc(html_favicon_url = "https://ruma.dev/favicon.ico")]
2#![doc(html_logo_url = "https://ruma.dev/images/logo.png")]
3//! Types and traits for working with the [Matrix](https://matrix.org) protocol.
4//!
5//! # Getting started
6//!
7//! If you want to build a Matrix client or bot, have a look at [matrix-rust-sdk](https://github.com/matrix-org/matrix-rust-sdk#readme).
8//! It builds on Ruma and includes handling of state storage, end-to-end encryption and many other
9//! useful things.
10//!
11//! For homeservers, bridges and harder-to-categorize software that works with Matrix, you're at the
12//! right place. To get started, add `ruma` to your dependencies:
13//!
14//! ```toml
15//! # crates.io release
16//! ruma = { version = "0.17.0", features = ["..."] }
17//! # git dependency
18//! ruma = { git = "https://github.com/ruma/ruma", branch = "main", features = ["..."] }
19//! ```
20//!
21//! You can find a low level Matrix client in the [ruma-client repository](https://github.com/ruma/ruma-client).
22//!
23//! You can also find a small number of examples in our dedicated [ruma-examples repository](https://github.com/ruma/ruma-examples).
24//!
25//! # Status
26//!
27//! Ruma supports all events and REST endpoints of Matrix 1.17.
28//!
29//! Only room versions enforcing canonical JSON (introduced with room version 6) are supported. Room
30//! versions 1 through 5 are supported on a best effort basis, but a missing feature or an
31//! incompatibility with a homeserver implementation are not considered bugs. Clients should be able
32//! to work with those room versions, granted parts of the room might break in some unconventional
33//! cases, but homeservers based on Ruma **should not** advertise support for them.
34//!
35//! # Features
36//!
37//! This crate re-exports things from all of the other ruma crates so you don't have to manually
38//! keep all the versions in sync.
39//!
40//! Which crates are re-exported can be configured through cargo features.
41//!
42//! > ⚠ Some details might be missing because rustdoc has trouble with re-exports so you may need
43//! > to refer to other crates' documentations.
44//!
45//! > 🛈 For internal consistency, Ruma uses American spelling for variable names. Names may differ
46//! > in the serialized representation, as the Matrix specification has a mix of British and
47//! > American English.
48//!
49//! ## API features
50//!
51//! Depending on which parts of Matrix are relevant to you, activate the following features:
52//!
53//! * `appservice-api` -- Application Service API.
54//! * `client-api` -- Client-Server API.
55//! * `federation-api` -- Server-Server (Federation) API.
56//! * `identity-service-api` -- Identity Service API.
57//! * `push-gateway-api` -- Push Gateway API.
58//!
59//! These features have `client`- and `server`-optimized variants that are enabled respectively
60//! with the `-c` and `-s` suffixes. For example:
61//!   * `client-api-c` -- The Client-Server API optimized for the client side.
62//!   * `client-api-s` -- The Client-Server API optimized for the server side.
63//!
64//! ## Compatibility features
65//!
66//! By default, the ruma crates are only able to handle strictly spec-compliant data and behaviour.
67//! However, due to the fact that Matrix is federated, that it is used by various implementations
68//! that might have different bugs, and that much of its data is immutable, they need to be able to
69//! interoperate with data that might differ slightly from the specification.
70//!
71//! This is the role of the `compat-*` cargo features. They allow the crates be more tolerant of
72//! external data and incoming requests for known and reasonable deviations from the spec, usually
73//! for historical reasons. They however do not permit the ruma crates to generate data that is not
74//! spec-compliant.
75//!
76//! Each cargo feature is documented briefly in the cargo manifest of the crate, and more thoroughly
77//! where the feature applies.
78//!
79//! ## Convenience features
80//!
81//! These features are only useful if you want to use a method that requires it:
82//!
83//! * `rand` -- Generate random identifiers.
84//! * `markdown` -- Parse markdown to construct messages.
85//! * `html` -- Parse HTML to sanitize it or navigate its tree.
86//!   * `html-matrix` -- Enables the `matrix` feature of `ruma-html` to parse HTML elements data to
87//!     typed data as suggested by the Matrix Specification.
88//!
89//! ## Unstable features
90//!
91//! By using these features, you opt out of all semver guarantees Ruma otherwise provides:
92//!
93//! * `unstable-mscXXXX`, where `XXXX` is the MSC number -- Upcoming Matrix features that may be
94//!   subject to change or removal.
95//! * `unstable-uniffi` -- Enables UniFFI bindings by adding conditional `uniffi` derives to _some_
96//!   types. This feature is currently a work in progress and, thus, unstable.
97//!
98//! ## Common features
99//!
100//! These submodules are usually activated by the API features when needed:
101//!
102//! * `api`
103//! * `events`
104//! * `signatures`
105//!
106//! # Compile-time `cfg` settings
107//!
108//! These settings are accepted at compile time to configure the generated code. They can be set
109//! using the `RUSTFLAGS` environment variable like this:
110//!
111//! ```shell
112//! RUSTFLAGS="--cfg {key}=\"{value}\""
113//! ```
114//!
115//! or in `.cargo/config.toml`:
116//!
117//! ```toml
118//! # General setting for all targets, overridden by per-target `rustflags` setting if set.
119//! [build]
120//! rustflags = ["--cfg", "{key}=\"{value}\""]
121//!
122//! # Per-target setting.
123//! [target.<triple/cfg>]
124//! rustflags = ["--cfg", "{key}=\"{value}\""]
125//! ```
126//!
127//! They can also be configured using an environment variable at compile time, which has the benefit
128//! of not requiring to re-compile the whole dependency chain when their value is changed, like
129//! this:
130//!
131//! ```shell
132//! {UPPERCASE_KEY}="{value}"
133//! ```
134//!
135//! * `ruma_identifiers_storage` -- Choose the inner representation of the identifier types
136//!   generated with the `ruma_id` attribute macro. If the setting is not set or has an unknown
137//!   value, the owned identifiers use a `Box<str>` internally. The following values are also
138//!   supported:
139//!
140//!   * `Arc` -- Use an `Arc<str>`.
141//!
142//!   This setting can also be configured by setting the `RUMA_IDENTIFIERS_STORAGE` environment
143//!   variable.
144//! * `ruma_unstable_exhaustive_types` -- Most types in Ruma are marked as non-exhaustive to avoid
145//!   breaking changes when new fields are added in the specification. This setting compiles all
146//!   types as exhaustive. By enabling this feature you opt out of all semver guarantees Ruma
147//!   otherwise provides. This can also be configured by setting the
148//!   `RUMA_UNSTABLE_EXHAUSTIVE_TYPES` environment variable.
149
150#![warn(missing_docs)]
151#![cfg_attr(docsrs, feature(doc_cfg))]
152
153#[cfg(feature = "events")]
154#[doc(inline)]
155pub use ruma_events as events;
156#[cfg(feature = "html")]
157#[doc(inline)]
158pub use ruma_html as html;
159#[cfg(feature = "signatures")]
160#[doc(inline)]
161pub use ruma_signatures as signatures;
162#[cfg(feature = "state-res")]
163#[doc(inline)]
164pub use ruma_state_res as state_res;
165
166/// (De)serializable types for various [Matrix APIs][apis] requests and responses and abstractions
167/// for them.
168///
169/// [apis]: https://spec.matrix.org/v1.18/#matrix-apis
170#[cfg(feature = "api")]
171pub mod api {
172    #[cfg(any(feature = "appservice-api-c", feature = "appservice-api-s"))]
173    #[doc(inline)]
174    pub use ruma_appservice_api as appservice;
175    #[cfg(any(feature = "client-api-c", feature = "client-api-s"))]
176    #[doc(inline)]
177    pub use ruma_client_api as client;
178    // The metadata macro is `#[doc(hidden)]` by default to only show it in the `api` module
179    // instead of at the root of `ruma_common`, so we need to explicitly inline it where we
180    // want it.
181    #[doc(inline)]
182    pub use ruma_common::api::metadata;
183    pub use ruma_common::api::*;
184    #[cfg(any(feature = "federation-api-c", feature = "federation-api-s"))]
185    #[doc(inline)]
186    pub use ruma_federation_api as federation;
187    #[cfg(any(feature = "identity-service-api-c", feature = "identity-service-api-s"))]
188    #[doc(inline)]
189    pub use ruma_identity_service_api as identity_service;
190    #[cfg(any(feature = "push-gateway-api-c", feature = "push-gateway-api-s"))]
191    #[doc(inline)]
192    pub use ruma_push_gateway_api as push_gateway;
193}
194
195/// Canonical JSON types and related functions.
196pub mod canonical_json {
197    // The assert_to_canonical_json_eq macro is `#[doc(hidden)]` by default to only show it in the
198    // `canonical_json` module instead of at the root of `ruma_common`, so we need to explicitly
199    // inline it where we want it.
200    #[doc(inline)]
201    pub use ruma_common::canonical_json::assert_to_canonical_json_eq;
202    pub use ruma_common::canonical_json::*;
203}
204
205#[doc(no_inline)]
206pub use assign::assign;
207#[doc(no_inline)]
208pub use js_int::{Int, UInt, int, uint};
209#[doc(no_inline)]
210pub use js_option::JsOption;
211#[cfg(all(feature = "events", feature = "unstable-msc4334"))]
212#[doc(no_inline)]
213pub use language_tags::LanguageTag;
214pub use ruma_common::{CanonicalJsonError, CanonicalJsonObject, CanonicalJsonValue, *};
215pub use web_time as time;