Continuwuity
A community-driven Matrix homeserver in Rust
Why does this exist?
The original conduwuit project has been archived and is no longer maintained. Rather than letting this Rust-based Matrix homeserver disappear, a group of community contributors have forked the project to continue its development, fix outstanding issues, and add new features.
We aim to provide a stable, well-maintained alternative for current conduwuit users and welcome newcomers seeking a lightweight, efficient Matrix homeserver.
Who are we?
We are a group of Matrix enthusiasts, developers and system administrators who have used conduwuit and believe in its potential. Our team includes both previous contributors to the original project and new developers who want to help maintain and improve this important piece of Matrix infrastructure.
We operate as an open community project, welcoming contributions from anyone interested in improving continuwuity.
What is Matrix?
Matrix is an open, federated, and extensible network for decentralized communication. Users from any Matrix homeserver can chat with users from all other homeservers over federation. Matrix is designed to be extensible and built on top of. You can even use bridges such as Matrix Appservices to communicate with users outside of Matrix, like a community on Discord.
What are the project's goals?
Continuwuity aims to:
- Maintain a stable, reliable Matrix homeserver implementation in Rust
- Improve compatibility and specification compliance with the Matrix protocol
- Fix bugs and performance issues from the original conduwuit
- Add missing features needed by homeserver administrators
- Provide comprehensive documentation and easy deployment options
- Create a sustainable development model for long-term maintenance
- Keep a lightweight, efficient codebase that can run on modest hardware
Can I try it out?
Check out the documentation for installation instructions.
There are currently no open registration Continuwuity instances available.
What are we working on?
We're working our way through all of the issues in the Forgejo project.
- Packaging & availability in more places
- Appservices bugs & features
- Improving compatibility and spec compliance
- Automated testing
- Admin API
- Policy-list controlled moderation
Can I migrate my data from x?
- Conduwuit: Yes
- Conduit: No, database is now incompatible
- Grapevine: No, database is now incompatible
- Dendrite: No
- Synapse: No
We haven't written up a guide on migrating from incompatible homeservers yet. Reach out to us if you need to do this!
How can I deploy my own?
If you want to connect an appservice to Continuwuity, take a look at the appservices documentation.
How can I contribute?
See the contributor's guide
Contact
Join our Matrix room and space to chat with us about the project!
Configuration
This chapter describes various ways to configure Continuwuity.
Basics
Continuwuity uses a config file for the majority of the settings, but also supports setting individual config options via commandline.
Please refer to the example config file for all of those settings.
The config file to use can be specified on the commandline when running
Continuwuity by specifying the -c
, --config
flag. Alternatively, you can use
the environment variable CONDUWUIT_CONFIG
to specify the config file to used.
Conduit's environment variables are supported for backwards compatibility.
Option commandline flag
Continuwuity supports setting individual config options in TOML format from the
-O
/ --option
flag. For example, you can set your server name via -O server_name=\"example.com\"
.
Note that the config is parsed as TOML, and shells like bash will remove quotes. So unfortunately it is required to escape quotes if the config option takes a string. This does not apply to options that take booleans or numbers:
--option allow_registration=true
works ✅-O max_request_size=99999999
works ✅-O server_name=example.com
does not work ❌--option log=\"debug\"
works ✅--option server_name='"example.com'"
works ✅
Execute commandline flag
Continuwuity supports running admin commands on startup using the commandline
argument --execute
. The most notable use for this is to create an admin user
on first startup.
The syntax of this is a standard admin command without the prefix such as
./conduwuit --execute "users create_user june"
An example output of a success is:
INFO conduwuit_service::admin::startup: Startup command #0 completed:
Created user with user_id: @june:girlboss.ceo and password: `<redacted>`
This commandline argument can be paired with the --option
flag.
Environment variables
All of the settings that are found in the config file can be specified by using
environment variables. The environment variable names should be all caps and
prefixed with CONDUWUIT_
.
For example, if the setting you are changing is max_request_size
, then the
environment variable to set is CONDUWUIT_MAX_REQUEST_SIZE
.
To modify config options not in the [global]
context such as
[global.well_known]
, use the __
suffix split: CONDUWUIT_WELL_KNOWN__SERVER
Conduit's environment variables are supported for backwards compatibility (e.g.
CONDUIT_SERVER_NAME
).
Example configuration
Example configuration
### continuwuity Configuration
###
### THIS FILE IS GENERATED. CHANGES/CONTRIBUTIONS IN THE REPO WILL BE
### OVERWRITTEN!
###
### You should rename this file before configuring your server. Changes to
### documentation and defaults can be contributed in source code at
### src/core/config/mod.rs. This file is generated when building.
###
### Any values pre-populated are the default values for said config option.
###
### At the minimum, you MUST edit all the config options to your environment
### that say "YOU NEED TO EDIT THIS".
###
### For more information, see:
### https://continuwuity.org/configuration.html
[global]
# The server_name is the pretty name of this server. It is used as a
# suffix for user and room IDs/aliases.
#
# See the docs for reverse proxying and delegation:
# https://continuwuity.org/deploying/generic.html#setting-up-the-reverse-proxy
#
# Also see the `[global.well_known]` config section at the very bottom.
#
# Examples of delegation:
# - https://puppygock.gay/.well-known/matrix/server
# - https://puppygock.gay/.well-known/matrix/client
#
# YOU NEED TO EDIT THIS. THIS CANNOT BE CHANGED AFTER WITHOUT A DATABASE
# WIPE.
#
# example: "continuwuity.org"
#
#server_name =
# The default address (IPv4 or IPv6) continuwuity will listen on.
#
# If you are using Docker or a container NAT networking setup, this must
# be "0.0.0.0".
#
# To listen on multiple addresses, specify a vector e.g. ["127.0.0.1",
# "::1"]
#
#address = ["127.0.0.1", "::1"]
# The port(s) continuwuity will listen on.
#
# For reverse proxying, see:
# https://continuwuity.org/deploying/generic.html#setting-up-the-reverse-proxy
#
# If you are using Docker, don't change this, you'll need to map an
# external port to this.
#
# To listen on multiple ports, specify a vector e.g. [8080, 8448]
#
#port = 8008
# The UNIX socket continuwuity will listen on.
#
# continuwuity cannot listen on both an IP address and a UNIX socket. If
# listening on a UNIX socket, you MUST remove/comment the `address` key.
#
# Remember to make sure that your reverse proxy has access to this socket
# file, either by adding your reverse proxy to the appropriate user group
# or granting world R/W permissions with `unix_socket_perms` (666
# minimum).
#
# example: "/run/continuwuity/continuwuity.sock"
#
#unix_socket_path =
# The default permissions (in octal) to create the UNIX socket with.
#
#unix_socket_perms = 660
# This is the only directory where continuwuity will save its data,
# including media. Note: this was previously "/var/lib/matrix-conduit".
#
# YOU NEED TO EDIT THIS.
#
# example: "/var/lib/continuwuity"
#
#database_path =
# continuwuity supports online database backups using RocksDB's Backup
# engine API. To use this, set a database backup path that continuwuity
# can write to.
#
# For more information, see:
# https://continuwuity.org/maintenance.html#backups
#
# example: "/opt/continuwuity-db-backups"
#
#database_backup_path =
# The amount of online RocksDB database backups to keep/retain, if using
# "database_backup_path", before deleting the oldest one.
#
#database_backups_to_keep = 1
# Text which will be added to the end of the user's displayname upon
# registration with a space before the text. In Conduit, this was the
# lightning bolt emoji.
#
# To disable, set this to "" (an empty string).
#
# The default is the trans pride flag.
#
# example: "🏳️⚧️"
#
#new_user_displayname_suffix = "🏳️⚧️"
# If enabled, continuwuity will send a simple GET request periodically to
# `https://continuwuity.org/.well-known/continuwuity/announcements` for any new
# announcements or major updates. This is not an update check endpoint.
#
#allow_announcements_check = true
# Set this to any float value to multiply continuwuity's in-memory LRU
# caches with such as "auth_chain_cache_capacity".
#
# May be useful if you have significant memory to spare to increase
# performance.
#
# If you have low memory, reducing this may be viable.
#
# By default, the individual caches such as "auth_chain_cache_capacity"
# are scaled by your CPU core count.
#
#cache_capacity_modifier = 1.0
# Set this to any float value in megabytes for continuwuity to tell the
# database engine that this much memory is available for database read
# caches.
#
# May be useful if you have significant memory to spare to increase
# performance.
#
# Similar to the individual LRU caches, this is scaled up with your CPU
# core count.
#
# This defaults to 128.0 + (64.0 * CPU core count).
#
#db_cache_capacity_mb = varies by system
# Set this to any float value in megabytes for continuwuity to tell the
# database engine that this much memory is available for database write
# caches.
#
# May be useful if you have significant memory to spare to increase
# performance.
#
# Similar to the individual LRU caches, this is scaled up with your CPU
# core count.
#
# This defaults to 48.0 + (4.0 * CPU core count).
#
#db_write_buffer_capacity_mb = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#pdu_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#auth_chain_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#shorteventid_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#eventidshort_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#eventid_pdu_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#shortstatekey_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#statekeyshort_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#servernameevent_data_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#stateinfo_cache_capacity = varies by system
# This item is undocumented. Please contribute documentation for it.
#
#roomid_spacehierarchy_cache_capacity = varies by system
# Maximum entries stored in DNS memory-cache. The size of an entry may
# vary so please take care if raising this value excessively. Only
# decrease this when using an external DNS cache. Please note that
# systemd-resolved does *not* count as an external cache, even when
# configured to do so.
#
#dns_cache_entries = 32768
# Minimum time-to-live in seconds for entries in the DNS cache. The
# default may appear high to most administrators; this is by design as the
# majority of NXDOMAINs are correct for a long time (e.g. the server is no
# longer running Matrix). Only decrease this if you are using an external
# DNS cache.
#
#dns_min_ttl = 10800
# Minimum time-to-live in seconds for NXDOMAIN entries in the DNS cache.
# This value is critical for the server to federate efficiently.
# NXDOMAIN's are assumed to not be returning to the federation and
# aggressively cached rather than constantly rechecked.
#
# Defaults to 3 days as these are *very rarely* false negatives.
#
#dns_min_ttl_nxdomain = 259200
# Number of DNS nameserver retries after a timeout or error.
#
#dns_attempts = 10
# The number of seconds to wait for a reply to a DNS query. Please note
# that recursive queries can take up to several seconds for some domains,
# so this value should not be too low, especially on slower hardware or
# resolvers.
#
#dns_timeout = 10
# Fallback to TCP on DNS errors. Set this to false if unsupported by
# nameserver.
#
#dns_tcp_fallback = true
# Enable to query all nameservers until the domain is found. Referred to
# as "trust_negative_responses" in hickory_resolver. This can avoid
# useless DNS queries if the first nameserver responds with NXDOMAIN or
# an empty NOERROR response.
#
#query_all_nameservers = true
# Enable using *only* TCP for querying your specified nameservers instead
# of UDP.
#
# If you are running continuwuity in a container environment, this config
# option may need to be enabled. For more details, see:
# https://continuwuity.org/troubleshooting.html#potential-dns-issues-when-using-docker
#
#query_over_tcp_only = false
# DNS A/AAAA record lookup strategy
#
# Takes a number of one of the following options:
# 1 - Ipv4Only (Only query for A records, no AAAA/IPv6)
#
# 2 - Ipv6Only (Only query for AAAA records, no A/IPv4)
#
# 3 - Ipv4AndIpv6 (Query for A and AAAA records in parallel, uses whatever
# returns a successful response first)
#
# 4 - Ipv6thenIpv4 (Query for AAAA record, if that fails then query the A
# record)
#
# 5 - Ipv4thenIpv6 (Query for A record, if that fails then query the AAAA
# record)
#
# If you don't have IPv6 networking, then for better DNS performance it
# may be suitable to set this to Ipv4Only (1) as you will never ever use
# the AAAA record contents even if the AAAA record is successful instead
# of the A record.
#
#ip_lookup_strategy = 5
# Max request size for file uploads in bytes. Defaults to 20MB.
#
#max_request_size = 20971520
# This item is undocumented. Please contribute documentation for it.
#
#max_fetch_prev_events = 192
# Default/base connection timeout (seconds). This is used only by URL
# previews and update/news endpoint checks.
#
#request_conn_timeout = 10
# Default/base request timeout (seconds). The time waiting to receive more
# data from another server. This is used only by URL previews,
# update/news, and misc endpoint checks.
#
#request_timeout = 35
# Default/base request total timeout (seconds). The time limit for a whole
# request. This is set very high to not cancel healthy requests while
# serving as a backstop. This is used only by URL previews and update/news
# endpoint checks.
#
#request_total_timeout = 320
# Default/base idle connection pool timeout (seconds). This is used only
# by URL previews and update/news endpoint checks.
#
#request_idle_timeout = 5
# Default/base max idle connections per host. This is used only by URL
# previews and update/news endpoint checks. Defaults to 1 as generally the
# same open connection can be re-used.
#
#request_idle_per_host = 1
# Federation well-known resolution connection timeout (seconds).
#
#well_known_conn_timeout = 6
# Federation HTTP well-known resolution request timeout (seconds).
#
#well_known_timeout = 10
# Federation client connection timeout (seconds). You should not set this
# to high values, as dead homeservers can significantly slow down
# federation, specifically key retrieval, which will take roughly the
# amount of time you configure here given that a homeserver doesn't
# respond. This will cause most clients to time out /keys/query, causing
# E2EE and device verification to fail.
#
#federation_conn_timeout = 10
# Federation client request timeout (seconds). You most definitely want
# this to be high to account for extremely large room joins, slow
# homeservers, your own resources etc.
#
#federation_timeout = 300
# Federation client idle connection pool timeout (seconds).
#
#federation_idle_timeout = 25
# Federation client max idle connections per host. Defaults to 1 as
# generally the same open connection can be re-used.
#
#federation_idle_per_host = 1
# Federation sender request timeout (seconds). The time it takes for the
# remote server to process sent transactions can take a while.
#
#sender_timeout = 180
# Federation sender idle connection pool timeout (seconds).
#
#sender_idle_timeout = 180
# Federation sender transaction retry backoff limit (seconds).
#
#sender_retry_backoff_limit = 86400
# Appservice URL request connection timeout. Defaults to 35 seconds as
# generally appservices are hosted within the same network.
#
#appservice_timeout = 35
# Appservice URL idle connection pool timeout (seconds).
#
#appservice_idle_timeout = 300
# Notification gateway pusher idle connection pool timeout.
#
#pusher_idle_timeout = 15
# Maximum time to receive a request from a client (seconds).
#
#client_receive_timeout = 75
# Maximum time to process a request received from a client (seconds).
#
#client_request_timeout = 180
# Maximum time to transmit a response to a client (seconds)
#
#client_response_timeout = 120
# Grace period for clean shutdown of client requests (seconds).
#
#client_shutdown_timeout = 10
# Grace period for clean shutdown of federation requests (seconds).
#
#sender_shutdown_timeout = 5
# Enables registration. If set to false, no users can register on this
# server.
#
# If set to true without a token configured, users can register with no
# form of 2nd-step only if you set the following option to true:
# `yes_i_am_very_very_sure_i_want_an_open_registration_server_prone_to_abuse`
#
# If you would like registration only via token reg, please configure
# `registration_token` or `registration_token_file`.
#
#allow_registration = false
# If registration is enabled, and this setting is true, new users
# registered after the first admin user will be automatically suspended
# and will require an admin to run `!admin users unsuspend <user_id>`.
#
# Suspended users are still able to read messages, make profile updates,
# leave rooms, and deactivate their account, however cannot send messages,
# invites, or create/join or otherwise modify rooms.
# They are effectively read-only.
#
# If you want to use this to screen people who register on your server,
# you should add a room to `auto_join_rooms` that is public, and contains
# information that new users can read (since they won't be able to DM
# anyone, or send a message, and may be confused).
#
#suspend_on_register = false
# Enabling this setting opens registration to anyone without restrictions.
# This makes your server vulnerable to abuse
#
#yes_i_am_very_very_sure_i_want_an_open_registration_server_prone_to_abuse = false
# A static registration token that new users will have to provide when
# creating an account. If unset and `allow_registration` is true,
# you must set
# `yes_i_am_very_very_sure_i_want_an_open_registration_server_prone_to_abuse`
# to true to allow open registration without any conditions.
#
# YOU NEED TO EDIT THIS OR USE registration_token_file.
#
# example: "o&^uCtes4HPf0Vu@F20jQeeWE7"
#
#registration_token =
# Path to a file on the system that gets read for additional registration
# tokens. Multiple tokens can be added if you separate them with
# whitespace
#
# continuwuity must be able to access the file, and it must not be empty
#
# example: "/etc/continuwuity/.reg_token"
#
#registration_token_file =
# The public site key for reCaptcha. If this is provided, reCaptcha
# becomes required during registration. If both captcha *and*
# registration token are enabled, both will be required during
# registration.
#
# IMPORTANT: "Verify the origin of reCAPTCHA solutions" **MUST** BE
# DISABLED IF YOU WANT THE CAPTCHA TO WORK IN 3RD PARTY CLIENTS, OR
# CLIENTS HOSTED ON DOMAINS OTHER THAN YOUR OWN!
#
# Registration must be enabled (`allow_registration` must be true) for
# this to have any effect.
#
#recaptcha_site_key =
# The private site key for reCaptcha.
# If this is omitted, captcha registration will not work,
# even if `recaptcha_site_key` is set.
#
#recaptcha_private_site_key =
# Controls whether encrypted rooms and events are allowed.
#
#allow_encryption = true
# Controls whether federation is allowed or not. It is not recommended to
# disable this after the fact due to potential federation breakage.
#
#allow_federation = true
# Allows federation requests to be made to itself
#
# This isn't intended and is very likely a bug if federation requests are
# being sent to yourself. This currently mainly exists for development
# purposes.
#
#federation_loopback = false
# Always calls /forget on behalf of the user if leaving a room. This is a
# part of MSC4267 "Automatically forgetting rooms on leave"
#
#forget_forced_upon_leave = false
# Set this to true to require authentication on the normally
# unauthenticated profile retrieval endpoints (GET)
# "/_matrix/client/v3/profile/{userId}".
#
# This can prevent profile scraping.
#
#require_auth_for_profile_requests = false
# Set this to true to allow your server's public room directory to be
# federated. Set this to false to protect against /publicRooms spiders,
# but will forbid external users from viewing your server's public room
# directory. If federation is disabled entirely (`allow_federation`), this
# is inherently false.
#
#allow_public_room_directory_over_federation = false
# Set this to true to allow your server's public room directory to be
# queried without client authentication (access token) through the Client
# APIs. Set this to false to protect against /publicRooms spiders.
#
#allow_public_room_directory_without_auth = false
# Allow guests/unauthenticated users to access TURN credentials.
#
# This is the equivalent of Synapse's `turn_allow_guests` config option.
# This allows any unauthenticated user to call the endpoint
# `/_matrix/client/v3/voip/turnServer`.
#
# It is unlikely you need to enable this as all major clients support
# authentication for this endpoint and prevents misuse of your TURN server
# from potential bots.
#
#turn_allow_guests = false
# Set this to true to lock down your server's public room directory and
# only allow admins to publish rooms to the room directory. Unpublishing
# is still allowed by all users with this enabled.
#
#lockdown_public_room_directory = false
# Set this to true to allow federating device display names / allow
# external users to see your device display name. If federation is
# disabled entirely (`allow_federation`), this is inherently false. For
# privacy reasons, this is best left disabled.
#
#allow_device_name_federation = false
# Config option to allow or disallow incoming federation requests that
# obtain the profiles of our local users from
# `/_matrix/federation/v1/query/profile`
#
# Increases privacy of your local user's such as display names, but some
# remote users may get a false "this user does not exist" error when they
# try to invite you to a DM or room. Also can protect against profile
# spiders.
#
# This is inherently false if `allow_federation` is disabled
#
#allow_inbound_profile_lookup_federation_requests = true
# Allow standard users to create rooms. Appservices and admins are always
# allowed to create rooms
#
#allow_room_creation = true
# Set to false to disable users from joining or creating room versions
# that aren't officially supported by continuwuity.
#
# continuwuity officially supports room versions 6 - 11.
#
# continuwuity has slightly experimental (though works fine in practice)
# support for versions 3 - 5.
#
#allow_unstable_room_versions = true
# Default room version continuwuity will create rooms with.
#
# Per spec, room version 11 is the default.
#
#default_room_version = 11
# This item is undocumented. Please contribute documentation for it.
#
#allow_jaeger = false
# This item is undocumented. Please contribute documentation for it.
#
#jaeger_filter = "info"
# If the 'perf_measurements' compile-time feature is enabled, enables
# collecting folded stack trace profile of tracing spans using
# tracing_flame. The resulting profile can be visualized with inferno[1],
# speedscope[2], or a number of other tools.
#
# [1]: https://github.com/jonhoo/inferno
# [2]: www.speedscope.app
#
#tracing_flame = false
# This item is undocumented. Please contribute documentation for it.
#
#tracing_flame_filter = "info"
# This item is undocumented. Please contribute documentation for it.
#
#tracing_flame_output_path = "./tracing.folded"
# Examples:
#
# - No proxy (default):
#
# proxy = "none"
#
# - For global proxy, create the section at the bottom of this file:
#
# [global.proxy]
# global = { url = "socks5h://localhost:9050" }
#
# - To proxy some domains:
#
# [global.proxy]
# [[global.proxy.by_domain]]
# url = "socks5h://localhost:9050"
# include = ["*.onion", "matrix.myspecial.onion"]
# exclude = ["*.myspecial.onion"]
#
# Include vs. Exclude:
#
# - If include is an empty list, it is assumed to be `["*"]`.
#
# - If a domain matches both the exclude and include list, the proxy will
# only be used if it was included because of a more specific rule than
# it was excluded. In the above example, the proxy would be used for
# `ordinary.onion`, `matrix.myspecial.onion`, but not
# `hello.myspecial.onion`.
#
#proxy = "none"
# Servers listed here will be used to gather public keys of other servers
# (notary trusted key servers).
#
# Currently, continuwuity doesn't support inbound batched key requests, so
# this list should only contain other Synapse servers.
#
# example: ["matrix.org", "tchncs.de"]
#
#trusted_servers = ["matrix.org"]
# Whether to query the servers listed in trusted_servers first or query
# the origin server first. For best security, querying the origin server
# first is advised to minimize the exposure to a compromised trusted
# server. For maximum federation/join performance this can be set to true,
# however other options exist to query trusted servers first under
# specific high-load circumstances and should be evaluated before setting
# this to true.
#
#query_trusted_key_servers_first = false
# Whether to query the servers listed in trusted_servers first
# specifically on room joins. This option limits the exposure to a
# compromised trusted server to room joins only. The join operation
# requires gathering keys from many origin servers which can cause
# significant delays. Therefor this defaults to true to mitigate
# unexpected delays out-of-the-box. The security-paranoid or those willing
# to tolerate delays are advised to set this to false. Note that setting
# query_trusted_key_servers_first to true causes this option to be
# ignored.
#
#query_trusted_key_servers_first_on_join = true
# Only query trusted servers for keys and never the origin server. This is
# intended for clusters or custom deployments using their trusted_servers
# as forwarding-agents to cache and deduplicate requests. Notary servers
# do not act as forwarding-agents by default, therefor do not enable this
# unless you know exactly what you are doing.
#
#only_query_trusted_key_servers = false
# Maximum number of keys to request in each trusted server batch query.
#
#trusted_server_batch_size = 1024
# Max log level for continuwuity. Allows debug, info, warn, or error.
#
# See also:
# https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#directives
#
# **Caveat**:
# For release builds, the tracing crate is configured to only implement
# levels higher than error to avoid unnecessary overhead in the compiled
# binary from trace macros. For debug builds, this restriction is not
# applied.
#
#log = "info"
# Output logs with ANSI colours.
#
#log_colors = true
# Configures the span events which will be outputted with the log.
#
#log_span_events = "none"
# Configures whether CONTINUWUITY_LOG EnvFilter matches values using
# regular expressions. See the tracing_subscriber documentation on
# Directives.
#
#log_filter_regex = true
# Toggles the display of ThreadId in tracing log output.
#
#log_thread_ids = false
# Enable journald logging on Unix platforms
#
# When enabled, log output will be sent to the systemd journal
# This is only supported on Unix platforms
#
#log_to_journald = false
# The syslog identifier to use with journald logging
#
# Only used when journald logging is enabled
#
# Defaults to the binary name
#
#journald_identifier =
# OpenID token expiration/TTL in seconds.
#
# These are the OpenID tokens that are primarily used for Matrix account
# integrations (e.g. Vector Integrations in Element), *not* OIDC/OpenID
# Connect/etc.
#
#openid_token_ttl = 3600
# Allow an existing session to mint a login token for another client.
# This requires interactive authentication, but has security ramifications
# as a malicious client could use the mechanism to spawn more than one
# session.
# Enabled by default.
#
#login_via_existing_session = true
# Login token expiration/TTL in milliseconds.
#
# These are short-lived tokens for the m.login.token endpoint.
# This is used to allow existing sessions to create new sessions.
# see login_via_existing_session.
#
#login_token_ttl = 120000
# Static TURN username to provide the client if not using a shared secret
# ("turn_secret"), It is recommended to use a shared secret over static
# credentials.
#
#turn_username = false
# Static TURN password to provide the client if not using a shared secret
# ("turn_secret"). It is recommended to use a shared secret over static
# credentials.
#
#turn_password = false
# Vector list of TURN URIs/servers to use.
#
# Replace "example.turn.uri" with your TURN domain, such as the coturn
# "realm" config option. If using TURN over TLS, replace the URI prefix
# "turn:" with "turns:".
#
# example: ["turn:example.turn.uri?transport=udp",
# "turn:example.turn.uri?transport=tcp"]
#
#turn_uris = []
# TURN secret to use for generating the HMAC-SHA1 hash apart of username
# and password generation.
#
# This is more secure, but if needed you can use traditional static
# username/password credentials.
#
#turn_secret = false
# TURN secret to use that's read from the file path specified.
#
# This takes priority over "turn_secret" first, and falls back to
# "turn_secret" if invalid or failed to open.
#
# example: "/etc/continuwuity/.turn_secret"
#
#turn_secret_file =
# TURN TTL, in seconds.
#
#turn_ttl = 86400
# List/vector of room IDs or room aliases that continuwuity will make
# newly registered users join. The rooms specified must be rooms that you
# have joined at least once on the server, and must be public.
#
# example: ["#continuwuity:continuwuity.org",
# "!main-1:continuwuity.org"]
#
#auto_join_rooms = []
# Config option to automatically deactivate the account of any user who
# attempts to join a:
# - banned room
# - forbidden room alias
# - room alias or ID with a forbidden server name
#
# This may be useful if all your banned lists consist of toxic rooms or
# servers that no good faith user would ever attempt to join, and
# to automatically remediate the problem without any admin user
# intervention.
#
# This will also make the user leave all rooms. Federation (e.g. remote
# room invites) are ignored here.
#
# Defaults to false as rooms can be banned for non-moderation-related
# reasons and this performs a full user deactivation.
#
#auto_deactivate_banned_room_attempts = false
# RocksDB log level. This is not the same as continuwuity's log level.
# This is the log level for the RocksDB engine/library which show up in
# your database folder/path as `LOG` files. continuwuity will log RocksDB
# errors as normal through tracing or panics if severe for safety.
#
#rocksdb_log_level = "error"
# This item is undocumented. Please contribute documentation for it.
#
#rocksdb_log_stderr = false
# Max RocksDB `LOG` file size before rotating in bytes. Defaults to 4MB in
# bytes.
#
#rocksdb_max_log_file_size = 4194304
# Time in seconds before RocksDB will forcibly rotate logs.
#
#rocksdb_log_time_to_roll = 0
# Set this to true to use RocksDB config options that are tailored to HDDs
# (slower device storage).
#
# It is worth noting that by default, continuwuity will use RocksDB with
# Direct IO enabled. *Generally* speaking this improves performance as it
# bypasses buffered I/O (system page cache). However there is a potential
# chance that Direct IO may cause issues with database operations if your
# setup is uncommon. This has been observed with FUSE filesystems, and
# possibly ZFS filesystem. RocksDB generally deals/corrects these issues
# but it cannot account for all setups. If you experience any weird
# RocksDB issues, try enabling this option as it turns off Direct IO and
# feel free to report in the continuwuity Matrix room if this option fixes
# your DB issues.
#
# For more information, see:
# https://github.com/facebook/rocksdb/wiki/Direct-IO
#
#rocksdb_optimize_for_spinning_disks = false
# Enables direct-io to increase database performance via unbuffered I/O.
#
# For more details about direct I/O and RockDB, see:
# https://github.com/facebook/rocksdb/wiki/Direct-IO
#
# Set this option to false if the database resides on a filesystem which
# does not support direct-io like FUSE, or any form of complex filesystem
# setup such as possibly ZFS.
#
#rocksdb_direct_io = true
# Amount of threads that RocksDB will use for parallelism on database
# operations such as cleanup, sync, flush, compaction, etc. Set to 0 to
# use all your logical threads. Defaults to your CPU logical thread count.
#
#rocksdb_parallelism_threads = varies by system
# Maximum number of LOG files RocksDB will keep. This must *not* be set to
# 0. It must be at least 1. Defaults to 3 as these are not very useful
# unless troubleshooting/debugging a RocksDB bug.
#
#rocksdb_max_log_files = 3
# Type of RocksDB database compression to use.
#
# Available options are "zstd", "bz2", "lz4", or "none".
#
# It is best to use ZSTD as an overall good balance between
# speed/performance, storage, IO amplification, and CPU usage. For more
# performance but less compression (more storage used) and less CPU usage,
# use LZ4.
#
# For more details, see:
# https://github.com/facebook/rocksdb/wiki/Compression
#
# "none" will disable compression.
#
#rocksdb_compression_algo = "zstd"
# Level of compression the specified compression algorithm for RocksDB to
# use.
#
# Default is 32767, which is internally read by RocksDB as the default
# magic number and translated to the library's default compression level
# as they all differ. See their `kDefaultCompressionLevel`.
#
# Note when using the default value we may override it with a setting
# tailored specifically for continuwuity.
#
#rocksdb_compression_level = 32767
# Level of compression the specified compression algorithm for the
# bottommost level/data for RocksDB to use. Default is 32767, which is
# internally read by RocksDB as the default magic number and translated to
# the library's default compression level as they all differ. See their
# `kDefaultCompressionLevel`.
#
# Since this is the bottommost level (generally old and least used data),
# it may be desirable to have a very high compression level here as it's
# less likely for this data to be used. Research your chosen compression
# algorithm.
#
# Note when using the default value we may override it with a setting
# tailored specifically for continuwuity.
#
#rocksdb_bottommost_compression_level = 32767
# Whether to enable RocksDB's "bottommost_compression".
#
# At the expense of more CPU usage, this will further compress the
# database to reduce more storage. It is recommended to use ZSTD
# compression with this for best compression results. This may be useful
# if you're trying to reduce storage usage from the database.
#
# See https://github.com/facebook/rocksdb/wiki/Compression for more details.
#
#rocksdb_bottommost_compression = true
# Database recovery mode (for RocksDB WAL corruption).
#
# Use this option when the server reports corruption and refuses to start.
# Set mode 2 (PointInTime) to cleanly recover from this corruption. The
# server will continue from the last good state, several seconds or
# minutes prior to the crash. Clients may have to run "clear-cache &
# reload" to account for the rollback. Upon success, you may reset the
# mode back to default and restart again. Please note in some cases the
# corruption error may not be cleared for at least 30 minutes of operation
# in PointInTime mode.
#
# As a very last ditch effort, if PointInTime does not fix or resolve
# anything, you can try mode 3 (SkipAnyCorruptedRecord) but this will
# leave the server in a potentially inconsistent state.
#
# The default mode 1 (TolerateCorruptedTailRecords) will automatically
# drop the last entry in the database if corrupted during shutdown, but
# nothing more. It is extraordinarily unlikely this will desynchronize
# clients. To disable any form of silent rollback set mode 0
# (AbsoluteConsistency).
#
# The options are:
# 0 = AbsoluteConsistency
# 1 = TolerateCorruptedTailRecords (default)
# 2 = PointInTime (use me if trying to recover)
# 3 = SkipAnyCorruptedRecord (you now voided your Continuwuity warranty)
#
# For more information on these modes, see:
# https://github.com/facebook/rocksdb/wiki/WAL-Recovery-Modes
#
# For more details on recovering a corrupt database, see:
# https://continuwuity.org/troubleshooting.html#database-corruption
#
#rocksdb_recovery_mode = 1
# Enables or disables paranoid SST file checks. This can improve RocksDB
# database consistency at a potential performance impact due to further
# safety checks ran.
#
# For more information, see:
# https://github.com/facebook/rocksdb/wiki/Online-Verification#columnfamilyoptionsparanoid_file_checks
#
#rocksdb_paranoid_file_checks = false
# Enables or disables checksum verification in rocksdb at runtime.
# Checksums are usually hardware accelerated with low overhead; they are
# enabled in rocksdb by default. Older or slower platforms may see gains
# from disabling.
#
#rocksdb_checksums = true
# Enables the "atomic flush" mode in rocksdb. This option is not intended
# for users. It may be removed or ignored in future versions. Atomic flush
# may be enabled by the paranoid to possibly improve database integrity at
# the cost of performance.
#
#rocksdb_atomic_flush = false
# Database repair mode (for RocksDB SST corruption).
#
# Use this option when the server reports corruption while running or
# panics. If the server refuses to start use the recovery mode options
# first. Corruption errors containing the acronym 'SST' which occur after
# startup will likely require this option.
#
# - Backing up your database directory is recommended prior to running the
# repair.
#
# - Disabling repair mode and restarting the server is recommended after
# running the repair.
#
# See https://continuwuity.org/troubleshooting.html#database-corruption for more details on recovering a corrupt database.
#
#rocksdb_repair = false
# This item is undocumented. Please contribute documentation for it.
#
#rocksdb_read_only = false
# This item is undocumented. Please contribute documentation for it.
#
#rocksdb_secondary = false
# Enables idle CPU priority for compaction thread. This is not enabled by
# default to prevent compaction from falling too far behind on busy
# systems.
#
#rocksdb_compaction_prio_idle = false
# Enables idle IO priority for compaction thread. This prevents any
# unexpected lag in the server's operation and is usually a good idea.
# Enabled by default.
#
#rocksdb_compaction_ioprio_idle = true
# Enables RocksDB compaction. You should never ever have to set this
# option to false. If you for some reason find yourself needing to use
# this option as part of troubleshooting or a bug, please reach out to us
# in the continuwuity Matrix room with information and details.
#
# Disabling compaction will lead to a significantly bloated and
# explosively large database, gradually poor performance, unnecessarily
# excessive disk read/writes, and slower shutdowns and startups.
#
#rocksdb_compaction = true
# Level of statistics collection. Some admin commands to display database
# statistics may require this option to be set. Database performance may
# be impacted by higher settings.
#
# Option is a number ranging from 0 to 6:
# 0 = No statistics.
# 1 = No statistics in release mode (default).
# 2 to 3 = Statistics with no performance impact.
# 3 to 5 = Statistics with possible performance impact.
# 6 = All statistics.
#
#rocksdb_stats_level = 1
# This is a password that can be configured that will let you login to the
# server bot account (currently `@conduit`) for emergency troubleshooting
# purposes such as recovering/recreating your admin room, or inviting
# yourself back.
#
# See https://continuwuity.org/troubleshooting.html#lost-access-to-admin-room for other ways to get back into your admin room.
#
# Once this password is unset, all sessions will be logged out for
# security purposes.
#
# example: "F670$2CP@Hw8mG7RY1$%!#Ic7YA"
#
#emergency_password =
# This item is undocumented. Please contribute documentation for it.
#
#notification_push_path = "/_matrix/push/v1/notify"
# Allow local (your server only) presence updates/requests.
#
# Note that presence on continuwuity is very fast unlike Synapse's. If
# using outgoing presence, this MUST be enabled.
#
#allow_local_presence = true
# Allow incoming federated presence updates/requests.
#
# This option receives presence updates from other servers, but does not
# send any unless `allow_outgoing_presence` is true. Note that presence on
# continuwuity is very fast unlike Synapse's.
#
#allow_incoming_presence = true
# Allow outgoing presence updates/requests.
#
# This option sends presence updates to other servers, but does not
# receive any unless `allow_incoming_presence` is true. Note that presence
# on continuwuity is very fast unlike Synapse's. If using outgoing
# presence, you MUST enable `allow_local_presence` as well.
#
#allow_outgoing_presence = true
# How many seconds without presence updates before you become idle.
# Defaults to 5 minutes.
#
#presence_idle_timeout_s = 300
# How many seconds without presence updates before you become offline.
# Defaults to 30 minutes.
#
#presence_offline_timeout_s = 1800
# Enable the presence idle timer for remote users.
#
# Disabling is offered as an optimization for servers participating in
# many large rooms or when resources are limited. Disabling it may cause
# incorrect presence states (i.e. stuck online) to be seen for some remote
# users.
#
#presence_timeout_remote_users = true
# Allow local read receipts.
#
# Disabling this will effectively also disable outgoing federated read
# receipts.
#
#allow_local_read_receipts = true
# Allow receiving incoming read receipts from remote servers.
#
#allow_incoming_read_receipts = true
# Allow sending read receipts to remote servers.
#
#allow_outgoing_read_receipts = true
# Allow local typing updates.
#
# Disabling this will effectively also disable outgoing federated typing
# updates.
#
#allow_local_typing = true
# Allow outgoing typing updates to federation.
#
#allow_outgoing_typing = true
# Allow incoming typing updates from federation.
#
#allow_incoming_typing = true
# Maximum time federation user can indicate typing.
#
#typing_federation_timeout_s = 30
# Minimum time local client can indicate typing. This does not override a
# client's request to stop typing. It only enforces a minimum value in
# case of no stop request.
#
#typing_client_timeout_min_s = 15
# Maximum time local client can indicate typing.
#
#typing_client_timeout_max_s = 45
# Set this to true for continuwuity to compress HTTP response bodies using
# zstd. This option does nothing if continuwuity was not built with
# `zstd_compression` feature. Please be aware that enabling HTTP
# compression may weaken TLS. Most users should not need to enable this.
# See https://breachattack.com/ and https://wikipedia.org/wiki/BREACH
# before deciding to enable this.
#
#zstd_compression = false
# Set this to true for continuwuity to compress HTTP response bodies using
# gzip. This option does nothing if continuwuity was not built with
# `gzip_compression` feature. Please be aware that enabling HTTP
# compression may weaken TLS. Most users should not need to enable this.
# See https://breachattack.com/ and https://wikipedia.org/wiki/BREACH before
# deciding to enable this.
#
# If you are in a large amount of rooms, you may find that enabling this
# is necessary to reduce the significantly large response bodies.
#
#gzip_compression = false
# Set this to true for continuwuity to compress HTTP response bodies using
# brotli. This option does nothing if continuwuity was not built with
# `brotli_compression` feature. Please be aware that enabling HTTP
# compression may weaken TLS. Most users should not need to enable this.
# See https://breachattack.com/ and https://wikipedia.org/wiki/BREACH
# before deciding to enable this.
#
#brotli_compression = false
# Set to true to allow user type "guest" registrations. Some clients like
# Element attempt to register guest users automatically.
#
#allow_guest_registration = false
# Set to true to log guest registrations in the admin room. Note that
# these may be noisy or unnecessary if you're a public homeserver.
#
#log_guest_registrations = false
# Set to true to allow guest registrations/users to auto join any rooms
# specified in `auto_join_rooms`.
#
#allow_guests_auto_join_rooms = false
# Enable the legacy unauthenticated Matrix media repository endpoints.
# These endpoints consist of:
# - /_matrix/media/*/config
# - /_matrix/media/*/upload
# - /_matrix/media/*/preview_url
# - /_matrix/media/*/download/*
# - /_matrix/media/*/thumbnail/*
#
# The authenticated equivalent endpoints are always enabled.
#
# Defaults to true for now, but this is highly subject to change, likely
# in the next release.
#
#allow_legacy_media = true
# This item is undocumented. Please contribute documentation for it.
#
#freeze_legacy_media = true
# Check consistency of the media directory at startup:
# 1. When `media_compat_file_link` is enabled, this check will upgrade
# media when switching back and forth between Conduit and conduwuit.
# Both options must be enabled to handle this.
# 2. When media is deleted from the directory, this check will also delete
# its database entry.
#
# If none of these checks apply to your use cases, and your media
# directory is significantly large setting this to false may reduce
# startup time.
#
#media_startup_check = true
# Enable backward-compatibility with Conduit's media directory by creating
# symlinks of media.
#
# This option is only necessary if you plan on using Conduit again.
# Otherwise setting this to false reduces filesystem clutter and overhead
# for managing these symlinks in the directory. This is now disabled by
# default. You may still return to upstream Conduit but you have to run
# continuwuity at least once with this set to true and allow the
# media_startup_check to take place before shutting down to return to
# Conduit.
#
#media_compat_file_link = false
# Prune missing media from the database as part of the media startup
# checks.
#
# This means if you delete files from the media directory the
# corresponding entries will be removed from the database. This is
# disabled by default because if the media directory is accidentally moved
# or inaccessible, the metadata entries in the database will be lost with
# sadness.
#
#prune_missing_media = false
# List of forbidden server names via regex patterns that we will block
# incoming AND outgoing federation with, and block client room joins /
# remote user invites.
#
# Note that your messages can still make it to forbidden servers through
# backfilling. Events we receive from forbidden servers via backfill
# from servers we *do* federate with will be stored in the database.
#
# This check is applied on the room ID, room alias, sender server name,
# sender user's server name, inbound federation X-Matrix origin, and
# outbound federation handler.
#
# You can set this to ["*"] to block all servers by default, and then
# use `allowed_remote_server_names` to allow only specific servers.
#
# example: ["badserver\\.tld$", "badphrase", "19dollarfortnitecards"]
#
#forbidden_remote_server_names = []
# List of allowed server names via regex patterns that we will allow,
# regardless of if they match `forbidden_remote_server_names`.
#
# This option has no effect if `forbidden_remote_server_names` is empty.
#
# example: ["goodserver\\.tld$", "goodphrase"]
#
#allowed_remote_server_names = []
# Vector list of regex patterns of server names that continuwuity will
# refuse to download remote media from.
#
# example: ["badserver\.tld$", "badphrase", "19dollarfortnitecards"]
#
#prevent_media_downloads_from = []
# List of forbidden server names via regex patterns that we will block all
# outgoing federated room directory requests for. Useful for preventing
# our users from wandering into bad servers or spaces.
#
# example: ["badserver\.tld$", "badphrase", "19dollarfortnitecards"]
#
#forbidden_remote_room_directory_server_names = []
# Vector list of regex patterns of server names that continuwuity will not
# send messages to the client from.
#
# Note that there is no way for clients to receive messages once a server
# has become unignored without doing a full sync. This is a protocol
# limitation with the current sync protocols. This means this is somewhat
# of a nuclear option.
#
# example: ["reallybadserver\.tld$", "reallybadphrase",
# "69dollarfortnitecards"]
#
#ignore_messages_from_server_names = []
# Send messages from users that the user has ignored to the client.
#
# There is no way for clients to receive messages sent while a user was
# ignored without doing a full sync. This is a protocol limitation with
# the current sync protocols. Disabling this option will move
# responsibility of ignoring messages to the client, which can avoid this
# limitation.
#
#send_messages_from_ignored_users_to_client = false
# Vector list of IPv4 and IPv6 CIDR ranges / subnets *in quotes* that you
# do not want continuwuity to send outbound requests to. Defaults to
# RFC1918, unroutable, loopback, multicast, and testnet addresses for
# security.
#
# Please be aware that this is *not* a guarantee. You should be using a
# firewall with zones as doing this on the application layer may have
# bypasses.
#
# Currently this does not account for proxies in use like Synapse does.
#
# To disable, set this to be an empty vector (`[]`).
#
# Defaults to:
# ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12",
# "192.168.0.0/16", "100.64.0.0/10", "192.0.0.0/24", "169.254.0.0/16",
# "192.88.99.0/24", "198.18.0.0/15", "192.0.2.0/24", "198.51.100.0/24",
# "203.0.113.0/24", "224.0.0.0/4", "::1/128", "fe80::/10", "fc00::/7",
# "2001:db8::/32", "ff00::/8", "fec0::/10"]
#
#ip_range_denylist =
# Optional IP address or network interface-name to bind as the source of
# URL preview requests. If not set, it will not bind to a specific
# address or interface.
#
# Interface names only supported on Linux, Android, and Fuchsia platforms;
# all other platforms can specify the IP address. To list the interfaces
# on your system, use the command `ip link show`.
#
# example: `"eth0"` or `"1.2.3.4"`
#
#url_preview_bound_interface =
# Vector list of domains allowed to send requests to for URL previews.
#
# This is a *contains* match, not an explicit match. Putting "google.com"
# will match "https://google.com" and
# "http://mymaliciousdomainexamplegoogle.com" Setting this to "*" will
# allow all URL previews. Please note that this opens up significant
# attack surface to your server, you are expected to be aware of the risks
# by doing so.
#
#url_preview_domain_contains_allowlist = []
# Vector list of explicit domains allowed to send requests to for URL
# previews.
#
# This is an *explicit* match, not a contains match. Putting "google.com"
# will match "https://google.com", "http://google.com", but not
# "https://mymaliciousdomainexamplegoogle.com". Setting this to "*" will
# allow all URL previews. Please note that this opens up significant
# attack surface to your server, you are expected to be aware of the risks
# by doing so.
#
#url_preview_domain_explicit_allowlist = []
# Vector list of explicit domains not allowed to send requests to for URL
# previews.
#
# This is an *explicit* match, not a contains match. Putting "google.com"
# will match "https://google.com", "http://google.com", but not
# "https://mymaliciousdomainexamplegoogle.com". The denylist is checked
# first before allowlist. Setting this to "*" will not do anything.
#
#url_preview_domain_explicit_denylist = []
# Vector list of URLs allowed to send requests to for URL previews.
#
# Note that this is a *contains* match, not an explicit match. Putting
# "google.com" will match "https://google.com/",
# "https://google.com/url?q=https://mymaliciousdomainexample.com", and
# "https://mymaliciousdomainexample.com/hi/google.com" Setting this to "*"
# will allow all URL previews. Please note that this opens up significant
# attack surface to your server, you are expected to be aware of the risks
# by doing so.
#
#url_preview_url_contains_allowlist = []
# Maximum amount of bytes allowed in a URL preview body size when
# spidering. Defaults to 256KB in bytes.
#
#url_preview_max_spider_size = 256000
# Option to decide whether you would like to run the domain allowlist
# checks (contains and explicit) on the root domain or not. Does not apply
# to URL contains allowlist. Defaults to false.
#
# Example usecase: If this is enabled and you have "wikipedia.org" allowed
# in the explicit and/or contains domain allowlist, it will allow all
# subdomains under "wikipedia.org" such as "en.m.wikipedia.org" as the
# root domain is checked and matched. Useful if the domain contains
# allowlist is still too broad for you but you still want to allow all the
# subdomains under a root domain.
#
#url_preview_check_root_domain = false
# List of forbidden room aliases and room IDs as strings of regex
# patterns.
#
# Regex can be used or explicit contains matches can be done by just
# specifying the words (see example).
#
# This is checked upon room alias creation, custom room ID creation if
# used, and startup as warnings if any room aliases in your database have
# a forbidden room alias/ID.
#
# example: ["19dollarfortnitecards", "b[4a]droom", "badphrase"]
#
#forbidden_alias_names = []
# List of forbidden username patterns/strings.
#
# Regex can be used or explicit contains matches can be done by just
# specifying the words (see example).
#
# This is checked upon username availability check, registration, and
# startup as warnings if any local users in your database have a forbidden
# username.
#
# example: ["administrator", "b[a4]dusernam[3e]", "badphrase"]
#
#forbidden_usernames = []
# Retry failed and incomplete messages to remote servers immediately upon
# startup. This is called bursting. If this is disabled, said messages may
# not be delivered until more messages are queued for that server. Do not
# change this option unless server resources are extremely limited or the
# scale of the server's deployment is huge. Do not disable this unless you
# know what you are doing.
#
#startup_netburst = true
# Messages are dropped and not reattempted. The `startup_netburst` option
# must be enabled for this value to have any effect. Do not change this
# value unless you know what you are doing. Set this value to -1 to
# reattempt every message without trimming the queues; this may consume
# significant disk. Set this value to 0 to drop all messages without any
# attempt at redelivery.
#
#startup_netburst_keep = 50
# Block non-admin local users from sending room invites (local and
# remote), and block non-admin users from receiving remote room invites.
#
# Admins are always allowed to send and receive all room invites.
#
#block_non_admin_invites = false
# Allow admins to enter commands in rooms other than "#admins" (admin
# room) by prefixing your message with "\!admin" or "\\!admin" followed up
# a normal continuwuity admin command. The reply will be publicly visible
# to the room, originating from the sender.
#
# example: \\!admin debug ping puppygock.gay
#
#admin_escape_commands = true
# Automatically activate the continuwuity admin room console / CLI on
# startup. This option can also be enabled with `--console` continuwuity
# argument.
#
#admin_console_automatic = false
# List of admin commands to execute on startup.
#
# This option can also be configured with the `--execute` continuwuity
# argument and can take standard shell commands and environment variables
#
# For example: `./continuwuity --execute "server admin-notice continuwuity
# has started up at $(date)"`
#
# example: admin_execute = ["debug ping puppygock.gay", "debug echo hi"]`
#
#admin_execute = []
# Ignore errors in startup commands.
#
# If false, continuwuity will error and fail to start if an admin execute
# command (`--execute` / `admin_execute`) fails.
#
#admin_execute_errors_ignore = false
# List of admin commands to execute on SIGUSR2.
#
# Similar to admin_execute, but these commands are executed when the
# server receives SIGUSR2 on supporting platforms.
#
#admin_signal_execute = []
# Controls the max log level for admin command log captures (logs
# generated from running admin commands). Defaults to "info" on release
# builds, else "debug" on debug builds.
#
#admin_log_capture = "info"
# The default room tag to apply on the admin room.
#
# On some clients like Element, the room tag "m.server_notice" is a
# special pinned room at the very bottom of your room list. The
# continuwuity admin room can be pinned here so you always have an
# easy-to-access shortcut dedicated to your admin room.
#
#admin_room_tag = "m.server_notice"
# Sentry.io crash/panic reporting, performance monitoring/metrics, etc.
# This is NOT enabled by default.
#
#sentry = false
# Sentry reporting URL, if a custom one is desired.
#
#sentry_endpoint = ""
# Report your continuwuity server_name in Sentry.io crash reports and
# metrics.
#
#sentry_send_server_name = false
# Performance monitoring/tracing sample rate for Sentry.io.
#
# Note that too high values may impact performance, and can be disabled by
# setting it to 0.0 (0%) This value is read as a percentage to Sentry,
# represented as a decimal. Defaults to 15% of traces (0.15)
#
#sentry_traces_sample_rate = 0.15
# Whether to attach a stacktrace to Sentry reports.
#
#sentry_attach_stacktrace = false
# Send panics to Sentry. This is true by default, but Sentry has to be
# enabled. The global `sentry` config option must be enabled to send any
# data.
#
#sentry_send_panic = true
# Send errors to sentry. This is true by default, but sentry has to be
# enabled. This option is only effective in release-mode; forced to false
# in debug-mode.
#
#sentry_send_error = true
# Controls the tracing log level for Sentry to send things like
# breadcrumbs and transactions
#
#sentry_filter = "info"
# Enable the tokio-console. This option is only relevant to developers.
#
# For more information, see:
# https://continuwuity.org/development.html#debugging-with-tokio-console
#
#tokio_console = false
# This item is undocumented. Please contribute documentation for it.
#
#test = false
# Controls whether admin room notices like account registrations, password
# changes, account deactivations, room directory publications, etc will be
# sent to the admin room. Update notices and normal admin command
# responses will still be sent.
#
#admin_room_notices = true
# Enable database pool affinity support. On supporting systems, block
# device queue topologies are detected and the request pool is optimized
# for the hardware; db_pool_workers is determined automatically.
#
#db_pool_affinity = true
# Sets the number of worker threads in the frontend-pool of the database.
# This number should reflect the I/O capabilities of the system,
# such as the queue-depth or the number of simultaneous requests in
# flight. Defaults to 32 or four times the number of CPU cores, whichever
# is greater.
#
# Note: This value is only used if db_pool_affinity is disabled or not
# detected on the system, otherwise it is determined automatically.
#
#db_pool_workers = 32
# When db_pool_affinity is enabled and detected, the size of any worker
# group will not exceed the determined value. This is necessary when
# thread-pooling approach does not scale to the full capabilities of
# high-end hardware; using detected values without limitation could
# degrade performance.
#
# The value is multiplied by the number of cores which share a device
# queue, since group workers can be scheduled on any of those cores.
#
#db_pool_workers_limit = 64
# Determines the size of the queues feeding the database's frontend-pool.
# The size of the queue is determined by multiplying this value with the
# number of pool workers. When this queue is full, tokio tasks conducting
# requests will yield until space is available; this is good for
# flow-control by avoiding buffer-bloat, but can inhibit throughput if
# too low.
#
#db_pool_queue_mult = 4
# Sets the initial value for the concurrency of streams. This value simply
# allows overriding the default in the code. The default is 32, which is
# the same as the default in the code. Note this value is itself
# overridden by the computed stream_width_scale, unless that is disabled;
# this value can serve as a fixed-width instead.
#
#stream_width_default = 32
# Scales the stream width starting from a base value detected for the
# specific system. The base value is the database pool worker count
# determined from the hardware queue size (e.g. 32 for SSD or 64 or 128+
# for NVMe). This float allows scaling the width up or down by multiplying
# it (e.g. 1.5, 2.0, etc). The maximum result can be the size of the pool
# queue (see: db_pool_queue_mult) as any larger value will stall the tokio
# task. The value can also be scaled down (e.g. 0.5) to improve
# responsiveness for many users at the cost of throughput for each.
#
# Setting this value to 0.0 causes the stream width to be fixed at the
# value of stream_width_default. The default scale is 1.0 to match the
# capabilities detected for the system.
#
#stream_width_scale = 1.0
# Sets the initial amplification factor. This controls batch sizes of
# requests made by each pool worker, multiplying the throughput of each
# stream. This value is somewhat abstract from specific hardware
# characteristics and can be significantly larger than any thread count or
# queue size. This is because each database query may require several
# index lookups, thus many database queries in a batch may make progress
# independently while also sharing index and data blocks which may or may
# not be cached. It is worthwhile to submit huge batches to reduce
# complexity. The maximum value is 32768, though sufficient hardware is
# still advised for that.
#
#stream_amplification = 1024
# Number of sender task workers; determines sender parallelism. Default is
# '0' which means the value is determined internally, likely matching the
# number of tokio worker-threads or number of cores, etc. Override by
# setting a non-zero value.
#
#sender_workers = 0
# Enables listener sockets; can be set to false to disable listening. This
# option is intended for developer/diagnostic purposes only.
#
#listening = true
# Enables configuration reload when the server receives SIGUSR1 on
# supporting platforms.
#
#config_reload_signal = true
[global.tls]
# Path to a valid TLS certificate file.
#
# example: "/path/to/my/certificate.crt"
#
#certs =
# Path to a valid TLS certificate private key.
#
# example: "/path/to/my/certificate.key"
#
#key =
# Whether to listen and allow for HTTP and HTTPS connections (insecure!)
#
#dual_protocol = false
[global.well_known]
# The server URL that the client well-known file will serve. This should
# not contain a port, and should just be a valid HTTPS URL.
#
# example: "https://matrix.example.com"
#
#client =
# The server base domain of the URL with a specific port that the server
# well-known file will serve. This should contain a port at the end, and
# should not be a URL.
#
# example: "matrix.example.com:443"
#
#server =
# URL to a support page for the server, which will be served as part of
# the MSC1929 server support endpoint at /.well-known/matrix/support.
# Will be included alongside any contact information
#
#support_page =
# Role string for server support contacts, to be served as part of the
# MSC1929 server support endpoint at /.well-known/matrix/support.
#
#support_role = "m.role.admin"
# Email address for server support contacts, to be served as part of the
# MSC1929 server support endpoint.
# This will be used along with support_mxid if specified.
#
#support_email =
# Matrix ID for server support contacts, to be served as part of the
# MSC1929 server support endpoint.
# This will be used along with support_email if specified.
#
# If no email or mxid is specified, all of the server's admins will be
# listed.
#
#support_mxid =
[global.blurhashing]
# blurhashing x component, 4 is recommended by https://blurha.sh/
#
#components_x = 4
# blurhashing y component, 3 is recommended by https://blurha.sh/
#
#components_y = 3
# Max raw size that the server will blurhash, this is the size of the
# image after converting it to raw data, it should be higher than the
# upload limit but not too high. The higher it is the higher the
# potential load will be for clients requesting blurhashes. The default
# is 33.55MB. Setting it to 0 disables blurhashing.
#
#blurhash_max_raw_size = 33554432
Debian systemd unit file
Debian systemd unit file
[Unit]
Description=Continuwuity - Matrix homeserver
Wants=network-online.target
After=network-online.target
Documentation=https://continuwuity.org/
Alias=matrix-conduwuit.service
[Service]
DynamicUser=yes
User=conduwuit
Group=conduwuit
Type=notify
Environment="CONTINUWUITY_CONFIG=/etc/conduwuit/conduwuit.toml"
Environment="CONTINUWUITY_LOG_TO_JOURNALD=true"
Environment="CONTINUWUITY_JOURNALD_IDENTIFIER=%N"
ExecStart=/usr/sbin/conduwuit
ReadWritePaths=/var/lib/conduwuit /etc/conduwuit
AmbientCapabilities=
CapabilityBoundingSet=
DevicePolicy=closed
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
#ProcSubset=pid
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
PrivateIPC=yes
RemoveIPC=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service @resources
SystemCallFilter=~@clock @debug @module @mount @reboot @swap @cpu-emulation @obsolete @timer @chown @setuid @privileged @keyring @ipc
SystemCallErrorNumber=EPERM
#StateDirectory=conduwuit
RuntimeDirectory=conduwuit
RuntimeDirectoryMode=0750
Restart=on-failure
RestartSec=5
TimeoutStopSec=2m
TimeoutStartSec=2m
StartLimitInterval=1m
StartLimitBurst=5
[Install]
WantedBy=multi-user.target
Arch Linux systemd unit file
Arch Linux systemd unit file
[Unit]
Description=Continuwuity - Matrix homeserver
Wants=network-online.target
After=network-online.target
Documentation=https://continuwuity.org/
RequiresMountsFor=/var/lib/private/conduwuit
Alias=matrix-conduwuit.service
[Service]
DynamicUser=yes
Type=notify-reload
ReloadSignal=SIGUSR1
TTYPath=/dev/tty25
DeviceAllow=char-tty
StandardInput=tty-force
StandardOutput=tty
StandardError=journal+console
Environment="CONTINUWUITY_LOG_TO_JOURNALD=true"
Environment="CONTINUWUITY_JOURNALD_IDENTIFIER=%N"
TTYReset=yes
# uncomment to allow buffer to be cleared every restart
TTYVTDisallocate=no
TTYColumns=120
TTYRows=40
AmbientCapabilities=
CapabilityBoundingSet=
DevicePolicy=closed
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
#ProcSubset=pid
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
PrivateIPC=yes
RemoveIPC=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service @resources
SystemCallFilter=~@clock @debug @module @mount @reboot @swap @cpu-emulation @obsolete @timer @chown @setuid @privileged @keyring @ipc
SystemCallErrorNumber=EPERM
StateDirectory=conduwuit
RuntimeDirectory=conduwuit
RuntimeDirectoryMode=0750
Environment=CONTINUWUITY_CONFIG=${CREDENTIALS_DIRECTORY}/config.toml
LoadCredential=config.toml:/etc/conduwuit/conduwuit.toml
BindPaths=/var/lib/private/conduwuit:/var/lib/matrix-conduit
BindPaths=/var/lib/private/conduwuit:/var/lib/private/matrix-conduit
ExecStart=/usr/bin/conduwuit
Restart=on-failure
RestartSec=5
TimeoutStopSec=4m
TimeoutStartSec=4m
StartLimitInterval=1m
StartLimitBurst=5
[Install]
WantedBy=multi-user.target
Deploying
This chapter describes various ways to deploy Continuwuity.
Generic deployment documentation
Getting help
If you run into any problems while setting up Continuwuity, ask us in
#continuwuity:continuwuity.org
or open an issue on Forgejo.
Installing Continuwuity
Static prebuilt binary
You may simply download the binary that fits your machine architecture (x86_64
or aarch64). Run uname -m
to see what you need.
You can download prebuilt fully static musl binaries from the latest tagged
release here or
from the main
CI branch workflow artifact output. These also include Debian/Ubuntu
packages.
You can download these directly using curl. The ci-bins
are CI workflow binaries organized by commit
hash/revision, and releases
are tagged releases. Sort by descending last
modified date to find the latest.
These binaries have jemalloc and io_uring statically linked and included with them, so no additional dynamic dependencies need to be installed.
For the best performance: if you are using an x86_64
CPU made in the last ~15 years,
we recommend using the -haswell-
optimized binaries. These set
-march=haswell
, which provides the most compatible and highest performance with
optimized binaries. The database backend, RocksDB, benefits most from this as it
uses hardware-accelerated CRC32 hashing/checksumming, which is critical
for performance.
Compiling
Alternatively, you may compile the binary yourself.
Building with the Rust toolchain
If wanting to build using standard Rust toolchains, make sure you install:
- (On linux)
liburing-dev
on the compiling machine, andliburing
on the target host - (On linux)
pkg-config
on the compiling machine to allow findingliburing
- A C++ compiler and (on linux)
libclang
for RocksDB
You can build Continuwuity using cargo build --release --all-features
.
Building with Nix
If you prefer, you can use Nix (or Lix) to build Continuwuity. This provides improved reproducibility and makes it easy to set up a build environment and generate output. This approach also allows for easy cross-compilation.
You can run the nix build -L .#static-x86_64-linux-musl-all-features
or
nix build -L .#static-aarch64-linux-musl-all-features
commands based
on architecture to cross-compile the necessary static binary located at
result/bin/conduwuit
. This is reproducible with the static binaries produced
in our CI.
Adding a Continuwuity user
While Continuwuity can run as any user, it is better to use dedicated users for different services. This also ensures that the file permissions are set up correctly.
In Debian, you can use this command to create a Continuwuity user:
sudo adduser --system continuwuity --group --disabled-login --no-create-home
For distros without adduser
(or where it's a symlink to useradd
):
sudo useradd -r --shell /usr/bin/nologin --no-create-home continuwuity
Forwarding ports in the firewall or the router
Matrix's default federation port is 8448, and clients must use port 443.
If you would like to use only port 443 or a different port, you will need to set up
delegation. Continuwuity has configuration options for delegation, or you can configure
your reverse proxy to manually serve the necessary JSON files for delegation
(see the [global.well_known]
config section).
If Continuwuity runs behind a router or in a container and has a different public IP address than the host system, you need to forward these public ports directly or indirectly to the port mentioned in the configuration.
Note for NAT users: if you have trouble connecting to your server from inside your network, check if your router supports "NAT hairpinning" or "NAT loopback".
If your router does not support this feature, you need to research doing local
DNS overrides and force your Matrix DNS records to use your local IP internally.
This can be done at the host level using /etc/hosts
. If you need this to be
on the network level, consider something like NextDNS or Pi-Hole.
Setting up a systemd service
You can find two example systemd units for Continuwuity
on the configuration page.
You may need to change the ExecStart=
path to match where you placed the Continuwuity
binary if it is not in /usr/bin/conduwuit
.
On systems where rsyslog is used alongside journald (i.e. Red Hat-based distros
and OpenSUSE), put $EscapeControlCharactersOnReceive off
inside
/etc/rsyslog.conf
to allow color in logs.
If you are using a different database_path
than the systemd unit's
configured default /var/lib/conduwuit
, you need to add your path to the
systemd unit's ReadWritePaths=
. You can do this by either directly editing
conduwuit.service
and reloading systemd, or by running systemctl edit conduwuit.service
and entering the following:
[Service]
ReadWritePaths=/path/to/custom/database/path
Creating the Continuwuity configuration file
Now you need to create the Continuwuity configuration file in
/etc/continuwuity/continuwuity.toml
. You can find an example configuration at
conduwuit-example.toml.
Please take a moment to read the config. You need to change at least the server name.
RocksDB is the only supported database backend.
Setting the correct file permissions
If you are using a dedicated user for Continuwuity, you need to allow it to read the configuration. To do this, run:
sudo chown -R root:root /etc/conduwuit
sudo chmod -R 755 /etc/conduwuit
If you use the default database path you also need to run this:
sudo mkdir -p /var/lib/conduwuit/
sudo chown -R continuwuity:continuwuity /var/lib/conduwuit/
sudo chmod 700 /var/lib/conduwuit/
Setting up the Reverse Proxy
We recommend Caddy as a reverse proxy because it is trivial to use and handles TLS certificates, reverse proxy headers, etc. transparently with proper defaults. For other software, please refer to their respective documentation or online guides.
Caddy
After installing Caddy via your preferred method, create /etc/caddy/conf.d/conduwuit_caddyfile
and enter the following (substitute your actual server name):
your.server.name, your.server.name:8448 {
# TCP reverse_proxy
reverse_proxy 127.0.0.1:6167
# UNIX socket
#reverse_proxy unix//run/conduwuit/conduwuit.sock
}
That's it! Just start and enable the service and you're set.
sudo systemctl enable --now caddy
Other Reverse Proxies
As we prefer our users to use Caddy, we do not provide configuration files for other proxies.
You will need to reverse proxy everything under the following routes:
/_matrix/
- core Matrix C-S and S-S APIs/_conduwuit/
and/or/_continuwuity/
- ad-hoc Continuwuity routes such as/local_user_count
and/server_version
You can optionally reverse proxy the following individual routes:
/.well-known/matrix/client
and/.well-known/matrix/server
if using Continuwuity to perform delegation (see the[global.well_known]
config section)/.well-known/matrix/support
if using Continuwuity to send the homeserver admin contact and support page (formerly known as MSC1929)/
if you would like to seehewwo from conduwuit woof!
at the root
See the following spec pages for more details on these files:
Examples of delegation:
For Apache and Nginx there are many examples available online.
Lighttpd is not supported as it appears to interfere with the X-Matrix
Authorization
header, making federation non-functional. If you find a workaround, please share it so we can add it to this documentation.
If using Apache, you need to use nocanon
in your ProxyPass
directive to prevent httpd from interfering with the X-Matrix
header (note that Apache is not ideal as a general reverse proxy, so we discourage using it if alternatives are available).
If using Nginx, you need to pass the request URI to Continuwuity using $request_uri
, like this:
proxy_pass http://127.0.0.1:6167$request_uri;
proxy_pass http://127.0.0.1:6167;
Nginx users need to increase the client_max_body_size
setting (default is 1M) to match the
max_request_size
defined in conduwuit.toml.
You're done
Now you can start Continuwuity with:
sudo systemctl start conduwuit
Set it to start automatically when your system boots with:
sudo systemctl enable conduwuit
How do I know it works?
You can open a Matrix client, enter your homeserver address, and try to register.
You can also use these commands as a quick health check (replace
your.server.name
).
curl https://your.server.name/_conduwuit/server_version
# If using port 8448
curl https://your.server.name:8448/_conduwuit/server_version
# If federation is enabled
curl https://your.server.name:8448/_matrix/federation/v1/version
- To check if your server can communicate with other homeservers, use the Matrix Federation Tester. If you can register but cannot join federated rooms, check your configuration and verify that port 8448 is open and forwarded correctly.
What's next?
Audio/Video calls
For Audio/Video call functionality see the TURN Guide.
Appservices
If you want to set up an appservice, take a look at the Appservice Guide.
Continuwuity for NixOS
NixOS packages Continuwuity as matrix-continuwuity
. This package includes both the Continuwuity software and a dedicated NixOS module for configuration and deployment.
Installation methods
You can acquire Continuwuity with Nix (or Lix) from these sources:
- Directly from Nixpkgs using the official package (
pkgs.matrix-continuwuity
) - The
flake.nix
at the root of the Continuwuity repo - The
default.nix
at the root of the Continuwuity repo
NixOS module
Continuwuity now has an official NixOS module that simplifies configuration and deployment. The module is available in Nixpkgs as services.matrix-continuwuity
from NixOS 25.05.
Here's a basic example of how to use the module:
{ config, pkgs, ... }:
{
services.matrix-continuwuity = {
enable = true;
settings = {
global = {
server_name = "example.com";
# Listening on localhost by default
# address and port are handled automatically
allow_registration = false;
allow_encryption = true;
allow_federation = true;
trusted_servers = [ "matrix.org" ];
};
};
};
}
Available options
The NixOS module provides these configuration options:
enable
: Enable the Continuwuity serviceuser
: The user to run Continuwuity as (defaults to "continuwuity")group
: The group to run Continuwuity as (defaults to "continuwuity")extraEnvironment
: Extra environment variables to pass to the Continuwuity serverpackage
: The Continuwuity package to usesettings
: The Continuwuity configuration (in TOML format)
Use the settings
option to configure Continuwuity itself. See the example configuration file for all available options.
UNIX sockets
The NixOS module natively supports UNIX sockets through the global.unix_socket_path
option. When using UNIX sockets, set global.address
to null
:
services.matrix-continuwuity = {
enable = true;
settings = {
global = {
server_name = "example.com";
address = null; # Must be null when using unix_socket_path
unix_socket_path = "/run/continuwuity/continuwuity.sock";
unix_socket_perms = 660; # Default permissions for the socket
# ...
};
};
};
The module automatically sets the correct RestrictAddressFamilies
in the systemd service configuration to allow access to UNIX sockets.
RocksDB database
Continuwuity exclusively uses RocksDB as its database backend. The system configures the database path automatically to /var/lib/continuwuity/
and you cannot change it due to the service's reliance on systemd's StateDir.
If you're migrating from Conduit with SQLite, use this tool to migrate a Conduit SQLite database to RocksDB.
jemalloc and hardened profile
Continuwuity uses jemalloc by default. This may interfere with the hardened.nix
profile because it uses scudo
by default. Either disable/hide scudo
from Continuwuity or disable jemalloc like this:
services.matrix-continuwuity = {
enable = true;
package = pkgs.matrix-continuwuity.override {
enableJemalloc = false;
};
# ...
};
Upgrading from Conduit
If you previously used Conduit with the services.matrix-conduit
module:
- Ensure your Conduit uses the RocksDB backend, or migrate from SQLite using the migration tool
- Switch to the new module by changing
services.matrix-conduit
toservices.matrix-continuwuity
in your configuration - Update any custom configuration to match the new module's structure
Reverse proxy configuration
You'll need to set up a reverse proxy (like nginx or caddy) to expose Continuwuity to the internet. Configure your reverse proxy to forward requests to /_matrix
on port 443 and 8448 to your Continuwuity instance.
Here's an example nginx configuration:
server {
listen 443 ssl;
listen [::]:443 ssl;
listen 8448 ssl;
listen [::]:8448 ssl;
server_name example.com;
# SSL configuration here...
location /_matrix/ {
proxy_pass http://127.0.0.1:6167$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Continuwuity for Docker
Docker
To run Continuwuity with Docker, you can either build the image yourself or pull it from a registry.
Use a registry
OCI images for Continuwuity are available in the registries listed below.
Registry | Image | Notes |
---|---|---|
Forgejo Registry | forgejo.ellis.link/continuwuation/continuwuity:latest | Latest tagged image. |
Forgejo Registry | forgejo.ellis.link/continuwuation/continuwuity:main | Main branch image. |
Use
docker image pull $LINK
to pull it to your machine.
Run
When you have the image, you can simply run it with
docker run -d -p 8448:6167 \
-v db:/var/lib/continuwuity/ \
-e CONTINUWUITY_SERVER_NAME="your.server.name" \
-e CONTINUWUITY_ALLOW_REGISTRATION=false \
--name continuwuity $LINK
or you can use Docker Compose.
The -d
flag lets the container run in detached mode. You may supply an
optional continuwuity.toml
config file, the example config can be found
here. You can pass in different env vars to
change config values on the fly. You can even configure Continuwuity completely by
using env vars. For an overview of possible values, please take a look at the
docker-compose.yml
file.
If you just want to test Continuwuity for a short time, you can use the --rm
flag, which cleans up everything related to your container after you stop
it.
Docker-compose
If the docker run
command is not suitable for you or your setup, you can also use one
of the provided docker-compose
files.
Depending on your proxy setup, you can use one of the following files:
- If you already have a
traefik
instance set up, usedocker-compose.for-traefik.yml
- If you don't have a
traefik
instance set up and would like to use it, usedocker-compose.with-traefik.yml
- If you want a setup that works out of the box with
caddy-docker-proxy
, usedocker-compose.with-caddy.yml
and replace allexample.com
placeholders with your own domain - For any other reverse proxy, use
docker-compose.yml
When picking the Traefik-related compose file, rename it to
docker-compose.yml
, and rename the override file to
docker-compose.override.yml
. Edit the latter with the values you want for your
server.
When picking the caddy-docker-proxy
compose file, it's important to first
create the caddy
network before spinning up the containers:
docker network create caddy
After that, you can rename it to docker-compose.yml
and spin up the
containers!
Additional info about deploying Continuwuity can be found here.
Build
Official Continuwuity images are built using Docker Buildx and the Dockerfile found at docker/Dockerfile
. This approach uses common Docker tooling and enables efficient multi-platform builds.
The resulting images are widely compatible with Docker and other container runtimes like Podman or containerd.
The images do not contain a shell. They contain only the Continuwuity binary, required libraries, TLS certificates, and metadata. Please refer to the docker/Dockerfile
for the specific details of the image composition.
To build an image locally using Docker Buildx, you can typically run a command like:
# Build for the current platform and load into the local Docker daemon
docker buildx build --load --tag continuwuity:latest -f docker/Dockerfile .
# Example: Build for specific platforms and push to a registry.
# docker buildx build --platform linux/amd64,linux/arm64 --tag registry.io/org/continuwuity:latest -f docker/Dockerfile . --push
# Example: Build binary optimized for the current CPU
# docker buildx build --load --tag continuwuity:latest --build-arg TARGET_CPU=native -f docker/Dockerfile .
Refer to the Docker Buildx documentation for more advanced build options.
Run
If you have already built the image or want to use one from the registries, you can start the container and everything else in the compose file in detached mode with:
docker compose up -d
Note: Don't forget to modify and adjust the compose file to your needs.
Use Traefik as Proxy
As a container user, you probably know about Traefik. It is an easy-to-use
reverse proxy for making containerized apps and services available through the
web. With the two provided files,
docker-compose.for-traefik.yml
(or
docker-compose.with-traefik.yml
) and
docker-compose.override.yml
, it is equally easy
to deploy and use Continuwuity, with a small caveat. If you have already looked at
the files, you should have seen the well-known
service, which is the
small caveat. Traefik is simply a proxy and load balancer and cannot
serve any kind of content. For Continuwuity to federate, we need to either
expose ports 443
and 8448
or serve two endpoints: .well-known/matrix/client
and .well-known/matrix/server
.
With the service well-known
, we use a single nginx
container that serves
those two files.
Alternatively, you can use Continuwuity's built-in delegation file capability. Set up the delegation files in the configuration file, and then proxy paths under /.well-known/matrix
to continuwuity. For example, the label traefik.http.routers.continuwuity.rule=(Host(`matrix.ellis.link`) || (Host(`ellis.link`) && PathPrefix(`/.well-known/matrix`)))
does this for the domain ellis.link
.
Voice communication
See the TURN page.
Continuwuity for Kubernetes
Continuwuity doesn't support horizontal scalability or distributed loading natively. However, a community-maintained Helm Chart is available here to run conduwuit on Kubernetes: https://gitlab.cronce.io/charts/conduwuit
This should be compatible with Continuwuity, but you will need to change the image reference.
If changes need to be made, please reach out to the maintainer, as this is not maintained or controlled by the Continuwuity maintainers.
Continuwuity for Arch Linux
Continuwuity is available in the archlinuxcn
repository and AUR with the same package name continuwuity
, which includes the latest tagged version. The development version is available on AUR as continuwuity-git
.
Simply install the continuwuity
package. Configure the service in /etc/conduwuit/conduwuit.toml
, then enable and start the continuwuity.service.
Continuwuity for Debian
This document provides information about downloading and deploying the Debian package. You can also use this guide for other apt
-based distributions such as Ubuntu.
Installation
See the generic deployment guide for additional information about using the Debian package.
No apt
repository is currently available. This feature is in development.
Configuration
After installation, Continuwuity places the example configuration at /etc/conduwuit/conduwuit.toml
as the default configuration file. The configuration file indicates which settings you must change before starting the service.
You can customize additional settings by uncommenting and modifying the configuration options in /etc/conduwuit/conduwuit.toml
.
Running
The package uses the conduwuit.service
systemd unit file to start and stop Continuwuity. The binary installs at /usr/sbin/conduwuit
.
By default, this package assumes that Continuwuity runs behind a reverse proxy. The default configuration options apply (listening on localhost
and TCP port 6167
). Matrix federation requires a valid domain name and TLS. To federate properly, you must set up TLS certificates and certificate renewal.
For information about setting up a reverse proxy and TLS, consult online documentation and guides. The generic deployment guide documents Caddy, which is the most user-friendly option for reverse proxy configuration.
Continuwuity for FreeBSD
Continuwuity currently does not provide FreeBSD builds or FreeBSD packaging. However, Continuwuity does build and work on FreeBSD using the system-provided RocksDB.
Contributions to get Continuwuity packaged for FreeBSD are welcome.
Setting up TURN/STURN
In order to make or receive calls, a TURN server is required. Continuwuity suggests using Coturn for this purpose, which is also available as a Docker image.
Configuration
Create a configuration file called coturn.conf
containing:
use-auth-secret
static-auth-secret=<a secret key>
realm=<your server domain>
A common way to generate a suitable alphanumeric secret key is by using pwgen -s 64 1
.
These same values need to be set in Continuwuity. See the example config in the TURN section for configuring these and restart Continuwuity after.
turn_secret
or a path to turn_secret_file
must have a value of your
coturn static-auth-secret
, or use turn_username
and turn_password
if using legacy username:password TURN authentication (not preferred).
turn_uris
must be the list of TURN URIs you would like to send to the client.
Typically you will just replace the example domain example.turn.uri
with the
realm
you set from the example config.
If you are using TURN over TLS, you can replace turn:
with turns:
in the
turn_uris
config option to instruct clients to attempt to connect to
TURN over TLS. This is highly recommended.
If you need unauthenticated access to the TURN URIs, or some clients may be
having trouble, you can enable turn_guest_access
in Continuwuity which disables
authentication for the TURN URI endpoint /_matrix/client/v3/voip/turnServer
Run
Run the Coturn image using
docker run -d --network=host -v
$(pwd)/coturn.conf:/etc/coturn/turnserver.conf coturn/coturn
or docker-compose. For the latter, paste the following section into a file
called docker-compose.yml
and run docker compose up -d
in the same
directory.
version: 3
services:
turn:
container_name: coturn-server
image: docker.io/coturn/coturn
restart: unless-stopped
network_mode: "host"
volumes:
- ./coturn.conf:/etc/coturn/turnserver.conf
To understand why the host networking mode is used and explore alternative configuration options, please visit Coturn's Docker documentation.
For security recommendations see Synapse's Coturn documentation.
Testing
To make sure turn credentials are being correctly served to clients, you can manually make a HTTP request to the turnServer endpoint.
curl "https://<matrix.example.com>/_matrix/client/r0/voip/turnServer" -H 'Authorization: Bearer <your_client_token>' | jq
You should get a response like this:
{
"username": "1752792167:@jade:example.com",
"password": "KjlDlawdPbU9mvP4bhdV/2c/h65=",
"uris": [
"turns:coturn.example.com?transport=udp",
"turns:coturn.example.com?transport=tcp",
"turn:coturn.example.com?transport=udp",
"turn:coturn.example.com?transport=tcp"
],
"ttl": 86400
}
You can test these credentials work using Trickle ICE
Setting up Appservices
Getting help
If you run into any problems while setting up an Appservice: ask us in #continuwuity:continuwuity.org or open an issue on Forgejo.
Set up the appservice - general instructions
Follow whatever instructions are given by the appservice. This usually includes downloading, changing its config (setting domain, homeserver url, port etc.) and later starting it.
At some point the appservice guide should ask you to add a registration yaml file to the homeserver. In Synapse you would do this by adding the path to the homeserver.yaml, but in Continuwuity you can do this from within Matrix:
First, go into the #admins
room of your homeserver. The first person that
registered on the homeserver automatically joins it. Then send a message into
the room like this:
!admin appservices register
```
paste
the
contents
of
the
yaml
registration
here
```
You can confirm it worked by sending a message like this:
!admin appservices list
The server bot should answer with Appservices (1): your-bridge
Then you are done. Continuwuity will send messages to the appservices and the appservice can send requests to the homeserver. You don't need to restart Continuwuity, but if it doesn't work, restarting while the appservice is running could help.
Appservice-specific instructions
Remove an appservice
To remove an appservice go to your admin room and execute
!admin appservices unregister <name>
where <name>
one of the output of appservices list
.
Maintaining your Continuwuity setup
Moderation
Continuwuity has moderation through admin room commands. "binary commands" (medium priority) and an admin API (low priority) is planned. Some moderation-related config options are available in the example config such as "global ACLs" and blocking media requests to certain servers. See the example config for the moderation config options under the "Moderation / Privacy / Security" section.
Continuwuity has moderation admin commands for:
- managing room aliases (
!admin rooms alias
) - managing room directory (
!admin rooms directory
) - managing room banning/blocking and user removal (
!admin rooms moderation
) - managing user accounts (
!admin users
) - fetching
/.well-known/matrix/support
from servers (!admin federation
) - blocking incoming federation for certain rooms (not the same as room banning)
(
!admin federation
) - deleting media (see the media section)
Any commands with -list
in them will require a codeblock in the message with
each object being newline delimited. An example of doing this is:
!admin rooms moderation ban-list-of-rooms
```
!roomid1:server.name
#badroomalias1:server.name
!roomid2:server.name
!roomid3:server.name
#badroomalias2:server.name
```
Database (RocksDB)
Generally there is very little you need to do. Compaction is ran automatically based on various defined thresholds tuned for Continuwuity to be high performance with the least I/O amplifcation or overhead. Manually running compaction is not recommended, or compaction via a timer, due to creating unnecessary I/O amplification. RocksDB is built with io_uring support via liburing for improved read performance.
RocksDB troubleshooting can be found in the RocksDB section of troubleshooting.
Compression
Some RocksDB settings can be adjusted such as the compression method chosen. See the RocksDB section in the example config.
btrfs users have reported that database compression does not need to be disabled
on Continuwuity as the filesystem already does not attempt to compress. This can be
validated by using filefrag -v
on a .SST
file in your database, and ensure
the physical_offset
matches (no filesystem compression). It is very important
to ensure no additional filesystem compression takes place as this can render
unbuffered Direct IO inoperable, significantly slowing down read and write
performance. See https://btrfs.readthedocs.io/en/latest/Compression.html#compatibility
Compression is done using the COW mechanism so it’s incompatible with nodatacow. Direct IO read works on compressed files but will fall back to buffered writes and leads to no compression even if force compression is set. Currently nodatasum and compression don’t work together.
Files in database
Do not touch any of the files in the database directory. This must be said due
to users being mislead by the .log
files in the RocksDB directory, thinking
they're server logs or database logs, however they are critical RocksDB files
related to WAL tracking.
The only safe files that can be deleted are the LOG
files (all caps). These
are the real RocksDB telemetry/log files, however Continuwuity has already
configured to only store up to 3 RocksDB LOG
files due to generally being
useless for average users unless troubleshooting something low-level. If you
would like to store nearly none at all, see the rocksdb_max_log_files
config option.
Backups
Currently only RocksDB supports online backups. If you'd like to backup your
database online without any downtime, see the !admin server
command for the
backup commands and the database_backup_path
config options in the example
config. Please note that the format of the database backup is not the exact
same. This is unfortunately a bad design choice by Facebook as we are using the
database backup engine API from RocksDB, however the data is still there and can
still be joined together.
To restore a backup from an online RocksDB backup:
- shutdown Continuwuity
- create a new directory for merging together the data
- in the online backup created, copy all
.sst
files in$DATABASE_BACKUP_PATH/shared_checksum
to your new directory - trim all the strings so instead of
######_sxxxxxxxxx.sst
, it reads######.sst
. A way of doing this with sed and bash isfor file in *.sst; do mv "$file" "$(echo "$file" | sed 's/_s.*/.sst/')"; done
- copy all the files in
$DATABASE_BACKUP_PATH/1
(or the latest backup number if you have multiple) to your new directory - set your
database_path
config option to your new directory, or replace your old one with the new one you crafted - start up Continuwuity again and it should open as normal
If you'd like to do an offline backup, shutdown Continuwuity and copy your
database_path
directory elsewhere. This can be restored with no modifications
needed.
Backing up media is also just copying the media/
directory from your database
directory.
Media
Media still needs various work, however Continuwuity implements media deletion via:
- MXC URI or Event ID (unencrypted and attempts to find the MXC URI in the event)
- Delete list of MXC URIs
- Delete remote media in the past
N
seconds/minutes via filesystem metadata on the file created time (btime
) or file modified time (mtime
)
See the !admin media
command for further information. All media in Continuwuity
is stored at $DATABASE_DIR/media
. This will be configurable soon.
If you are finding yourself needing extensive granular control over media, we recommend looking into Matrix Media Repo. Continuwuity intends to implement various utilities for media, but MMR is dedicated to extensive media management.
Built-in S3 support is also planned, but for now using a "S3 filesystem" on
media/
works. Continuwuity also sends a Cache-Control
header of 1 year and
immutable for all media requests (download and thumbnail) to reduce unnecessary
media requests from browsers, reduce bandwidth usage, and reduce load.
Troubleshooting Continuwuity
Docker users ⚠️
Docker can be difficult to use and debug. It's common for Docker misconfigurations to cause issues, particularly with networking and permissions. Please check that your issues are not due to problems with your Docker setup.
Continuwuity and Matrix issues
Lost access to admin room
You can reinvite yourself to the admin room through the following methods:
- Use the
--execute "users make_user_admin <username>"
Continuwuity binary argument once to invite yourslf to the admin room on startup - Use the Continuwuity console/CLI to run the
users make_user_admin
command - Or specify the
emergency_password
config option to allow you to temporarily log into the server account (@conduit
) from a web client
General potential issues
Potential DNS issues when using Docker
Docker's DNS setup for containers in a non-default network intercepts queries to enable resolving of container hostnames to IP addresses. However, due to performance issues with Docker's built-in resolver, this can cause DNS queries to take a long time to resolve, resulting in federation issues.
This is particularly common with Docker Compose, as custom networks are easily created and configured.
Symptoms of this include excessively long room joins (30+ minutes) from very long DNS timeouts, log entries of "mismatching responding nameservers", and/or partial or non-functional inbound/outbound federation.
This is not a bug in continuwuity. Docker's default DNS resolver is not suitable for heavy DNS activity, which is normal for federated protocols like Matrix.
Workarounds:
- Use DNS over TCP via the config option
query_over_tcp_only = true
- Bypass Docker's default DNS setup and instead allow the container to use and communicate with your host's DNS servers. Typically, this can be done by mounting the host's
/etc/resolv.conf
.
DNS No connections available error message
If you receive spurious amounts of error logs saying "DNS No connections
available", this is due to your DNS server (servers from /etc/resolv.conf
)
being overloaded and unable to handle typical Matrix federation volume. Some
users have reported that the upstream servers are rate-limiting them as well
when they get this error (e.g. popular upstreams like Google DNS).
Matrix federation is extremely heavy and sends wild amounts of DNS requests. Unfortunately this is by design and has only gotten worse with more server/destination resolution steps. Synapse also expects a very perfect DNS setup.
There are some ways you can reduce the amount of DNS queries, but ultimately the best solution/fix is selfhosting a high quality caching DNS server like Unbound without any upstream resolvers, and without DNSSEC validation enabled.
DNSSEC validation is highly recommended to be disabled due to DNSSEC being very computationally expensive, and is extremely susceptible to denial of service, especially on Matrix. Many servers also strangely have broken DNSSEC setups and will result in non-functional federation.
Continuwuity cannot provide a "works-for-everyone" Unbound DNS setup guide, but
the official Unbound tuning guide and the Unbound Arch Linux wiki page
may be of interest. Disabling DNSSEC on Unbound is commenting out trust-anchors
config options and removing the validator
module.
Avoid using systemd-resolved
as it does not perform very well under
high load, and we have identified its DNS caching to not be very effective.
dnsmasq can possibly work, but it does not support TCP fallback which can be
problematic when receiving large DNS responses such as from large SRV records.
If you still want to use dnsmasq, make sure you disable dns_tcp_fallback
in Continuwuity config.
Raising dns_cache_entries
in Continuwuity config from the default can also assist
in DNS caching, but a full-fledged external caching resolver is better and more
reliable.
If you don't have IPv6 connectivity, changing ip_lookup_strategy
to match
your setup can help reduce unnecessary AAAA queries
(1 - Ipv4Only (Only query for A records, no AAAA/IPv6)
).
If your DNS server supports it, some users have reported enabling
query_over_tcp_only
to force only TCP querying by default has improved DNS
reliability at a slight performance cost due to TCP overhead.
RocksDB / database issues
Database corruption
If your database is corrupted and is failing to start (e.g. checksum mismatch), it may be recoverable but careful steps must be taken, and there is no guarantee it may be recoverable.
The first thing that can be done is launching Continuwuity with the
rocksdb_repair
config option set to true. This will tell RocksDB to attempt to
repair itself at launch. If this does not work, disable the option and continue
reading.
RocksDB has the following recovery modes:
TolerateCorruptedTailRecords
AbsoluteConsistency
PointInTime
SkipAnyCorruptedRecord
By default, Continuwuity uses TolerateCorruptedTailRecords
as generally these may
be due to bad federation and we can re-fetch the correct data over federation.
The RocksDB default is PointInTime
which will attempt to restore a "snapshot"
of the data when it was last known to be good. This data can be either a few
seconds old, or multiple minutes prior. PointInTime
may not be suitable for
default usage due to clients and servers possibly not being able to handle
sudden "backwards time travels", and AbsoluteConsistency
may be too strict.
AbsoluteConsistency
will fail to start the database if any sign of corruption
is detected. SkipAnyCorruptedRecord
will skip all forms of corruption unless
it forbids the database from opening (e.g. too severe). Usage of
SkipAnyCorruptedRecord
voids any support as this may cause more damage and/or
leave your database in a permanently inconsistent state, but it may do something
if PointInTime
does not work as a last ditch effort.
With this in mind:
- First start Continuwuity with the
PointInTime
recovery method. See the example config for how to do this usingrocksdb_recovery_mode
- If your database successfully opens, clients are recommended to clear their client cache to account for the rollback
- Leave your Continuwuity running in
PointInTime
for at least 30-60 minutes so as much possible corruption is restored - If all goes will, you should be able to restore back to using
TolerateCorruptedTailRecords
and you have successfully recovered your database
Debugging
Note that users should not really be debugging things. If you find yourself
debugging and find the issue, please let us know and/or how we can fix it.
Various debug commands can be found in !admin debug
.
Debug/Trace log level
Continuwuity builds without debug or trace log levels at compile time by default
for substantial performance gains in CPU usage and improved compile times. If
you need to access debug/trace log levels, you will need to build without the
release_max_log_level
feature or use our provided static debug binaries.
Changing log level dynamically
Continuwuity supports changing the tracing log environment filter on-the-fly using
the admin command !admin debug change-log-level <log env filter>
. This accepts
a string without quotes the same format as the log
config option.
Example: !admin debug change-log-level debug
This can also accept complex filters such as:
!admin debug change-log-level info,conduit_service[{dest="example.com"}]=trace,ruma_state_res=trace
!admin debug change-log-level info,conduit_service[{dest="example.com"}]=trace,conduit_service[send{dest="example.org"}]=trace
And to reset the log level to the one that was set at startup / last config
load, simply pass the --reset
flag.
!admin debug change-log-level --reset
Pinging servers
Continuwuity can ping other servers using !admin debug ping <server>
. This takes
a server name and goes through the server discovery process and queries
/_matrix/federation/v1/version
. Errors are outputted.
While it does measure the latency of the request, it is not indicative of server performance on either side as that endpoint is completely unauthenticated and simply fetches a string on a static JSON endpoint. It is very low cost both bandwidth and computationally.
Allocator memory stats
When using jemalloc with jemallocator's stats
feature (--enable-stats
), you
can see Continuwuity's high-level allocator stats by using
!admin server memory-usage
at the bottom.
If you are a developer, you can also view the raw jemalloc statistics with
!admin debug memory-stats
. Please note that this output is extremely large
which may only be visible in the Continuwuity console CLI due to PDU size limits,
and is not easy for non-developers to understand.
Command-Line Help for admin
This document contains the help content for the admin
command-line program.
Command Overview:
admin
↴admin appservices
↴admin appservices register
↴admin appservices unregister
↴admin appservices show-appservice-config
↴admin appservices list-registered
↴admin users
↴admin users create-user
↴admin users reset-password
↴admin users deactivate
↴admin users deactivate-all
↴admin users suspend
↴admin users unsuspend
↴admin users list-users
↴admin users list-joined-rooms
↴admin users force-join-room
↴admin users force-leave-room
↴admin users force-demote
↴admin users make-user-admin
↴admin users put-room-tag
↴admin users delete-room-tag
↴admin users get-room-tags
↴admin users redact-event
↴admin users force-join-list-of-local-users
↴admin users force-join-all-local-users
↴admin rooms
↴admin rooms list-rooms
↴admin rooms info
↴admin rooms info list-joined-members
↴admin rooms info view-room-topic
↴admin rooms moderation
↴admin rooms moderation ban-room
↴admin rooms moderation ban-list-of-rooms
↴admin rooms moderation unban-room
↴admin rooms moderation list-banned-rooms
↴admin rooms alias
↴admin rooms alias set
↴admin rooms alias remove
↴admin rooms alias which
↴admin rooms alias list
↴admin rooms directory
↴admin rooms directory publish
↴admin rooms directory unpublish
↴admin rooms directory list
↴admin rooms exists
↴admin federation
↴admin federation incoming-federation
↴admin federation disable-room
↴admin federation enable-room
↴admin federation fetch-support-well-known
↴admin federation remote-user-in-rooms
↴admin server
↴admin server uptime
↴admin server show-config
↴admin server reload-config
↴admin server list-features
↴admin server memory-usage
↴admin server clear-caches
↴admin server backup-database
↴admin server list-backups
↴admin server admin-notice
↴admin server reload-mods
↴admin server restart
↴admin server shutdown
↴admin media
↴admin media delete
↴admin media delete-list
↴admin media delete-past-remote-media
↴admin media delete-all-from-user
↴admin media delete-all-from-server
↴admin media get-file-info
↴admin media get-remote-file
↴admin media get-remote-thumbnail
↴admin check
↴admin check check-all-users
↴admin debug
↴admin debug echo
↴admin debug get-auth-chain
↴admin debug parse-pdu
↴admin debug get-pdu
↴admin debug get-short-pdu
↴admin debug get-remote-pdu
↴admin debug get-remote-pdu-list
↴admin debug get-room-state
↴admin debug get-signing-keys
↴admin debug get-verify-keys
↴admin debug ping
↴admin debug force-device-list-updates
↴admin debug change-log-level
↴admin debug sign-json
↴admin debug verify-json
↴admin debug verify-pdu
↴admin debug first-pdu-in-room
↴admin debug latest-pdu-in-room
↴admin debug force-set-room-state-from-server
↴admin debug resolve-true-destination
↴admin debug memory-stats
↴admin debug runtime-metrics
↴admin debug runtime-interval
↴admin debug time
↴admin debug list-dependencies
↴admin debug database-stats
↴admin debug trim-memory
↴admin debug database-files
↴admin query
↴admin query account-data
↴admin query account-data changes-since
↴admin query account-data account-data-get
↴admin query appservice
↴admin query appservice get-registration
↴admin query appservice all
↴admin query presence
↴admin query presence get-presence
↴admin query presence presence-since
↴admin query room-alias
↴admin query room-alias resolve-local-alias
↴admin query room-alias local-aliases-for-room
↴admin query room-alias all-local-aliases
↴admin query room-state-cache
↴admin query room-state-cache server-in-room
↴admin query room-state-cache room-servers
↴admin query room-state-cache server-rooms
↴admin query room-state-cache room-members
↴admin query room-state-cache local-users-in-room
↴admin query room-state-cache active-local-users-in-room
↴admin query room-state-cache room-joined-count
↴admin query room-state-cache room-invited-count
↴admin query room-state-cache room-user-once-joined
↴admin query room-state-cache room-members-invited
↴admin query room-state-cache get-invite-count
↴admin query room-state-cache get-left-count
↴admin query room-state-cache rooms-joined
↴admin query room-state-cache rooms-left
↴admin query room-state-cache rooms-invited
↴admin query room-state-cache invite-state
↴admin query room-timeline
↴admin query room-timeline pdus
↴admin query room-timeline last
↴admin query globals
↴admin query globals database-version
↴admin query globals current-count
↴admin query globals last-check-for-announcements-id
↴admin query globals signing-keys-for
↴admin query sending
↴admin query sending active-requests
↴admin query sending active-requests-for
↴admin query sending queued-requests
↴admin query sending get-latest-edu-count
↴admin query users
↴admin query users count-users
↴admin query users iter-users
↴admin query users iter-users2
↴admin query users password-hash
↴admin query users list-devices
↴admin query users list-devices-metadata
↴admin query users get-device-metadata
↴admin query users get-devices-version
↴admin query users count-one-time-keys
↴admin query users get-device-keys
↴admin query users get-user-signing-key
↴admin query users get-master-key
↴admin query users get-to-device-events
↴admin query users get-latest-backup
↴admin query users get-latest-backup-version
↴admin query users get-backup-algorithm
↴admin query users get-all-backups
↴admin query users get-room-backups
↴admin query users get-backup-session
↴admin query users get-shared-rooms
↴admin query resolver
↴admin query resolver destinations-cache
↴admin query resolver overrides-cache
↴admin query pusher
↴admin query pusher get-pushers
↴admin query short
↴admin query short short-event-id
↴admin query short short-room-id
↴admin query raw
↴admin query raw raw-maps
↴admin query raw raw-get
↴admin query raw raw-del
↴admin query raw raw-keys
↴admin query raw raw-keys-sizes
↴admin query raw raw-keys-total
↴admin query raw raw-vals-sizes
↴admin query raw raw-vals-total
↴admin query raw raw-iter
↴admin query raw raw-keys-from
↴admin query raw raw-iter-from
↴admin query raw raw-count
↴admin query raw compact
↴
admin
Usage: admin <COMMAND>
Subcommands:
appservices
— - Commands for managing appservicesusers
— - Commands for managing local usersrooms
— - Commands for managing roomsfederation
— - Commands for managing federationserver
— - Commands for managing the servermedia
— - Commands for managing mediacheck
— - Commands for checking integritydebug
— - Commands for debugging thingsquery
— - Low-level queries for database getters and iterators
admin appservices
- Commands for managing appservices
Usage: admin appservices <COMMAND>
Subcommands:
register
— - Register an appservice using its registration YAMLunregister
— - Unregister an appservice using its IDshow-appservice-config
— - Show an appservice's config using its IDlist-registered
— - List all the currently registered appservices
admin appservices register
- Register an appservice using its registration YAML
This command needs a YAML generated by an appservice (such as a bridge), which must be provided in a Markdown code block below the command.
Registering a new bridge using the ID of an existing bridge will replace the old one.
Usage: admin appservices register
admin appservices unregister
- Unregister an appservice using its ID
You can find the ID using the list-appservices
command.
Usage: admin appservices unregister <APPSERVICE_IDENTIFIER>
Arguments:
<APPSERVICE_IDENTIFIER>
— The appservice to unregister
admin appservices show-appservice-config
- Show an appservice's config using its ID
You can find the ID using the list-appservices
command.
Usage: admin appservices show-appservice-config <APPSERVICE_IDENTIFIER>
Arguments:
<APPSERVICE_IDENTIFIER>
— The appservice to show
admin appservices list-registered
- List all the currently registered appservices
Usage: admin appservices list-registered
admin users
- Commands for managing local users
Usage: admin users <COMMAND>
Subcommands:
create-user
— - Create a new userreset-password
— - Reset user passworddeactivate
— - Deactivate a userdeactivate-all
— - Deactivate a list of userssuspend
— - Suspend a userunsuspend
— - Unsuspend a userlist-users
— - List local users in the databaselist-joined-rooms
— - Lists all the rooms (local and remote) that the specified user is joined inforce-join-room
— - Manually join a local user to a roomforce-leave-room
— - Manually leave a local user from a roomforce-demote
— - Forces the specified user to drop their power levels to the room default, if their permissions allow and the auth check permitsmake-user-admin
— - Grant server-admin privileges to a userput-room-tag
— - Puts a room tag for the specified user and room IDdelete-room-tag
— - Deletes the room tag for the specified user and room IDget-room-tags
— - Gets all the room tags for the specified user and room IDredact-event
— - Attempts to forcefully redact the specified event ID from the sender userforce-join-list-of-local-users
— - Force joins a specified list of local users to join the specified roomforce-join-all-local-users
— - Force joins all local users to the specified room
admin users create-user
- Create a new user
Usage: admin users create-user <USERNAME> [PASSWORD]
Arguments:
<USERNAME>
— Username of the new user<PASSWORD>
— Password of the new user, if unspecified one is generated
admin users reset-password
- Reset user password
Usage: admin users reset-password <USERNAME> [PASSWORD]
Arguments:
<USERNAME>
— Username of the user for whom the password should be reset<PASSWORD>
— New password for the user, if unspecified one is generated
admin users deactivate
- Deactivate a user
User will be removed from all rooms by default. Use --no-leave-rooms to not leave all rooms by default.
Usage: admin users deactivate [OPTIONS] <USER_ID>
Arguments:
<USER_ID>
Options:
-n
,--no-leave-rooms
admin users deactivate-all
- Deactivate a list of users
Recommended to use in conjunction with list-local-users.
Users will be removed from joined rooms by default.
Can be overridden with --no-leave-rooms.
Removing a mass amount of users from a room may cause a significant amount of leave events. The time to leave rooms may depend significantly on joined rooms and servers.
This command needs a newline separated list of users provided in a Markdown code block below the command.
Usage: admin users deactivate-all [OPTIONS]
Options:
-n
,--no-leave-rooms
— Does not leave any rooms the user is in on deactivation-f
,--force
— Also deactivate admin accounts and will assume leave all rooms too
admin users suspend
- Suspend a user
Suspended users are able to log in, sync, and read messages, but are not able to send events nor redact them, cannot change their profile, and are unable to join, invite to, or knock on rooms.
Suspended users can still leave rooms and deactivate their account. Suspending them effectively makes them read-only.
Usage: admin users suspend <USER_ID>
Arguments:
<USER_ID>
— Username of the user to suspend
admin users unsuspend
- Unsuspend a user
Reverses the effects of the suspend
command, allowing the user to send messages, change their profile, create room invites, etc.
Usage: admin users unsuspend <USER_ID>
Arguments:
<USER_ID>
— Username of the user to unsuspend
admin users list-users
- List local users in the database
Usage: admin users list-users
admin users list-joined-rooms
- Lists all the rooms (local and remote) that the specified user is joined in
Usage: admin users list-joined-rooms <USER_ID>
Arguments:
<USER_ID>
admin users force-join-room
- Manually join a local user to a room
Usage: admin users force-join-room <USER_ID> <ROOM_ID>
Arguments:
<USER_ID>
<ROOM_ID>
admin users force-leave-room
- Manually leave a local user from a room
Usage: admin users force-leave-room <USER_ID> <ROOM_ID>
Arguments:
<USER_ID>
<ROOM_ID>
admin users force-demote
- Forces the specified user to drop their power levels to the room default, if their permissions allow and the auth check permits
Usage: admin users force-demote <USER_ID> <ROOM_ID>
Arguments:
<USER_ID>
<ROOM_ID>
admin users make-user-admin
- Grant server-admin privileges to a user
Usage: admin users make-user-admin <USER_ID>
Arguments:
<USER_ID>
admin users put-room-tag
- Puts a room tag for the specified user and room ID.
This is primarily useful if you'd like to set your admin room to the special "System Alerts" section in Element as a way to permanently see your admin room without it being buried away in your favourites or rooms. To do this, you would pass your user, your admin room's internal ID, and the tag name m.server_notice
.
Usage: admin users put-room-tag <USER_ID> <ROOM_ID> <TAG>
Arguments:
<USER_ID>
<ROOM_ID>
<TAG>
admin users delete-room-tag
- Deletes the room tag for the specified user and room ID
Usage: admin users delete-room-tag <USER_ID> <ROOM_ID> <TAG>
Arguments:
<USER_ID>
<ROOM_ID>
<TAG>
admin users get-room-tags
- Gets all the room tags for the specified user and room ID
Usage: admin users get-room-tags <USER_ID> <ROOM_ID>
Arguments:
<USER_ID>
<ROOM_ID>
admin users redact-event
- Attempts to forcefully redact the specified event ID from the sender user
This is only valid for local users
Usage: admin users redact-event <EVENT_ID>
Arguments:
<EVENT_ID>
admin users force-join-list-of-local-users
- Force joins a specified list of local users to join the specified room.
Specify a codeblock of usernames.
At least 1 server admin must be in the room to reduce abuse.
Requires the --yes-i-want-to-do-this
flag.
Usage: admin users force-join-list-of-local-users [OPTIONS] <ROOM_ID>
Arguments:
<ROOM_ID>
Options:
--yes-i-want-to-do-this
admin users force-join-all-local-users
- Force joins all local users to the specified room.
At least 1 server admin must be in the room to reduce abuse.
Requires the --yes-i-want-to-do-this
flag.
Usage: admin users force-join-all-local-users [OPTIONS] <ROOM_ID>
Arguments:
<ROOM_ID>
Options:
--yes-i-want-to-do-this
admin rooms
- Commands for managing rooms
Usage: admin rooms <COMMAND>
Subcommands:
list-rooms
— - List all rooms the server knows aboutinfo
— - View information about a room we know aboutmoderation
— - Manage moderation of remote or local roomsalias
— - Manage rooms' aliasesdirectory
— - Manage the room directoryexists
— - Check if we know about a room
admin rooms list-rooms
- List all rooms the server knows about
Usage: admin rooms list-rooms [OPTIONS] [PAGE]
Arguments:
<PAGE>
Options:
--exclude-disabled
— Excludes rooms that we have federation disabled with--exclude-banned
— Excludes rooms that we have banned--no-details
— Whether to only output room IDs without supplementary room information
admin rooms info
- View information about a room we know about
Usage: admin rooms info <COMMAND>
Subcommands:
list-joined-members
— - List joined members in a roomview-room-topic
— - Displays room topic
admin rooms info list-joined-members
- List joined members in a room
Usage: admin rooms info list-joined-members [OPTIONS] <ROOM_ID>
Arguments:
<ROOM_ID>
Options:
--local-only
— Lists only our local users in the specified room
admin rooms info view-room-topic
- Displays room topic
Room topics can be huge, so this is in its own separate command
Usage: admin rooms info view-room-topic <ROOM_ID>
Arguments:
<ROOM_ID>
admin rooms moderation
- Manage moderation of remote or local rooms
Usage: admin rooms moderation <COMMAND>
Subcommands:
ban-room
— - Bans a room from local users joining and evicts all our local users (including server admins) from the room. Also blocks any invites (local and remote) for the banned room, and disables federation entirely with itban-list-of-rooms
— - Bans a list of rooms (room IDs and room aliases) from a newline delimited codeblock similar touser deactivate-all
. Applies the same steps as ban-roomunban-room
— - Unbans a room to allow local users to join againlist-banned-rooms
— - List of all rooms we have banned
admin rooms moderation ban-room
- Bans a room from local users joining and evicts all our local users (including server admins) from the room. Also blocks any invites (local and remote) for the banned room, and disables federation entirely with it
Usage: admin rooms moderation ban-room <ROOM>
Arguments:
<ROOM>
— The room in the format of!roomid:example.com
or a room alias in the format of#roomalias:example.com
admin rooms moderation ban-list-of-rooms
- Bans a list of rooms (room IDs and room aliases) from a newline delimited codeblock similar to
user deactivate-all
. Applies the same steps as ban-room
Usage: admin rooms moderation ban-list-of-rooms
admin rooms moderation unban-room
- Unbans a room to allow local users to join again
Usage: admin rooms moderation unban-room <ROOM>
Arguments:
<ROOM>
— The room in the format of!roomid:example.com
or a room alias in the format of#roomalias:example.com
admin rooms moderation list-banned-rooms
- List of all rooms we have banned
Usage: admin rooms moderation list-banned-rooms [OPTIONS]
Options:
--no-details
— Whether to only output room IDs without supplementary room information
admin rooms alias
- Manage rooms' aliases
Usage: admin rooms alias <COMMAND>
Subcommands:
set
— - Make an alias point to a roomremove
— - Remove a local aliaswhich
— - Show which room is using an aliaslist
— - List aliases currently being used
admin rooms alias set
- Make an alias point to a room
Usage: admin rooms alias set [OPTIONS] <ROOM_ID> <ROOM_ALIAS_LOCALPART>
Arguments:
<ROOM_ID>
— The room id to set the alias on<ROOM_ALIAS_LOCALPART>
— The alias localpart to use (alias
, not#alias:servername.tld
)
Options:
-f
,--force
— Set the alias even if a room is already using it
admin rooms alias remove
- Remove a local alias
Usage: admin rooms alias remove <ROOM_ALIAS_LOCALPART>
Arguments:
<ROOM_ALIAS_LOCALPART>
— The alias localpart to remove (alias
, not#alias:servername.tld
)
admin rooms alias which
- Show which room is using an alias
Usage: admin rooms alias which <ROOM_ALIAS_LOCALPART>
Arguments:
<ROOM_ALIAS_LOCALPART>
— The alias localpart to look up (alias
, not#alias:servername.tld
)
admin rooms alias list
- List aliases currently being used
Usage: admin rooms alias list [ROOM_ID]
Arguments:
<ROOM_ID>
— If set, only list the aliases for this room
admin rooms directory
- Manage the room directory
Usage: admin rooms directory <COMMAND>
Subcommands:
publish
— - Publish a room to the room directoryunpublish
— - Unpublish a room to the room directorylist
— - List rooms that are published
admin rooms directory publish
- Publish a room to the room directory
Usage: admin rooms directory publish <ROOM_ID>
Arguments:
<ROOM_ID>
— The room id of the room to publish
admin rooms directory unpublish
- Unpublish a room to the room directory
Usage: admin rooms directory unpublish <ROOM_ID>
Arguments:
<ROOM_ID>
— The room id of the room to unpublish
admin rooms directory list
- List rooms that are published
Usage: admin rooms directory list [PAGE]
Arguments:
<PAGE>
admin rooms exists
- Check if we know about a room
Usage: admin rooms exists <ROOM_ID>
Arguments:
<ROOM_ID>
admin federation
- Commands for managing federation
Usage: admin federation <COMMAND>
Subcommands:
incoming-federation
— - List all rooms we are currently handling an incoming pdu fromdisable-room
— - Disables incoming federation handling for a roomenable-room
— - Enables incoming federation handling for a room againfetch-support-well-known
— - Fetch/.well-known/matrix/support
from the specified serverremote-user-in-rooms
— - Lists all the rooms we share/track with the specified remote user
admin federation incoming-federation
- List all rooms we are currently handling an incoming pdu from
Usage: admin federation incoming-federation
admin federation disable-room
- Disables incoming federation handling for a room
Usage: admin federation disable-room <ROOM_ID>
Arguments:
<ROOM_ID>
admin federation enable-room
- Enables incoming federation handling for a room again
Usage: admin federation enable-room <ROOM_ID>
Arguments:
<ROOM_ID>
admin federation fetch-support-well-known
- Fetch
/.well-known/matrix/support
from the specified server
Despite the name, this is not a federation endpoint and does not go through the federation / server resolution process as per-spec this is supposed to be served at the server_name.
Respecting homeservers put this file here for listing administration, moderation, and security inquiries. This command provides a way to easily fetch that information.
Usage: admin federation fetch-support-well-known <SERVER_NAME>
Arguments:
<SERVER_NAME>
admin federation remote-user-in-rooms
- Lists all the rooms we share/track with the specified remote user
Usage: admin federation remote-user-in-rooms <USER_ID>
Arguments:
<USER_ID>
admin server
- Commands for managing the server
Usage: admin server <COMMAND>
Subcommands:
uptime
— - Time elapsed since startupshow-config
— - Show configuration valuesreload-config
— - Reload configuration valueslist-features
— - List the features built into the servermemory-usage
— - Print database memory usage statisticsclear-caches
— - Clears all of Continuwuity's cachesbackup-database
— - Performs an online backup of the database (only available for RocksDB at the moment)list-backups
— - List database backupsadmin-notice
— - Send a message to the admin roomreload-mods
— - Hot-reload the serverrestart
— - Restart the servershutdown
— - Shutdown the server
admin server uptime
- Time elapsed since startup
Usage: admin server uptime
admin server show-config
- Show configuration values
Usage: admin server show-config
admin server reload-config
- Reload configuration values
Usage: admin server reload-config [PATH]
Arguments:
<PATH>
admin server list-features
- List the features built into the server
Usage: admin server list-features [OPTIONS]
Options:
-a
,--available
-e
,--enabled
-c
,--comma
admin server memory-usage
- Print database memory usage statistics
Usage: admin server memory-usage
admin server clear-caches
- Clears all of Continuwuity's caches
Usage: admin server clear-caches
admin server backup-database
- Performs an online backup of the database (only available for RocksDB at the moment)
Usage: admin server backup-database
admin server list-backups
- List database backups
Usage: admin server list-backups
admin server admin-notice
- Send a message to the admin room
Usage: admin server admin-notice [MESSAGE]...
Arguments:
<MESSAGE>
admin server reload-mods
- Hot-reload the server
Usage: admin server reload-mods
admin server restart
- Restart the server
Usage: admin server restart [OPTIONS]
Options:
-f
,--force
admin server shutdown
- Shutdown the server
Usage: admin server shutdown
admin media
- Commands for managing media
Usage: admin media <COMMAND>
Subcommands:
delete
— - Deletes a single media file from our database and on the filesystem via a single MXC URL or event ID (not redacted)delete-list
— - Deletes a codeblock list of MXC URLs from our database and on the filesystem. This will always ignore errorsdelete-past-remote-media
— - Deletes all remote (and optionally local) media created before or after [duration] time using filesystem metadata first created at date, or fallback to last modified date. This will always ignore errors by defaultdelete-all-from-user
— - Deletes all the local media from a local user on our server. This will always ignore errors by defaultdelete-all-from-server
— - Deletes all remote media from the specified remote server. This will always ignore errors by defaultget-file-info
—get-remote-file
—get-remote-thumbnail
—
admin media delete
- Deletes a single media file from our database and on the filesystem via a single MXC URL or event ID (not redacted)
Usage: admin media delete [OPTIONS]
Options:
--mxc <MXC>
— The MXC URL to delete--event-id <EVENT_ID>
— - The message event ID which contains the media and thumbnail MXC URLs
admin media delete-list
- Deletes a codeblock list of MXC URLs from our database and on the filesystem. This will always ignore errors
Usage: admin media delete-list
admin media delete-past-remote-media
- Deletes all remote (and optionally local) media created before or after [duration] time using filesystem metadata first created at date, or fallback to last modified date. This will always ignore errors by default
Usage: admin media delete-past-remote-media [OPTIONS] <DURATION>
Arguments:
<DURATION>
— - The relative time (e.g. 30s, 5m, 7d) within which to search
Options:
-b
,--before
— - Only delete media created before [duration] ago-a
,--after
— - Only delete media created after [duration] ago--yes-i-want-to-delete-local-media
— - Long argument to additionally delete local media
admin media delete-all-from-user
- Deletes all the local media from a local user on our server. This will always ignore errors by default
Usage: admin media delete-all-from-user <USERNAME>
Arguments:
<USERNAME>
admin media delete-all-from-server
- Deletes all remote media from the specified remote server. This will always ignore errors by default
Usage: admin media delete-all-from-server [OPTIONS] <SERVER_NAME>
Arguments:
<SERVER_NAME>
Options:
--yes-i-want-to-delete-local-media
— Long argument to delete local media
admin media get-file-info
Usage: admin media get-file-info <MXC>
Arguments:
<MXC>
— The MXC URL to lookup info for
admin media get-remote-file
Usage: admin media get-remote-file [OPTIONS] <MXC>
Arguments:
<MXC>
— The MXC URL to fetch
Options:
-
-s
,--server <SERVER>
-
-t
,--timeout <TIMEOUT>
Default value:
10000
admin media get-remote-thumbnail
Usage: admin media get-remote-thumbnail [OPTIONS] <MXC>
Arguments:
<MXC>
— The MXC URL to fetch
Options:
-
-s
,--server <SERVER>
-
-t
,--timeout <TIMEOUT>
Default value:
10000
-
--width <WIDTH>
Default value:
800
-
--height <HEIGHT>
Default value:
800
admin check
- Commands for checking integrity
Usage: admin check <COMMAND>
Subcommands:
check-all-users
—
admin check check-all-users
Usage: admin check check-all-users
admin debug
- Commands for debugging things
Usage: admin debug <COMMAND>
Subcommands:
echo
— - Echo input of admin commandget-auth-chain
— - Get the auth_chain of a PDUparse-pdu
— - Parse and print a PDU from a JSONget-pdu
— - Retrieve and print a PDU by EventID from the Continuwuity databaseget-short-pdu
— - Retrieve and print a PDU by PduId from the Continuwuity databaseget-remote-pdu
— - Attempts to retrieve a PDU from a remote server. Inserts it into our database/timeline if found and we do not have this PDU already (following normal event auth rules, handles it as an incoming PDU)get-remote-pdu-list
— - Same asget-remote-pdu
but accepts a codeblock newline delimited list of PDUs and a single server to fetch fromget-room-state
— - Gets all the room state events for the specified roomget-signing-keys
— - Get and display signing keys from local cache or remote serverget-verify-keys
— - Get and display signing keys from local cache or remote serverping
— - Sends a federation request to the remote server's/_matrix/federation/v1/version
endpoint and measures the latency it took for the server to respondforce-device-list-updates
— - Forces device lists for all local and remote users to be updated (as having new keys available)change-log-level
— - Change tracing log level/filter on the flysign-json
— - Sign JSON blobverify-json
— - Verify JSON signaturesverify-pdu
— - Verify PDUfirst-pdu-in-room
— - Prints the very first PDU in the specified room (typically m.room.create)latest-pdu-in-room
— - Prints the latest ("last") PDU in the specified room (typically a message)force-set-room-state-from-server
— - Forcefully replaces the room state of our local copy of the specified room, with the copy (auth chain and room state events) the specified remote server saysresolve-true-destination
— - Runs a server name through Continuwuity's true destination resolution processmemory-stats
— - Print extended memory usageruntime-metrics
— - Print general tokio runtime metric totalsruntime-interval
— - Print detailed tokio runtime metrics accumulated since last command invocationtime
— - Print the current timelist-dependencies
— - List dependenciesdatabase-stats
— - Get database statisticstrim-memory
— - Trim memory usagedatabase-files
— - List database files
admin debug echo
- Echo input of admin command
Usage: admin debug echo [MESSAGE]...
Arguments:
<MESSAGE>
admin debug get-auth-chain
- Get the auth_chain of a PDU
Usage: admin debug get-auth-chain <EVENT_ID>
Arguments:
<EVENT_ID>
— An event ID (the $ character followed by the base64 reference hash)
admin debug parse-pdu
- Parse and print a PDU from a JSON
The PDU event is only checked for validity and is not added to the database.
This command needs a JSON blob provided in a Markdown code block below the command.
Usage: admin debug parse-pdu
admin debug get-pdu
- Retrieve and print a PDU by EventID from the Continuwuity database
Usage: admin debug get-pdu <EVENT_ID>
Arguments:
<EVENT_ID>
— An event ID (a $ followed by the base64 reference hash)
admin debug get-short-pdu
- Retrieve and print a PDU by PduId from the Continuwuity database
Usage: admin debug get-short-pdu <SHORTROOMID> <SHORTEVENTID>
Arguments:
<SHORTROOMID>
— Shortroomid integer<SHORTEVENTID>
— Shorteventid integer
admin debug get-remote-pdu
- Attempts to retrieve a PDU from a remote server. Inserts it into our database/timeline if found and we do not have this PDU already (following normal event auth rules, handles it as an incoming PDU)
Usage: admin debug get-remote-pdu <EVENT_ID> <SERVER>
Arguments:
<EVENT_ID>
— An event ID (a $ followed by the base64 reference hash)<SERVER>
— Argument for us to attempt to fetch the event from the specified remote server
admin debug get-remote-pdu-list
- Same as
get-remote-pdu
but accepts a codeblock newline delimited list of PDUs and a single server to fetch from
Usage: admin debug get-remote-pdu-list [OPTIONS] <SERVER>
Arguments:
<SERVER>
— Argument for us to attempt to fetch all the events from the specified remote server
Options:
-f
,--force
— If set, ignores errors, else stops at the first error/failure
admin debug get-room-state
- Gets all the room state events for the specified room.
This is functionally equivalent to GET /_matrix/client/v3/rooms/{roomid}/state
, except the admin command does not check if the sender user is allowed to see state events. This is done because it's implied that server admins here have database access and can see/get room info themselves anyways if they were malicious admins.
Of course the check is still done on the actual client API.
Usage: admin debug get-room-state <ROOM_ID>
Arguments:
<ROOM_ID>
— Room ID
admin debug get-signing-keys
- Get and display signing keys from local cache or remote server
Usage: admin debug get-signing-keys [OPTIONS] [SERVER_NAME]
Arguments:
<SERVER_NAME>
Options:
--notary <NOTARY>
-q
,--query
admin debug get-verify-keys
- Get and display signing keys from local cache or remote server
Usage: admin debug get-verify-keys [SERVER_NAME]
Arguments:
<SERVER_NAME>
admin debug ping
- Sends a federation request to the remote server's
/_matrix/federation/v1/version
endpoint and measures the latency it took for the server to respond
Usage: admin debug ping <SERVER>
Arguments:
<SERVER>
admin debug force-device-list-updates
- Forces device lists for all local and remote users to be updated (as having new keys available)
Usage: admin debug force-device-list-updates
admin debug change-log-level
- Change tracing log level/filter on the fly
This accepts the same format as the log
config option.
Usage: admin debug change-log-level [OPTIONS] [FILTER]
Arguments:
<FILTER>
— Log level/filter
Options:
-r
,--reset
— Resets the log level/filter to the one in your config
admin debug sign-json
- Sign JSON blob
This command needs a JSON blob provided in a Markdown code block below the command.
Usage: admin debug sign-json
admin debug verify-json
- Verify JSON signatures
This command needs a JSON blob provided in a Markdown code block below the command.
Usage: admin debug verify-json
admin debug verify-pdu
- Verify PDU
This re-verifies a PDU existing in the database found by ID.
Usage: admin debug verify-pdu <EVENT_ID>
Arguments:
<EVENT_ID>
admin debug first-pdu-in-room
- Prints the very first PDU in the specified room (typically m.room.create)
Usage: admin debug first-pdu-in-room <ROOM_ID>
Arguments:
<ROOM_ID>
— The room ID
admin debug latest-pdu-in-room
- Prints the latest ("last") PDU in the specified room (typically a message)
Usage: admin debug latest-pdu-in-room <ROOM_ID>
Arguments:
<ROOM_ID>
— The room ID
admin debug force-set-room-state-from-server
- Forcefully replaces the room state of our local copy of the specified room, with the copy (auth chain and room state events) the specified remote server says.
A common desire for room deletion is to simply "reset" our copy of the room. While this admin command is not a replacement for that, if you know you have split/broken room state and you know another server in the room that has the best/working room state, this command can let you use their room state. Such example is your server saying users are in a room, but other servers are saying they're not in the room in question.
This command will get the latest PDU in the room we know about, and request the room state at that point in time via /_matrix/federation/v1/state/{roomId}
.
Usage: admin debug force-set-room-state-from-server <ROOM_ID> <SERVER_NAME> [EVENT_ID]
Arguments:
<ROOM_ID>
— The impacted room ID<SERVER_NAME>
— The server we will use to query the room state for<EVENT_ID>
— The event ID of the latest known PDU in the room. Will be found automatically if not provided
admin debug resolve-true-destination
- Runs a server name through Continuwuity's true destination resolution process
Useful for debugging well-known issues
Usage: admin debug resolve-true-destination [OPTIONS] <SERVER_NAME>
Arguments:
<SERVER_NAME>
Options:
-n
,--no-cache
admin debug memory-stats
- Print extended memory usage
Optional argument is a character mask (a sequence of characters in any order) which enable additional extended statistics. Known characters are "abdeglmx". For convenience, a '*' will enable everything.
Usage: admin debug memory-stats [OPTS]
Arguments:
<OPTS>
admin debug runtime-metrics
- Print general tokio runtime metric totals
Usage: admin debug runtime-metrics
admin debug runtime-interval
- Print detailed tokio runtime metrics accumulated since last command invocation
Usage: admin debug runtime-interval
admin debug time
- Print the current time
Usage: admin debug time
admin debug list-dependencies
- List dependencies
Usage: admin debug list-dependencies [OPTIONS]
Options:
-n
,--names
admin debug database-stats
- Get database statistics
Usage: admin debug database-stats [OPTIONS] [PROPERTY]
Arguments:
<PROPERTY>
Options:
-m
,--map <MAP>
admin debug trim-memory
- Trim memory usage
Usage: admin debug trim-memory
admin debug database-files
- List database files
Usage: admin debug database-files [OPTIONS] [MAP]
Arguments:
<MAP>
Options:
--level <LEVEL>
admin query
- Low-level queries for database getters and iterators
Usage: admin query <COMMAND>
Subcommands:
account-data
— - account_data.rs iterators and gettersappservice
— - appservice.rs iterators and getterspresence
— - presence.rs iterators and gettersroom-alias
— - rooms/alias.rs iterators and gettersroom-state-cache
— - rooms/state_cache iterators and gettersroom-timeline
— - rooms/timeline iterators and gettersglobals
— - globals.rs iterators and getterssending
— - sending.rs iterators and gettersusers
— - users.rs iterators and gettersresolver
— - resolver servicepusher
— - pusher serviceshort
— - short serviceraw
— - raw service
admin query account-data
- account_data.rs iterators and getters
Usage: admin query account-data <COMMAND>
Subcommands:
changes-since
— - Returns all changes to the account data that happened aftersince
account-data-get
— - Searches the account data for a specific kind
admin query account-data changes-since
- Returns all changes to the account data that happened after
since
Usage: admin query account-data changes-since <USER_ID> <SINCE> [ROOM_ID]
Arguments:
<USER_ID>
— Full user ID<SINCE>
— UNIX timestamp since (u64)<ROOM_ID>
— Optional room ID of the account data
admin query account-data account-data-get
- Searches the account data for a specific kind
Usage: admin query account-data account-data-get <USER_ID> <KIND> [ROOM_ID]
Arguments:
<USER_ID>
— Full user ID<KIND>
— Account data event type<ROOM_ID>
— Optional room ID of the account data
admin query appservice
- appservice.rs iterators and getters
Usage: admin query appservice <COMMAND>
Subcommands:
get-registration
— - Gets the appservice registration info/details from the ID as a stringall
— - Gets all appservice registrations with their ID and registration info
admin query appservice get-registration
- Gets the appservice registration info/details from the ID as a string
Usage: admin query appservice get-registration <APPSERVICE_ID>
Arguments:
<APPSERVICE_ID>
— Appservice registration ID
admin query appservice all
- Gets all appservice registrations with their ID and registration info
Usage: admin query appservice all
admin query presence
- presence.rs iterators and getters
Usage: admin query presence <COMMAND>
Subcommands:
get-presence
— - Returns the latest presence event for the given userpresence-since
— - Iterator of the most recent presence updates that happened after the event with idsince
admin query presence get-presence
- Returns the latest presence event for the given user
Usage: admin query presence get-presence <USER_ID>
Arguments:
<USER_ID>
— Full user ID
admin query presence presence-since
- Iterator of the most recent presence updates that happened after the event with id
since
Usage: admin query presence presence-since <SINCE>
Arguments:
<SINCE>
— UNIX timestamp since (u64)
admin query room-alias
- rooms/alias.rs iterators and getters
Usage: admin query room-alias <COMMAND>
Subcommands:
resolve-local-alias
—local-aliases-for-room
— - Iterator of all our local room aliases for the room IDall-local-aliases
— - Iterator of all our local aliases in our database with their room IDs
admin query room-alias resolve-local-alias
Usage: admin query room-alias resolve-local-alias <ALIAS>
Arguments:
<ALIAS>
— Full room alias
admin query room-alias local-aliases-for-room
- Iterator of all our local room aliases for the room ID
Usage: admin query room-alias local-aliases-for-room <ROOM_ID>
Arguments:
<ROOM_ID>
— Full room ID
admin query room-alias all-local-aliases
- Iterator of all our local aliases in our database with their room IDs
Usage: admin query room-alias all-local-aliases
admin query room-state-cache
- rooms/state_cache iterators and getters
Usage: admin query room-state-cache <COMMAND>
Subcommands:
server-in-room
—room-servers
—server-rooms
—room-members
—local-users-in-room
—active-local-users-in-room
—room-joined-count
—room-invited-count
—room-user-once-joined
—room-members-invited
—get-invite-count
—get-left-count
—rooms-joined
—rooms-left
—rooms-invited
—invite-state
—
admin query room-state-cache server-in-room
Usage: admin query room-state-cache server-in-room <SERVER> <ROOM_ID>
Arguments:
<SERVER>
<ROOM_ID>
admin query room-state-cache room-servers
Usage: admin query room-state-cache room-servers <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache server-rooms
Usage: admin query room-state-cache server-rooms <SERVER>
Arguments:
<SERVER>
admin query room-state-cache room-members
Usage: admin query room-state-cache room-members <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache local-users-in-room
Usage: admin query room-state-cache local-users-in-room <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache active-local-users-in-room
Usage: admin query room-state-cache active-local-users-in-room <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache room-joined-count
Usage: admin query room-state-cache room-joined-count <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache room-invited-count
Usage: admin query room-state-cache room-invited-count <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache room-user-once-joined
Usage: admin query room-state-cache room-user-once-joined <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache room-members-invited
Usage: admin query room-state-cache room-members-invited <ROOM_ID>
Arguments:
<ROOM_ID>
admin query room-state-cache get-invite-count
Usage: admin query room-state-cache get-invite-count <ROOM_ID> <USER_ID>
Arguments:
<ROOM_ID>
<USER_ID>
admin query room-state-cache get-left-count
Usage: admin query room-state-cache get-left-count <ROOM_ID> <USER_ID>
Arguments:
<ROOM_ID>
<USER_ID>
admin query room-state-cache rooms-joined
Usage: admin query room-state-cache rooms-joined <USER_ID>
Arguments:
<USER_ID>
admin query room-state-cache rooms-left
Usage: admin query room-state-cache rooms-left <USER_ID>
Arguments:
<USER_ID>
admin query room-state-cache rooms-invited
Usage: admin query room-state-cache rooms-invited <USER_ID>
Arguments:
<USER_ID>
admin query room-state-cache invite-state
Usage: admin query room-state-cache invite-state <USER_ID> <ROOM_ID>
Arguments:
<USER_ID>
<ROOM_ID>
admin query room-timeline
- rooms/timeline iterators and getters
Usage: admin query room-timeline <COMMAND>
Subcommands:
pdus
—last
—
admin query room-timeline pdus
Usage: admin query room-timeline pdus [OPTIONS] <ROOM_ID> [FROM]
Arguments:
<ROOM_ID>
<FROM>
Options:
-l
,--limit <LIMIT>
admin query room-timeline last
Usage: admin query room-timeline last <ROOM_ID>
Arguments:
<ROOM_ID>
admin query globals
- globals.rs iterators and getters
Usage: admin query globals <COMMAND>
Subcommands:
database-version
—current-count
—last-check-for-announcements-id
—signing-keys-for
— - This returns an emptyOk(BTreeMap<..>)
when there are no keys found for the server
admin query globals database-version
Usage: admin query globals database-version
admin query globals current-count
Usage: admin query globals current-count
admin query globals last-check-for-announcements-id
Usage: admin query globals last-check-for-announcements-id
admin query globals signing-keys-for
- This returns an empty
Ok(BTreeMap<..>)
when there are no keys found for the server
Usage: admin query globals signing-keys-for <ORIGIN>
Arguments:
<ORIGIN>
admin query sending
- sending.rs iterators and getters
Usage: admin query sending <COMMAND>
Subcommands:
active-requests
— - Queries database for allservercurrentevent_data
active-requests-for
— - Queries database forservercurrentevent_data
but for a specific destinationqueued-requests
— - Queries database forservernameevent_data
which are the queued up requests that will eventually be sentget-latest-edu-count
—
admin query sending active-requests
- Queries database for all
servercurrentevent_data
Usage: admin query sending active-requests
admin query sending active-requests-for
- Queries database for
servercurrentevent_data
but for a specific destination
This command takes only one format of these arguments:
appservice_id server_name user_id AND push_key
See src/service/sending/mod.rs for the definition of the Destination
enum
Usage: admin query sending active-requests-for [OPTIONS]
Options:
-a
,--appservice-id <APPSERVICE_ID>
-s
,--server-name <SERVER_NAME>
-u
,--user-id <USER_ID>
-p
,--push-key <PUSH_KEY>
admin query sending queued-requests
- Queries database for
servernameevent_data
which are the queued up requests that will eventually be sent
This command takes only one format of these arguments:
appservice_id server_name user_id AND push_key
See src/service/sending/mod.rs for the definition of the Destination
enum
Usage: admin query sending queued-requests [OPTIONS]
Options:
-a
,--appservice-id <APPSERVICE_ID>
-s
,--server-name <SERVER_NAME>
-u
,--user-id <USER_ID>
-p
,--push-key <PUSH_KEY>
admin query sending get-latest-edu-count
Usage: admin query sending get-latest-edu-count <SERVER_NAME>
Arguments:
<SERVER_NAME>
admin query users
- users.rs iterators and getters
Usage: admin query users <COMMAND>
Subcommands:
count-users
—iter-users
—iter-users2
—password-hash
—list-devices
—list-devices-metadata
—get-device-metadata
—get-devices-version
—count-one-time-keys
—get-device-keys
—get-user-signing-key
—get-master-key
—get-to-device-events
—get-latest-backup
—get-latest-backup-version
—get-backup-algorithm
—get-all-backups
—get-room-backups
—get-backup-session
—get-shared-rooms
—
admin query users count-users
Usage: admin query users count-users
admin query users iter-users
Usage: admin query users iter-users
admin query users iter-users2
Usage: admin query users iter-users2
admin query users password-hash
Usage: admin query users password-hash <USER_ID>
Arguments:
<USER_ID>
admin query users list-devices
Usage: admin query users list-devices <USER_ID>
Arguments:
<USER_ID>
admin query users list-devices-metadata
Usage: admin query users list-devices-metadata <USER_ID>
Arguments:
<USER_ID>
admin query users get-device-metadata
Usage: admin query users get-device-metadata <USER_ID> <DEVICE_ID>
Arguments:
<USER_ID>
<DEVICE_ID>
admin query users get-devices-version
Usage: admin query users get-devices-version <USER_ID>
Arguments:
<USER_ID>
admin query users count-one-time-keys
Usage: admin query users count-one-time-keys <USER_ID> <DEVICE_ID>
Arguments:
<USER_ID>
<DEVICE_ID>
admin query users get-device-keys
Usage: admin query users get-device-keys <USER_ID> <DEVICE_ID>
Arguments:
<USER_ID>
<DEVICE_ID>
admin query users get-user-signing-key
Usage: admin query users get-user-signing-key <USER_ID>
Arguments:
<USER_ID>
admin query users get-master-key
Usage: admin query users get-master-key <USER_ID>
Arguments:
<USER_ID>
admin query users get-to-device-events
Usage: admin query users get-to-device-events <USER_ID> <DEVICE_ID>
Arguments:
<USER_ID>
<DEVICE_ID>
admin query users get-latest-backup
Usage: admin query users get-latest-backup <USER_ID>
Arguments:
<USER_ID>
admin query users get-latest-backup-version
Usage: admin query users get-latest-backup-version <USER_ID>
Arguments:
<USER_ID>
admin query users get-backup-algorithm
Usage: admin query users get-backup-algorithm <USER_ID> <VERSION>
Arguments:
<USER_ID>
<VERSION>
admin query users get-all-backups
Usage: admin query users get-all-backups <USER_ID> <VERSION>
Arguments:
<USER_ID>
<VERSION>
admin query users get-room-backups
Usage: admin query users get-room-backups <USER_ID> <VERSION> <ROOM_ID>
Arguments:
<USER_ID>
<VERSION>
<ROOM_ID>
admin query users get-backup-session
Usage: admin query users get-backup-session <USER_ID> <VERSION> <ROOM_ID> <SESSION_ID>
Arguments:
<USER_ID>
<VERSION>
<ROOM_ID>
<SESSION_ID>
admin query users get-shared-rooms
Usage: admin query users get-shared-rooms <USER_A> <USER_B>
Arguments:
<USER_A>
<USER_B>
admin query resolver
- resolver service
Usage: admin query resolver <COMMAND>
Subcommands:
destinations-cache
— Query the destinations cacheoverrides-cache
— Query the overrides cache
admin query resolver destinations-cache
Query the destinations cache
Usage: admin query resolver destinations-cache [SERVER_NAME]
Arguments:
<SERVER_NAME>
admin query resolver overrides-cache
Query the overrides cache
Usage: admin query resolver overrides-cache [NAME]
Arguments:
<NAME>
admin query pusher
- pusher service
Usage: admin query pusher <COMMAND>
Subcommands:
get-pushers
— - Returns all the pushers for the user
admin query pusher get-pushers
- Returns all the pushers for the user
Usage: admin query pusher get-pushers <USER_ID>
Arguments:
<USER_ID>
— Full user ID
admin query short
- short service
Usage: admin query short <COMMAND>
Subcommands:
short-event-id
—short-room-id
—
admin query short short-event-id
Usage: admin query short short-event-id <EVENT_ID>
Arguments:
<EVENT_ID>
admin query short short-room-id
Usage: admin query short short-room-id <ROOM_ID>
Arguments:
<ROOM_ID>
admin query raw
- raw service
Usage: admin query raw <COMMAND>
Subcommands:
raw-maps
— - List database mapsraw-get
— - Raw database queryraw-del
— - Raw database delete (for string keys)raw-keys
— - Raw database keys iterationraw-keys-sizes
— - Raw database key size breakdownraw-keys-total
— - Raw database keys total bytesraw-vals-sizes
— - Raw database values size breakdownraw-vals-total
— - Raw database values total bytesraw-iter
— - Raw database items iterationraw-keys-from
— - Raw database keys iterationraw-iter-from
— - Raw database items iterationraw-count
— - Raw database record countcompact
— - Compact database
admin query raw raw-maps
- List database maps
Usage: admin query raw raw-maps
admin query raw raw-get
- Raw database query
Usage: admin query raw raw-get <MAP> <KEY>
Arguments:
<MAP>
— Map name<KEY>
— Key
admin query raw raw-del
- Raw database delete (for string keys)
Usage: admin query raw raw-del <MAP> <KEY>
Arguments:
<MAP>
— Map name<KEY>
— Key
admin query raw raw-keys
- Raw database keys iteration
Usage: admin query raw raw-keys <MAP> [PREFIX]
Arguments:
<MAP>
— Map name<PREFIX>
— Key prefix
admin query raw raw-keys-sizes
- Raw database key size breakdown
Usage: admin query raw raw-keys-sizes [MAP] [PREFIX]
Arguments:
<MAP>
— Map name<PREFIX>
— Key prefix
admin query raw raw-keys-total
- Raw database keys total bytes
Usage: admin query raw raw-keys-total [MAP] [PREFIX]
Arguments:
<MAP>
— Map name<PREFIX>
— Key prefix
admin query raw raw-vals-sizes
- Raw database values size breakdown
Usage: admin query raw raw-vals-sizes [MAP] [PREFIX]
Arguments:
<MAP>
— Map name<PREFIX>
— Key prefix
admin query raw raw-vals-total
- Raw database values total bytes
Usage: admin query raw raw-vals-total [MAP] [PREFIX]
Arguments:
<MAP>
— Map name<PREFIX>
— Key prefix
admin query raw raw-iter
- Raw database items iteration
Usage: admin query raw raw-iter <MAP> [PREFIX]
Arguments:
<MAP>
— Map name<PREFIX>
— Key prefix
admin query raw raw-keys-from
- Raw database keys iteration
Usage: admin query raw raw-keys-from [OPTIONS] <MAP> <START>
Arguments:
<MAP>
— Map name<START>
— Lower-bound
Options:
-l
,--limit <LIMIT>
— Limit
admin query raw raw-iter-from
- Raw database items iteration
Usage: admin query raw raw-iter-from [OPTIONS] <MAP> <START>
Arguments:
<MAP>
— Map name<START>
— Lower-bound
Options:
-l
,--limit <LIMIT>
— Limit
admin query raw raw-count
- Raw database record count
Usage: admin query raw raw-count [MAP] [PREFIX]
Arguments:
<MAP>
— Map name<PREFIX>
— Key prefix
admin query raw compact
- Compact database
Usage: admin query raw compact [OPTIONS]
Options:
-
-m
,--map <MAP>
-
--start <START>
-
--stop <STOP>
-
--from <FROM>
-
--into <INTO>
-
--parallelism <PARALLELISM>
— There is one compaction job per column; then this controls how many columns are compacted in parallel. If zero, one compaction job is still run at a time here, but in exclusive-mode blocking any other automatic compaction jobs until complete -
--exhaustive
Default value:
false
Development
Information about developing the project. If you are only interested in using it, you can safely ignore this page. If you plan on contributing, see the contributor's guide and code style guide.
Continuwuity project layout
Continuwuity uses a collection of sub-crates, packages, or workspace members
that indicate what each general area of code is for. All of the workspace
members are under src/
. The workspace definition is at the top level / root
Cargo.toml
.
The crate names are generally self-explanatory:
admin
is the admin roomapi
is the HTTP API, Matrix C-S and S-S endpoints, etccore
is core Continuwuity functionality like config loading, error definitions, global utilities, logging infrastructure, etcdatabase
is RocksDB methods, helpers, RocksDB config, and general database definitions, utilities, or functionsmacros
are Continuwuity Rust macros like general helper macros, logging and error handling macros, and syn and procedural macros used for admin room commands and othersmain
is the "primary" sub-crate. This is where themain()
function lives, tokio worker and async initialisation, Sentry initialisation, clap init, and signal handling. If you are adding new Rust features, they must go here.router
is the webserver and request handling bits, using axum, tower, tower-http, hyper, etc, and the global server state to accessservices
.service
is the high-level database definitions and functions for data, outbound/sending code, and other business logic such as media fetching.
It is highly unlikely you will ever need to add a new workspace member, but if you truly find yourself needing to, we recommend reaching out to us in the Matrix room for discussions about it beforehand.
The primary inspiration for this design was apart of hot reloadable development,
to support "Continuwuity as a library" where specific parts can simply be swapped out.
There is evidence Conduit wanted to go this route too as axum
is technically an
optional feature in Conduit, and can be compiled without the binary or axum library
for handling inbound web requests; but it was never completed or worked.
See the Rust documentation on Workspaces for general questions and information on Cargo workspaces.
Adding compile-time features
If you'd like to add a compile-time feature, you must first define it in
the main
workspace crate located in src/main/Cargo.toml
. The feature must
enable a feature in the other workspace crate(s) you intend to use it in. Then
the said workspace crate(s) must define the feature there in its Cargo.toml
.
So, if this is adding a feature to the API such as woof
, you define the feature
in the api
crate's Cargo.toml
as woof = []
. The feature definition in main
's
Cargo.toml
will be woof = ["conduwuit-api/woof"]
.
The rationale for this is due to Rust / Cargo not supporting "workspace level features", we must make a choice of; either scattering features all over the workspace crates, making it difficult for anyone to add or remove default features; or define all the features in one central workspace crate that propagate down/up to the other workspace crates. It is a Cargo pitfall, and we'd like to see better developer UX in Rust's Workspaces.
Additionally, the definition of one single place makes "feature collection" in our
Nix flake a million times easier instead of collecting and deduping them all from
searching in all the workspace crates' Cargo.toml
s. Though we wouldn't need to
do this if Rust supported workspace-level features to begin with.
List of forked dependencies
During Continuwuity (and prior projects) development, we have had to fork some dependencies to support our use-cases. These forks exist for various reasons including features that upstream projects won't accept, faster-paced development, Continuwuity-specific usecases, or lack of time to upstream changes.
All forked dependencies are maintained under the continuwuation organization on Forgejo:
- ruwuma - Fork of ruma/ruma with various performance improvements, more features and better client/server interop
- rocksdb - Fork of facebook/rocksdb via
@zaidoon1
with liburing build fixes and GCC debug build fixes - jemallocator - Fork of tikv/jemallocator fixing musl builds, suspicious code, and adding support for redzones in Valgrind
- rustyline-async - Fork of zyansheep/rustyline-async with tab completion callback
and
CTRL+\
signal quit event for Continuwuity console CLI - rust-rocksdb - Fork of rust-rocksdb/rust-rocksdb fixing musl build issues,
removing unnecessary
gtest
include, and using our RocksDB and jemallocator forks - tracing - Fork of tokio-rs/tracing implementing
Clone
forEnvFilter
to support dynamically changing tracing environments
Debugging with tokio-console
tokio-console
can be a useful tool for debugging and profiling. To make a
tokio-console
-enabled build of Continuwuity, enable the tokio_console
feature,
disable the default release_max_log_level
feature, and set the --cfg tokio_unstable
flag to enable experimental tokio APIs. A build might look like
this:
RUSTFLAGS="--cfg tokio_unstable" cargo +nightly build \
--release \
--no-default-features \
--features=systemd,element_hacks,gzip_compression,brotli_compression,zstd_compression,tokio_console
You will also need to enable the tokio_console
config option in Continuwuity when
starting it. This was due to tokio-console causing gradual memory leak/usage
if left enabled.
Building Docker Images
To build a Docker image for Continuwuity, use the standard Docker build command:
docker build -f docker/Dockerfile .
The image can be cross-compiled for different architectures.
Contributing guide
This page is about contributing to Continuwuity. The development and code style guide pages may be of interest for you as well.
If you would like to work on an issue that is not assigned, preferably ask in the Matrix room first at #continuwuity:continuwuity.org, and comment on it.
Code Style
Please review and follow the code style guide for formatting, linting, naming conventions, and other code standards.
Pre-commit Checks
Continuwuity uses pre-commit hooks to enforce various coding standards and catch common issues before they're committed. These checks include:
- Code formatting and linting
- Typo detection (both in code and commit messages)
- Checking for large files
- Ensuring proper line endings and no trailing whitespace
- Validating YAML, JSON, and TOML files
- Checking for merge conflicts
You can run these checks locally by installing prefligit:
# Requires UV: https://docs.astral.sh/uv/getting-started/installation/
# Mac/linux: curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
# Install prefligit using cargo-binstall
cargo binstall prefligit
# Install git hooks to run checks automatically
prefligit install
# Run all checks
prefligit --all-files
Alternatively, you can use pre-commit:
# Requires python
# Install pre-commit
pip install pre-commit
# Install the hooks
pre-commit install
# Run all checks manually
pre-commit run --all-files
These same checks are run in CI via the prefligit-checks workflow to ensure consistency. These must pass before the PR is merged.
Running tests locally
Tests, compilation, and linting can be run with standard Cargo commands:
# Run tests
cargo test
# Check compilation
cargo check --workspace
# Run lints
cargo clippy --workspace
# Auto-fix: cargo clippy --workspace --fix --allow-staged;
# Format code (must use nightly)
cargo +nightly fmt
Matrix tests
Continuwuity uses Complement for Matrix protocol compliance testing. Complement tests are run manually by developers, and documentation on how to run these tests locally is currently being developed.
If your changes are done to fix Matrix tests, please note that in your pull request. If more Complement tests start failing from your changes, please review the logs and determine if they're intended or not.
Sytest is currently unsupported.
Writing documentation
Continuwuity's website uses mdbook
and is deployed via CI using Cloudflare Pages
in the documentation.yml
workflow file. All documentation is in the docs/
directory at the top level.
To build the documentation locally:
-
Install mdbook if you don't have it already:
cargo install mdbook # or cargo binstall, or another method
-
Build the documentation:
mdbook build
The output of the mdbook generation is in public/
. You can open the HTML files directly in your browser without needing a web server.
Commit Messages
Continuwuity follows the Conventional Commits specification for commit messages. This provides a standardized format that makes the commit history more readable and enables automated tools to generate changelogs.
The basic structure is:
<type>[(optional scope)]: <description>
[optional body]
[optional footer(s)]
The allowed types for commits are:
fix
: Bug fixesfeat
: New featuresdocs
: Documentation changesstyle
: Changes that don't affect the meaning of the code (formatting, etc.)refactor
: Code changes that neither fix bugs nor add featuresperf
: Performance improvementstest
: Adding or fixing testsbuild
: Changes to the build system or dependenciesci
: Changes to CI configurationchore
: Other changes that don't modify source or test files
Examples:
feat: add user authentication
fix(database): resolve connection pooling issue
docs: update installation instructions
The project uses the committed
hook to validate commit messages in pre-commit. This ensures all commits follow the conventional format.
Creating pull requests
Please try to keep contributions to the Forgejo Instance. While the mirrors of continuwuity allow for pull/merge requests, there is no guarantee the maintainers will see them in a timely manner. Additionally, please mark WIP or unfinished or incomplete PRs as drafts. This prevents us from having to ping once in a while to double check the status of it, especially when the CI completed successfully and everything so it looks done.
Before submitting a pull request, please ensure:
- Your code passes all CI checks (formatting, linting, typo detection, etc.)
- Your code follows the code style guide
- Your commit messages follow the conventional commits format
- Tests are added for new functionality
- Documentation is updated if needed
Direct all PRs/MRs to the main
branch.
By sending a pull request or patch, you are agreeing that your changes are allowed to be licenced under the Apache-2.0 licence and all of your conduct is in line with the Contributor's Covenant, and continuwuity's Code of Conduct.
Contribution by users who violate either of these code of conducts may not have their contributions accepted. This includes users who have been banned from continuwuity Matrix rooms for Code of Conduct violations.
Code Style Guide
This guide outlines the coding standards and best practices for Continuwuity development. These guidelines help avoid bugs and maintain code consistency, readability, and quality across the project.
These guidelines apply to new code on a best-effort basis. When modifying existing code, follow existing patterns in the immediate area you're changing and then gradually improve code style when making substantial changes.
General Principles
- Clarity over cleverness: Write code that is easy to understand and maintain
- Consistency: Pragmatically follow existing patterns in the codebase, rather than adding new dependencies.
- Safety: Prefer safe, explicit code over unsafe code with implicit requirements
- Performance: Consider performance implications, but not at the expense of correctness or maintainability
Formatting and Linting
All code must satisfy lints (clippy, rustc, rustdoc, etc) and be formatted using nightly rustfmt (cargo +nightly fmt
). Many of the rustfmt.toml
features depend on the nightly toolchain.
If you need to allow a lint, ensure it's either obvious why (e.g. clippy saying redundant clone but it's actually required) or add a comment explaining the reason. Do not write inefficient code just to satisfy lints. If a lint is wrong and provides a less efficient solution, allow the lint and mention that in a comment.
If making large formatting changes across unrelated files, create a separate commit so it can be added to the .git-blame-ignore-revs
file.
Rust-Specific Guidelines
Naming Conventions
Follow standard Rust naming conventions as outlined in the Rust API Guidelines:
- Use
snake_case
for functions, variables, and modules - Use
PascalCase
for types, traits, and enum variants - Use
SCREAMING_SNAKE_CASE
for constants and statics - Use descriptive names that clearly indicate purpose
// Good
fn process_user_request(user_id: &UserId) -> Result<Response, Error> { ... }
const MAX_RETRY_ATTEMPTS: usize = 3;
struct UserSession {
session_id: String,
created_at: SystemTime,
}
// Avoid
fn proc_reqw(id: &str) -> Result<Resp, Err> { ... }
Error Handling
- Use
Result<T, E>
for operations that can fail - Prefer specific error types over generic ones
- Use
?
operator for error propagation - Provide meaningful error messages
- If needed, create or use an error enum.
// Good
fn parse_server_name(input: &str) -> Result<ServerName, InvalidServerNameError> {
ServerName::parse(input)
.map_err(|_| InvalidServerNameError::new(input))
}
// Avoid
fn parse_server_name(input: &str) -> Result<ServerName, Box<dyn Error>> {
Ok(ServerName::parse(input).unwrap())
}
Option Handling
- Prefer explicit
Option
handling over unwrapping - Use combinators like
map
,and_then
,unwrap_or_else
when appropriate
// Good
let display_name = user.display_name
.as_ref()
.map(|name| name.trim())
.filter(|name| !name.is_empty())
.unwrap_or(&user.localpart);
// Avoid
let display_name = if user.display_name.is_some() {
user.display_name.as_ref().unwrap()
} else {
&user.localpart
};
Logging Guidelines
Structured Logging
Always use structured logging instead of string interpolation. This improves log parsing, filtering, and observability.
// Good - structured parameters
debug!(
room_id = %room_id,
user_id = %user_id,
event_type = ?event.event_type(),
"Processing room event"
);
info!(
server_name = %server_name,
response_time_ms = response_time.as_millis(),
"Federation request completed successfully"
);
// Avoid - string interpolation
debug!("Processing room event for {room_id} from {user_id}");
info!("Federation request to {server_name} took {response_time:?}");
Log Levels
Use appropriate log levels:
error!
: Unrecoverable errors that affect functionalitywarn!
: Potentially problematic situations that don't stop executioninfo!
: General information about application flowdebug!
: Detailed information for debuggingtrace!
: Very detailed information, typically only useful during development
Keep in mind the frequency that the log will be reached, and the relevancy to a server operator.
// Good
error!(
error = %err,
room_id = %room_id,
"Failed to send event to room"
);
warn!(
server_name = %server_name,
attempt = retry_count,
"Federation request failed, retrying"
);
info!(
user_id = %user_id,
"User registered successfully"
);
debug!(
event_id = %event_id,
auth_events = ?auth_event_ids,
"Validating event authorization"
);
Sensitive Information
Never log sensitive information such as:
- Access tokens
- Passwords
- Private keys
- Personal user data (unless specifically needed for debugging)
// Good
debug!(
user_id = %user_id,
session_id = %session_id,
"Processing authenticated request"
);
// Avoid
debug!(
user_id = %user_id,
access_token = %access_token,
"Processing authenticated request"
);
Lock Management
Explicit Lock Scopes
Always use closure guards instead of implicitly dropped guards. This makes lock scopes explicit and helps prevent deadlocks.
Use the WithLock
trait from core::utils::with_lock
:
use conduwuit::utils::with_lock::WithLock;
// Good - explicit closure guard
shared_data.with_lock(|data| {
data.counter += 1;
data.last_updated = SystemTime::now();
// Lock is explicitly released here
});
// Avoid - implicit guard
{
let mut data = shared_data.lock().unwrap();
data.counter += 1;
data.last_updated = SystemTime::now();
// Lock released when guard goes out of scope - less explicit
}
For async contexts, use the async variant:
use conduwuit::utils::with_lock::WithLockAsync;
// Good - async closure guard
async_shared_data.with_lock(|data| {
data.process_async_update();
}).await;
Lock Ordering
When acquiring multiple locks, always acquire them in a consistent order to prevent deadlocks:
// Good - consistent ordering (e.g., by memory address or logical hierarchy)
let locks = [&lock_a, &lock_b, &lock_c];
locks.sort_by_key(|lock| lock as *const _ as usize);
for lock in locks {
lock.with_lock(|data| {
// Process data
});
}
// Avoid - inconsistent ordering that can cause deadlocks
lock_b.with_lock(|data_b| {
lock_a.with_lock(|data_a| {
// Deadlock risk if another thread acquires in A->B order
});
});
Documentation
Code Comments
- Reference related documentation or parts of the specification
- When a task has multiple ways of being acheved, explain your reasoning for your decision
- Update comments when code changes
/// Processes a federation request with automatic retries and backoff.
///
/// Implements exponential backoff to handle temporary
/// network issues and server overload gracefully.
pub async fn send_federation_request(
destination: &ServerName,
request: FederationRequest,
) -> Result<FederationResponse, FederationError> {
// Retry with exponential backoff because federation can be flaky
// due to network issues or temporary server overload
let mut retry_delay = Duration::from_millis(100);
for attempt in 1..=MAX_RETRIES {
match try_send_request(destination, &request).await {
Ok(response) => return Ok(response),
Err(err) if err.is_retriable() && attempt < MAX_RETRIES => {
warn!(
destination = %destination,
attempt = attempt,
error = %err,
retry_delay_ms = retry_delay.as_millis(),
"Federation request failed, retrying"
);
tokio::time::sleep(retry_delay).await;
retry_delay *= 2; // Exponential backoff
}
Err(err) => return Err(err),
}
}
unreachable!("Loop should have returned or failed by now")
}
Async Patterns
- Use
async
/await
appropriately - Avoid blocking operations in async contexts
- Consider using
tokio::task::spawn_blocking
for CPU-intensive work
// Good - non-blocking async operation
pub async fn fetch_user_profile(
&self,
user_id: &UserId,
) -> Result<UserProfile, Error> {
let profile = self.db
.get_user_profile(user_id)
.await?;
Ok(profile)
}
// Good - CPU-intensive work moved to blocking thread
pub async fn generate_thumbnail(
&self,
image_data: Vec<u8>,
) -> Result<Vec<u8>, Error> {
tokio::task::spawn_blocking(move || {
image::generate_thumbnail(image_data)
})
.await
.map_err(|_| Error::TaskJoinError)?
}
Inclusivity and Diversity Guidelines
All code and documentation must be written with inclusivity and diversity in mind. This ensures our software is welcoming and accessible to all users and contributors. Follow the Google guide on writing inclusive code and documentation for comprehensive guidance.
The following types of language are explicitly forbidden in all code, comments, documentation, and commit messages:
Ableist language: Avoid terms like "sanity check", "crazy", "insane", "cripple", or "blind to". Use alternatives like "validation", "unexpected", "disable", or "unaware of".
Socially-charged technical terms: Replace overly divisive terminology with neutral alternatives:
- "whitelist/blacklist" → "allowlist/denylist" or "permitted/blocked"
- "master/slave" → "primary/replica", "controller/worker", or "parent/child"
When working with external dependencies that use non-inclusive terminology, avoid propagating them in your own APIs and variable names.
Use diverse examples in documentation that avoid culturally-specific references, assumptions about user demographics, or unnecessarily gendered language. Design with accessibility and inclusivity in mind by providing clear error messages and considering diverse user needs.
This software is intended to be used by everyone regardless of background, identity, or ability. Write code and documentation that reflects this commitment to inclusivity.
Testing
Complement
Have a look at Complement's repository for an explanation of what it is.
To test against Complement, with Nix (or Lix and
direnv installed and set up (run direnv allow
after setting up the hook), you can:
- Run
./bin/complement "$COMPLEMENT_SRC"
to build a Complement image, run the tests, and output the logs and results to the specified paths. This will also output the OCI image atresult
- Run
nix build .#complement
from the root of the repository to just build a Complement OCI image outputted toresult
(it's a.tar.gz
file) - Or download the latest Complement OCI image from the CI workflow artifacts output from the commit/revision you want to test (e.g. from main) here
If you want to use your own prebuilt OCI image (such as from our CI) without needing
Nix installed, put the image at complement_oci_image.tar.gz
in the root of the repo
and run the script.
If you're on macOS and need to build an image, run nix build .#linux-complement
.
We have a Complement fork as some tests have needed to be fixed. This can be found at: https://forgejo.ellis.link/continuwuation/complement
Hot Reloading ("Live" Development)
Note that hot reloading has not been refactored in quite a while and is not guaranteed to work at this time.
Summary
When developing in debug-builds with the nightly toolchain, Continuwuity is modular
using dynamic libraries and various parts of the application are hot-reloadable
while the server is running: http api handlers, admin commands, services,
database, etc. These are all split up into individual workspace crates as seen
in the src/
directory. Changes to sourcecode in a crate rebuild that crate and
subsequent crates depending on it. Reloading then occurs for the changed crates.
Release builds still produce static binaries which are unaffected. Rust's soundness guarantees are in full force. Thus you cannot hot-reload release binaries.
Requirements
Currently, this development setup only works on x86_64 and aarch64 Linux glibc.
musl explicitly does not support hot reloadable libraries, and does not
implement dlclose
. macOS does not fully support our usage of RTLD_GLOBAL
possibly due to some thread-local issues. This Rust issue may be of
relevance, specifically this comment. It may be possible to get it working
on only very modern macOS versions such as at least Sonoma, as currently loading
dylibs is supported, but not unloading them in our setup, and the cited comment
mentions an Apple WWDC confirming there have been TLS changes to somewhat make
this possible.
As mentioned above this requires the nightly toolchain. This is due to reliance
on various Cargo.toml features that are only available on nightly, most
specifically RUSTFLAGS
in Cargo.toml. Some of the implementation could also be
simpler based on other various nightly features. We hope lots of nightly
features start making it out of nightly sooner as there have been dozens of very
helpful features that have been stuck in nightly ("unstable") for at least 5+
years that would make this simpler. We encourage greater community consensus to
move these features into stability.
This currently only works on x86_64/aarch64 Linux with a glibc C library. musl C
library, macOS, and likely other host architectures are not supported (if other
architectures work, feel free to let us know and/or make a PR updating this).
This should work on GNU ld and lld (rust-lld) and gcc/clang, however if you
happen to have linker issues it's recommended to try using mold
or gold
linkers, and please let us know in the Continuwuity Matrix room the linker
error and what linker solved this issue so we can figure out a solution. Ideally
there should be minimal friction to using this, and in the future a build script
(build.rs
) may be suitable to making this easier to use if the capabilities
allow us.
Usage
As of 19 May 2024, the instructions for using this are:
-
Have patience. Don't hesitate to join the Continuwuity Matrix room to receive help using this. As indicated by the various rustflags used and some of the interesting issues linked at the bottom, this is definitely not something the Rust ecosystem or toolchain is used to doing.
-
Install the nightly toolchain using rustup. You may need to use
rustup override set nightly
in your local Continuwuity directory, or usecargo +nightly
for all actions. -
Uncomment
cargo-features
at the top level / root Cargo.toml -
Scroll down to the
# Developer profile
section and uncomment ALL the rustflags for each dev profile and their respective packages. -
In each workspace crate's Cargo.toml (everything under
src/*
ANDdeps/rust-rocksdb/Cargo.toml
), uncomment thedylib
crate type under[lib]
. -
Due to this rpath issue, you must export the
LD_LIBRARY_PATH
environment variable to your nightly Rust toolchain library directory. If using rustup (hopefully), use this:export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/
-
Start the server. You can use
cargo +nightly run
for this along with the standard. -
Make some changes where you need to.
-
In a separate terminal window in the same directory (or using a terminal multiplexer like tmux), run the build Cargo command
cargo +nightly build
. Cargo should only rebuild what was changed / what's necessary, so it should not be rebuilding all the crates. -
In your Continuwuity server terminal, hit/send
CTRL+C
signal. This will tell Continuwuity to find which libraries need to be reloaded, and reloads them as necessary. -
If there were no errors, it will tell you it successfully reloaded
#
modules, and your changes should now be visible. Repeat 7 - 9 as needed.
To shutdown Continuwuity in this setup, hit/send CTRL+\
. Normal builds still
shutdown with CTRL+C
as usual.
Steps 1 - 5 are the initial first-time steps for using this. To remove the hot reload setup, revert/comment all the Cargo.toml changes.
As mentioned in the requirements section, if you happen to have some linker
issues, try using the -fuse-ld=
rustflag and specify mold or gold in all the
rustflags
definitions in the top level Cargo.toml, and please let us know in
the Continuwuity Matrix room the problem. mold can be installed typically
through your distro, and gold is provided by the binutils package.
It's possible a helper script can be made to do all of this, or most preferably
a specially made build script (build.rs). cargo watch
support will be
implemented soon which will eliminate the need to manually run cargo build
all
together.
Addendum
Conduit was inherited as a single crate without modularity or reloading in its design. Reasonable partitioning and abstraction allowed a split into several crates, though many circular dependencies had to be corrected. The resulting crates now form a directed graph as depicted in figures below. The interfacing between these crates is still extremely broad which is not mitigable.
Initially hot_lib_reload was investigated but found appropriate for a
project designed with modularity through limited interfaces, not a large and
complex existing codebase. Instead a bespoke solution built directly on
libloading satisfied our constraints. This required relatively minimal
modifications and zero maintenance burden compared to what would be required
otherwise. The technical difference lies with relocation processing: we leverage
global bindings (RTLD_GLOBAL
) in a very intentional way. Most libraries and
off-the-shelf module systems (such as hot_lib_reload) restrict themselves
to local bindings (RTLD_LOCAL
). This allows them to release software to
multiple platforms with much greater consistency, but at the cost of burdening
applications to explicitly manage these bindings. In our case with an optional
feature for developers, we shrug any such requirement to enjoy the cost/benefit
on platforms where global relocations are properly cooperative.
To make use of RTLD_GLOBAL
the application has to be oriented as a directed
acyclic graph. The primary rule is simple and illustrated in the figure below:
no crate is allowed to call a function or use a variable from a crate below
it.
When a symbol is referenced between crates they become bound: crates cannot be
unloaded until their calling crates are first unloaded. Thus we start the
reloading process from the crate which has no callers. There is a small problem
though: the first crate is called by the base executable itself! This is solved
by using an RTLD_LOCAL
binding for just one link between the main executable
and the first crate, freeing the executable from all modules as no global
binding ever occurs between them.
Proper resource management is essential for reliable reloading to occur. This is a very basic ask in RAII-idiomatic Rust and the exposure to reloading hazards is remarkably low, generally stemming from poor patterns and practices. Unfortunately static analysis doesn't enforce reload-safety programmatically (though it could one day), for now hazards can be avoided by knowing a few basic do's and dont's:
-
Understand that code is memory. Just like one is forbidden from referencing free'd memory, one must not transfer control to free'd code. Exposure to this is primarily from two things:
- Callbacks, which this project makes very little use of.
- Async tasks, which are addressed below.
-
Tie all resources to a scope or object lifetime with greatest possible symmetry (locality). For our purposes this applies to code resources, which means async blocks and tokio tasks.
- Never spawn a task without receiving and storing its JoinHandle.
- Always wait on join handles before leaving a scope or in another cleanup function called by an owning scope.
-
Know any minor specific quirks documented in code or here:
- Don't use
tokio::spawn
, instead use ourHandle
incore/server.rs
, which is reachable in most of the codebase viaservices()
or other state. This is due to some bugs or assumptions made in tokio, as it happens inunsafe {}
blocks, which are mitigated by circumventing some thread-local variables. Using runtime handles is good practice in any case.
- Don't use
The initial implementation PR is available here.
Interesting related issues/bugs
- DT_RUNPATH produced in binary with rpath = true is wrong (cargo)
- Disabling MIR Optimization in Rust Compilation (cargo)
- Workspace-level metadata (cargo-deb)
Continuwuity Community Guidelines
Welcome to the Continuwuity commuwunity! We're excited to have you here. Continuwuity is a continuation of the conduwuit homeserver, which in turn is a hard-fork of the Conduit homeserver, aimed at making Matrix more accessible and inclusive for everyone.
This space is dedicated to fostering a positive, supportive, and welcoming environment for everyone. These guidelines apply to all Continuwuity spaces, including our Matrix rooms and any other community channels that reference them. We've written these guidelines to help us all create an environment where everyone feels safe and respected.
For code and contribution guidelines, please refer to the Contributor's Covenant. Below are additional guidelines specific to the Continuwuity community.
Our Values and Expected Behaviors
We strive to create a community based on mutual respect, collaboration, and inclusivity. We expect all members to:
-
Be Respectful and Inclusive: Treat everyone with respect. We're committed to a community where everyone feels safe, regardless of background, identity, or experience. Discrimination, harassment, or hate speech won't be tolerated. Remember that each person experiences the world differently; share your own perspective and be open to learning about others'.
-
Be Positive and Constructive: Engage in discussions constructively and support each other. If you feel angry or frustrated, take a break before participating. Approach disagreements with the goal of understanding, not winning. Focus on the issue, not the person.
-
Communicate Clearly and Kindly: Our community includes neurodivergent individuals and those who may not appreciate sarcasm or subtlety. Communicate clearly and kindly. Avoid ambiguity and ensure your messages can be easily understood by all. Avoid placing the burden of education on marginalized groups; please make an effort to look into your questions before asking others for detailed explanations.
-
Be Open to Improving Inclusivity: Actively participate in making our community more inclusive. Report behaviour that contradicts these guidelines (see Reporting and Enforcement below) and be open to constructive feedback aimed at improving our community. Understand that discussing negative experiences can be emotionally taxing; focus on the message, not the tone.
-
Commit to Our Values: Building an inclusive community requires ongoing effort from everyone. Recognise that addressing bias and discrimination is a continuous process that needs commitment and action from all members.
Unacceptable Behaviors
To ensure everyone feels safe and welcome, the following behaviors are considered unacceptable within the Continuwuity community:
-
Harassment and Discrimination: Avoid offensive comments related to background, family status, gender, gender identity or expression, marital status, sex, sexual orientation, native language, age, ability, race and/or ethnicity, caste, national origin, socioeconomic status, religion, geographic location, or any other dimension of diversity. Don't deliberately misgender someone or question the legitimacy of their gender identity.
-
Violence and Threats: Do not engage in any form of violence or threats, including inciting violence towards anyone or encouraging self-harm. Posting or threatening to post someone else's personally identifying information ("doxxing") is also forbidden.
-
Personal Attacks: Disagreements happen, but they should never turn into personal attacks. Don't insult, demean, or belittle others.
-
Unwelcome Attention or Contact: Avoid unwelcome sexual attention, inappropriate physical contact (or simulation thereof), sexualized comments, jokes, or imagery.
-
Disruption: Do not engage in sustained disruption of discussions, events, or other community activities.
-
Bad Faith Actions: Do not intentionally make false reports or otherwise abuse the reporting process.
This is not an exhaustive list. Any behaviour that makes others feel unsafe or unwelcome may be subject to enforcement action.
Matrix Community
These Community Guidelines apply to the entire Continuwuity Matrix Space and its rooms, including:
#continuwuity:continuwuity.org
This room is for support and discussions about Continuwuity. Ask questions, share insights, and help each other out while adhering to these guidelines.
We ask that this room remain focused on the Continuwuity software specifically: the team are typically happy to engage in conversations about related subjects in the off-topic room.
#offtopic:continuwuity.org
For off-topic community conversations about any subject. While this room allows for a wide range of topics, the same guidelines apply. Please keep discussions respectful and inclusive, and avoid divisive or stressful subjects like specific country/world politics unless handled with exceptional care and respect for diverse viewpoints.
General topics, such as world events, are welcome as long as they follow the guidelines. If a member of the team asks for the conversation to end, please respect their decision.
#dev:continuwuity.org
This room is dedicated to discussing active development of Continuwuity, including ongoing issues or code development. Collaboration here must follow these guidelines, and please consider raising an issue on the repository to help track progress.
Reporting and Enforcement
We take these Community Guidelines seriously to protect our community members. If you witness or experience unacceptable behaviour, or have any other concerns, please report it.
How to Report:
- Alert Moderators in the Room: If you feel comfortable doing so, you can address the issue
publicly in the relevant room by mentioning the moderation bot,
@rock:continuwuity.org
, which will immediately alert all available moderators. - Direct Message: If you're not comfortable raising the issue publicly, please send a direct message (DM) to one of the room moderators.
Reports will be handled with discretion. We will investigate promptly and thoroughly.
Enforcement Actions:
Anyone asked to stop unacceptable behaviour is expected to comply immediately. Failure to do so, or engaging in prohibited behaviour, may result in enforcement action. Moderators may take actions they deem appropriate, including but not limited to:
- Warning: A direct message or public warning identifying the violation and requesting corrective action.
- Temporary Mute: Temporary restriction from participating in discussions for a specified period.
- Kick or Ban: Removal from a room (kick) or the entire community space (ban). Egregious or repeated violations may result in an immediate ban. Bans are typically permanent and reviewed only in exceptional circumstances.
Retaliation against those who report concerns in good faith will not be tolerated and will be subject to the same enforcement actions.
Together, let's build and maintain a community where everyone feels valued, safe, and respected.
— The Continuwuity Moderation Team
Security Policy for Continuwuity
This document outlines the security policy for Continuwuity. Our goal is to maintain a secure platform for all users, and we take security matters seriously.
Supported Versions
We provide security updates for the following versions of Continuwuity:
Version | Supported |
---|---|
Latest release | ✅ |
Main branch | ✅ |
Older releases | ❌ |
We may backport fixes to the previous release at our discretion, but we don't guarantee this.
Reporting a Vulnerability
Responsible Disclosure
We appreciate the efforts of security researchers and the community in identifying and reporting vulnerabilities. To ensure that potential vulnerabilities are addressed properly, please follow these guidelines:
- Contact members of the team directly over E2EE private message.
- Email the security team at [email protected]. This is not E2EE, so don't include sensitive details.
- Do not disclose the vulnerability publicly until it has been addressed
- Provide detailed information about the vulnerability, including:
- A clear description of the issue
- Steps to reproduce
- Potential impact
- Any possible mitigations
- Version(s) affected, including specific commits if possible
If you have any doubts about a potential security vulnerability, contact us via private channels first! We'd prefer that you bother us, instead of having a vulnerability disclosed without a fix.
What to Expect
When you report a security vulnerability:
- Acknowledgment: We will acknowledge receipt of your report.
- Assessment: We will assess the vulnerability and determine its impact on our users
- Updates: We will provide updates on our progress in addressing the vulnerability, and may request you help test mitigations
- Resolution: Once resolved, we will notify you and discuss coordinated disclosure
- Credit: We will recognize your contribution (unless you prefer to remain anonymous)
Security Update Process
When security vulnerabilities are identified:
- We will develop and test fixes in a private fork
- Security updates will be released as soon as possible
- Release notes will include information about the vulnerabilities, avoiding details that could facilitate exploitation where possible
- Critical security updates may be backported to the previous stable release
Additional Resources
This security policy was last updated on May 25, 2025.