Tom Foster
b481ff31c0
Some checks failed
Checks / Build / Publish / Pre-commit & Formatting (pull_request) Successful in 31s
Deploy / Documentation / Build and Deploy Documentation (pull_request) Successful in 36s
Checks / Build / Publish / Clippy and Cargo Tests (pull_request) Successful in 3m21s
Checks / Build / Publish / Build linux/amd64 (pull_request) Failing after 3m41s
Checks / Build / Publish / Build linux/arm64 (pull_request) Failing after 4m12s
Checks / Build / Publish / Publish Multi-Platform (pull_request) Failing after 0s
Merge rust-checks.yml and release-image.yml into unified ci-build.yml
workflow that runs faster and more efficiently. The previous setup ran
4+ parallel jobs immediately (format, clippy, test, builds), causing
resource contention. The new pipeline runs max 2 jobs in parallel at
each stage, catching lint/format issues quickly before attempting
expensive compilation.
Extract all Rust setup logic from both workflows into reusable
rust-with-cache composite action. This replaces 6 separate actions
(rust-toolchain, sccache, timelord, plus inline APT/cache steps) with
a single action that handles:
- Rust toolchain installation with component selection
- Cross-compilation configuration (previously scattered across
release-image.yml)
- System dependency installation with proper error handling
- Comprehensive caching (sccache, cargo registry, cargo target, uv
tools)
- Timeline tracking and performance monitoring
The previous release-image.yml had cross-compilation support but it
was implemented inline with complex environment variables. The new
rust-with-cache action centralises this with proper parameters for
pkg-config paths, foreign architecture setup, and toolchain selection.
Performance improvements make the pipeline fast enough to consolidate:
- Warmed sccache cache shared between check and build stages
- Optimised cargo target cache to exclude incremental/ and binaries
(was caching entire target/ directory via buildkit-cache-dance)
- Add restore-keys fallback for better cache hit rates
- Parallel background tasks for Rust setup while APT runs
- Fail-fast on format/lint errors before expensive compilation
- Enable Haswell CPU optimisations for x86_64 builds (AVX2, FMA, etc.)
- Add cross-language LTO (Link-Time Optimisation) for better performance
Fix ARM64 cross-compilation reliability issues:
- Move APT installations from background to foreground (background
processes would hang during package downloads despite
DEBIAN_FRONTEND=noninteractive)
- Set proper pkg-config environment for cross-compilation
- Configure APT sources to ports.ubuntu.com for foreign architectures
- Replace hardened_malloc with jemalloc (ARM64 unsupported)
Modernisation from previous commit (
|
||
|---|---|---|
| .cargo | ||
| .forgejo | ||
| .github | ||
| .vscode | ||
| arch | ||
| bin | ||
| debian | ||
| docker | ||
| docs | ||
| nix/pkgs/main | ||
| src | ||
| tests | ||
| theme | ||
| xtask | ||
| .dockerignore | ||
| .editorconfig | ||
| .envrc | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .markdownlintignore | ||
| .pre-commit-config.yaml | ||
| .typos.toml | ||
| book.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| clippy.toml | ||
| CODE_OF_CONDUCT.md | ||
| committed.toml | ||
| conduwuit-example.toml | ||
| CONTRIBUTING.md | ||
| default.nix | ||
| development.md | ||
| engage.toml | ||
| flake.lock | ||
| flake.nix | ||
| LICENSE | ||
| README.md | ||
| renovate.json | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
| SECURITY.md | ||
continuwuity
A community-driven Matrix homeserver in Rust
continuwuity is a Matrix homeserver written in Rust. It's a community continuation of the conduwuit homeserver.
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!
Contribution
Development flow
- Features / changes must developed in a separate branch
- For each change, create a descriptive PR
- Your code will be reviewed by one or more of the continuwuity developers
- The branch will be deployed live on multiple tester's matrix servers to shake out bugs
- Once all testers and reviewers have agreed, the PR will be merged to the main branch
- The main branch will have nightly builds deployed to users on the cutting edge
- Every week or two, a new release is cut.
The main branch is always green!
Policy on pulling from other forks
We welcome contributions from other forks of conduwuit, subject to our review process. When incorporating code from other forks:
- All external contributions must go through our standard PR process
- Code must meet our quality standards and pass tests
- Code changes will require testing on multiple test servers before merging
- Attribution will be given to original authors and forks
- We prioritize stability and compatibility when evaluating external contributions
- Features that align with our project goals will be given priority consideration
Contact
Join our Matrix room and space to chat with us about the project!