District Core for Rust

The shared Rust core of the District AI apps for Linux and Windows: the data types, the HTTP client, sign-in, live updates, the application state and the call engine, as seven crates with no user interface toolkit in any of them. An app renders the state the core hands it and forwards what the user does; the core decides the rest.

Used by

District AI for LinuxGTK 4 and libadwaita

District AI for WindowsWinUI 3, through UniFFI

Seven crates, one workspace

district-modelThe API's data types and the live event envelopes, with no IO

district-apiThe HTTP client and the endpoint table

district-authSign-in: OAuth with PKCE in the browser, token refresh, sign-out

district-liveThe live updates socket

district-coreApp state: the session, routes, a model per screen, the effect runner

district-hostWhat a desktop app keeps on the machine, and sleep

district-callThe call engine, on LiveKit in a build with calls

Tested on Linux and Windows.

One core for the desktop apps

Tested without a desktop

No crate depends on a user interface toolkit or on one operating system, so every test runs without a display, a keyring or a network, on Linux and on Windows. The tests must reach every line of every crate's default build, or continuous integration fails.

Held to the service's own answers

The repository carries responses recorded from the District AI service, and its tests decode every one with unknown fields refused, so a field the server renames or adds fails here rather than in an app. The endpoint table is checked against the Android app's every week.

A change reaches an app as a version

A release is a version tag that never moves. Each app pins it by tag and exact version, so Cargo refuses a tag that does not hold that version, and moves to a new release in a pull request of its own.

Licence: Apache-2.0
Built with: Rust, Cargo
Used by: District AI for Linux and District AI for Windows

District Core for Rust on GitHub

What is open source, and what is not

What is open source

These crates, under Apache-2.0: you can read them, build them, change them and use them. The District AI and Distronode names, logos and app icons are trademarks, so an app you distribute with these crates uses its own name, icon and identifier.

The crates report no crashes: no crash-reporting library is among their dependencies, and nothing in them logs or prints.

What is not

The District AI service the crates talk to. Signing in needs a District AI account; without one you can still build the crates and run every test.

Without an account with us

Today the apps need a District AI account to sign in. We want them to work without an account with us too. We have not worked out what that looks like or whether it can work, and the answer depends on what people would use them with, so we are asking before we build anything.

Tell us what you would connect them to

Get involved

Issues and pull requests are welcome on GitHub. Report a vulnerability privately, as the security policy describes, and not in a public issue.

Contributing guide: CONTRIBUTING.md
Security policy: SECURITY.md
Changelog: CHANGELOG.md