- Rust 95.8%
- Jinja 1.9%
- Dockerfile 0.6%
- CSS 0.5%
- Shell 0.4%
- Other 0.7%
Morgan
7e979882bd
All checks were successful
Documentation / Build and Deploy Documentation (pull_request) Successful in 1m5s
Checks / Prek / Check changed files (pull_request) Successful in 6s
Checks / Prek / Pre-commit & Formatting (pull_request) Successful in 1m23s
Update flake hashes / update-flake-hashes (pull_request) Successful in 1m26s
Checks / Prek / Clippy and Cargo Tests (pull_request) Has been skipped
Checks / Changelog / Check changelog is added (pull_request_target) Successful in 10s
The arm64 build cross-compiled with the Rust target triple inside an amd64 container and copied the binary out, deliberately avoiding Docker emulation because arm64 emulation is unreliable on some BuildKit instances. A dedicated Ubuntu VM on an M4 Mac Mini is now available under the ubuntu-arm64 label. Each matrix entry carries its own runner label and a native flag, so builds can be moved between runners or between build modes without changing the workflow structure. Where native is set, the build-native action compiles on the host and assembles the artefact tree, leaving Docker to package it. It builds into a target directory outside the per-run workspace so cargo can reuse artefacts between runs. The Dockerfile's ARTIFACTS argument selects whether artefacts come from the builder stage or from out/ in the build context; prepper and the final image are unchanged. Libraries are resolved where the binary was linked, so arm64 images carry Ubuntu's rather than Debian's. Architecture flags are split into TARGET_MARCH, which feeds -march for the C and C++ compilers, and TARGET_RUSTFLAGS, which is appended to RUSTFLAGS. amd64 passes haswell to both as before; arm64 passes +crc, which rustc does not enable by default. TARGET_CPU still drives the tag and artefact suffix. |
||
|---|---|---|
| .cargo | ||
| .forgejo | ||
| .github | ||
| .vscode | ||
| bin | ||
| changelog.d | ||
| complement | ||
| docker | ||
| docs | ||
| nix | ||
| pkg | ||
| src | ||
| tests | ||
| theme | ||
| xtask | ||
| .dockerignore | ||
| .editorconfig | ||
| .envrc | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .markdownlintignore | ||
| .pre-commit-config.yaml | ||
| .typos.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| clippy.toml | ||
| CODE_OF_CONDUCT.md | ||
| committed.toml | ||
| conduwuit-example.toml | ||
| CONTRIBUTING.md | ||
| default.nix | ||
| development.md | ||
| engage.toml | ||
| flake.lock | ||
| flake.nix | ||
| LICENSE | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| release.toml | ||
| renovate.json | ||
| rspress.config.ts | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
| SECURITY.md | ||
| taplo.toml | ||
| towncrier.toml | ||
| tsconfig.json | ||
continuwuity
A community-driven Matrix homeserver in Rust
continuwuity is a Matrix homeserver written in Rust. It's the official 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.
If you want to try it out as a user, we have some partnered homeservers you can use:
-
You can head over to https://federated.nexus in your browser.
- Hit the
Apply to Joinbutton. Once your request has been accepted, you will receive an email with your username and password. - Head over to https://app.federated.nexus and you can sign in there, or use any other matrix chat client you wish elsewhere.
- Your username for matrix will be in the form of
@username:federated.nexus, however you can simply use theusernamepart to log in. Your password is your password.
- Hit the
-
There's also https://continuwuity.rocks/. You can register a new account using Cinny via this convenient link, or you can use Element or another matrix client that supports registration.
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!