xmtp_configuration/common/
mls.rs

1//! Common configuration values between dev & prod
2use crate::ns::{NS_IN_30_DAYS, NS_IN_SEC};
3
4/// Duration to wait before restarting workers in case of an error.
5pub const WORKER_RESTART_DELAY: std::time::Duration = std::time::Duration::from_secs(1);
6
7pub const WELCOME_HPKE_LABEL: &str = "MLS_WELCOME";
8
9pub const MAX_GROUP_SYNC_RETRIES: usize = 3;
10
11pub const MAX_INTENT_PUBLISH_ATTEMPTS: usize = 3;
12
13pub const GROUP_KEY_ROTATION_INTERVAL_NS: i64 = NS_IN_30_DAYS;
14
15pub const KEY_PACKAGE_QUEUE_INTERVAL_NS: i64 = 5 * NS_IN_SEC; // 5 secs
16
17/// Interval in NS used to compute `next_key_package_rotation_ns`.
18/// This defines how often a new KeyPackage should be *rotated*,
19/// but does *not* determine the actual KeyPackage expiration.
20pub const KEY_PACKAGE_ROTATION_INTERVAL_NS: i64 = NS_IN_30_DAYS; // 30 days
21
22pub const SEND_MESSAGE_UPDATE_INSTALLATIONS_INTERVAL_NS: i64 = 5 * NS_IN_SEC;
23
24pub const MAX_GROUP_SIZE: usize = 250;
25
26pub const MAX_INSTALLATIONS_PER_INBOX: usize = 10;
27
28/// Most actions one identity update may carry. Validators reject a larger
29/// update when they decode it, before they verify any of its signatures, and
30/// clients refuse to build one. It is also the most installations a client
31/// accepts as a deployment's installation ceiling, so one update can revoke
32/// every installation that ceiling allows.
33pub const MAX_IDENTITY_UPDATE_ACTIONS: usize = 100;
34
35pub const MAX_PAST_EPOCHS: usize = 3;
36
37/// Largest gap from a sender's ratchet head accepted in the current epoch.
38/// OpenMLS persists this configuration per group; changing it needs a migration.
39pub const SENDER_RATCHET_MAX_FORWARD_DISTANCE: u32 = 1_000;
40
41/// Number of earlier sender generations retained for out-of-order messages.
42pub const SENDER_RATCHET_OUT_OF_ORDER_TOLERANCE: u32 = 5;
43
44/// Healthy primary-read time allowed for an absent pinned identity update.
45/// This exceeds the backend's default statement timeout.
46pub const IDENTITY_REFERENCE_WAIT: std::time::Duration = std::time::Duration::from_secs(30);
47
48/// First interval between primary reads for absent identity updates. Each
49/// later interval doubles up to `IDENTITY_REFERENCE_MAX_RETRY_INTERVAL`.
50pub const IDENTITY_REFERENCE_RETRY_INTERVAL: std::time::Duration =
51    std::time::Duration::from_millis(250);
52
53/// Longest interval between primary reads for absent identity updates.
54pub const IDENTITY_REFERENCE_MAX_RETRY_INTERVAL: std::time::Duration =
55    std::time::Duration::from_secs(2);
56
57/// Maximum concurrent identity proof requests in one resolver batch, and the
58/// most association states one batch read derives at once.
59pub const IDENTITY_DEPENDENCY_CONCURRENCY: usize = 8;
60
61pub const CREATE_PQ_KEY_PACKAGE_EXTENSION: bool = true;
62
63// If a metadata field name starts with this character,
64// and it does not have a policy set, it is a super admin only field
65pub const SUPER_ADMIN_METADATA_PREFIX: &str = "_";
66pub const HMAC_SALT: &[u8] = b"libXMTP HKDF salt!";
67
68pub const ENABLE_COMMIT_LOG: bool = true;
69pub const MIN_RECOVERY_REQUEST_VERSION: &str = "1.6.0";
70
71/// The protocol floor written when a group or DM is created.
72///
73/// Its runtime effect is nil by construction: this floor must be at or below
74/// `CARGO_PKG_VERSION`. The version gate becomes load-bearing when a later
75/// floor is raised above a shipped client version. Keep the gate wired so
76/// those clients pause and resume after an upgrade.
77///
78/// Follow the floor-bump convention in the component registry when changing
79/// the wire format. Raise this constant with the workspace version.
80pub const PROPOSALS_MIN_PROTOCOL_VERSION: &str = "1.12.0-dev.1";
81
82/// First version whose receivers accept an inbox adding back its own leafless
83/// installation. Senders retry only in groups whose floor is at least this.
84pub const INSTALLATION_RETRY_MIN_PROTOCOL_VERSION: &str = "1.12.0-dev.1";
85
86// Welcome pointers are mostly the hpke public key and less than 100 bytes for the welcome pointer
87// so as long as we have 2 installations that need a single welcome it will result in less data being
88// ingested by the nodes and stored. There is a slight penalty for egress data, but the amount needed
89// to be stored can be 100x less than using regular welcome messages.
90pub const INSTALLATION_THRESHOLD_FOR_WELCOME_POINTER_SENDING: usize = 2;
91
92/// Length of a welcome pointer's ChaCha20-Poly1305 pointee key.
93pub const WELCOME_POINTEE_KEY_BYTES: usize = 32;
94
95/// Length of each of a welcome pointer's two ChaCha20-Poly1305 nonces.
96pub const WELCOME_POINTEE_NONCE_BYTES: usize = 12;
97
98/// Length of a key package's Curve25519 Welcome wrapper key.
99pub const WELCOME_WRAPPER_CURVE25519_KEY_BYTES: usize = 32;
100
101/// Length of a key package's X-Wing (ML-KEM-768 draft 6) Welcome wrapper key.
102pub const WELCOME_WRAPPER_XWING_KEY_BYTES: usize = 1216;
103
104/// the base backoff time that is multiplied by 3
105pub const SYNC_BACKOFF_WAIT_MS: u16 = 50;
106/// the total wait for all attempts
107pub const SYNC_BACKOFF_TOTAL_WAIT_MAX_SECS: u16 = 10;
108/// jitter time between attempts in ms
109pub const SYNC_JITTER_MS: u16 = 25;
110
111/// How long after the backend's timestamp on a Welcome the client keeps it
112/// waiting for a welcome pointee or for its group's message topic to reach the
113/// join anchor.
114pub const WELCOME_RETENTION_NS: i64 = 3 * crate::ns::NS_IN_DAY;
xmtp_configuration/common/mls.rs

xmtp_configuration/common/
mls.rs
