Academy Network desktop client

The desktop application: the thing a person installs to become a node. Build order phase 4, in progress. The app embeds the full Rust node (the same engine the headless seed runs): starting it bootstraps Tor, publishes this node's onion service, syncs the corpus from peers, and serves it onward. The UI is a thin client over that node; every rule peers could disagree about lives in academy-core, per the spec.

Built today:

• The embedded node: persistent onion identity, disk-backed object and blob stores, peer table, gossip, the manifest follower (SPEC 7), and an in-process supervisor that retries failures quietly.
• Library and reader: the approved index from the validated manifest chain head, grouped by hierarchy and ordered by level; guides rendered from CommonMark in Rust and sanitized before they touch the DOM. Wiki topic: links route in-app (red links for guides that do not exist yet); media loads from the local blob store over a custom protocol; external links ask before leaving the network.
• Network page: the node's own health, address, peers, chain head, and gossip counters. Local knowledge only; nothing reports anywhere.
• The guide editor: WYSIWYG over the protocol's CommonMark (ProseMirror + prosemirror-markdown; the markup never shows unless you open the source tab, which edits the same document). Toolbar and standard shortcuts, wiki links to other guides, images stored as content-addressed blobs with prompted alt text. Drafts autosave continuously to this machine only; nothing leaves until you submit.
• Submission: signing with your local identity, the SPEC 9 proof of work, and publish over Tor. Edits chain onto the approved revision; new guides go into an existing subject or found a new one.
• Revision history on every guide with word-level diffs ("what changed"), and restore (open any old revision as a new draft).
• The community layer: up/down ratings (one counted vote per person, your latest wins), public talk pages, what-links-here backlinks, a recent-changes feed, and a wanted-guides board, all built from ordinary signed objects.
• Standalone Media (SPEC 5.19): a Media section for uploads that stand on their own (books, videos, audio, images, files), not attached to a guide. It reuses the guide-media blob machinery, so a large file chunks into content-addressed parts that spread across peers (no node holds the whole thing), identical bytes dedupe network-wide, and uncompressed uploads are opportunistically compressed. An author can take down an upload that is solely theirs (SPEC 5.20 author self-delete); everything else comes down by community vote.
• The verifier review flow: an opt-in review-duty switch (SPEC 5.11), a queue of docketed submissions with live tallies, and a submission view where a juror reads the proposed text (with a diff against the approved revision) and votes approve or reject with written reasoning (SPEC 5.4). The app hosts the phase-3 editorial runtimes, replayed from the local store.
• The governance portal (Community): your earned standing (SPEC 5.8), open petitions with standing-weighted tallies and their pass bars, a full petition composer (including no-confidence with a successor editor set, and seat-verifier), removal petitions (SPEC 5.6), and verifier certification (SPEC 5.9) all standing-weighted, public, and permanent. The forum carries the same community controls (SPEC 5.10/5.14): petitions to remove a whole board and everything in it, remove a whole thread and its replies, and lock or pin a board or thread. Removals reuse the manifest removed set; lock and pin are reader-derived from the passed-petition set, so no new manifest field is needed and the genesis id never moves.
• The editors' console: the app half of the manifest signing ceremony (SPEC 7), readable by anyone. It shows what the next manifest MUST contain (submissions to docket, jury approvals to adopt, the manual-review queue, governance bindings, passed removals), assembles the proposal, tracks arriving detached signatures against the threshold, and publishes the finished manifest. Secret editor keys never enter the app: co-signing happens offline with the academy-ceremony tool from the node repository, and the two link the same crate so the file formats cannot drift.
• The duke layer (SPEC 5.7): every guide's original poster holds its display properties (title override, donation link) and nothing else; the duke panel on the guide page sets, hands over, or renounces them. Content stays community-owned.
• Three-way merge on submit: a draft remembers which revision it started from, and if a different one is approved before you submit, the newer accepted changes fold in automatically; genuinely overlapping edits come back as marked conflict blocks to resolve instead of silently overwriting anyone's work.
• The update ASK (SPEC 18.4): seeds auto-update behind a canary window; this app only ever checks and tells, at your explicit request (the button says it contacts the website), verifying the release roster chain and threshold signatures against the trust anchor baked into the build before comparing versions. It never downloads or installs code.
• Packaging: a Windows installer (NSIS, about 8 MB with Tor built in), published with its SHA-256 on the website's download page.
• Speed and first-run seamlessness: the installer bundles a self-validating corpus snapshot (re-checked object by object on import, so it is a head start, never a trust shortcut) that populates the approved library and the starter forum boards on first launch instead of waiting for a full sync; a real Tor bootstrap progress bar; offline title + full-text search over the whole local corpus; a live proof-of-work meter while a submission grinds; background prefetch of approved guides' images; and release builds tuned for size and speed.
• The "you" layer: a first-run welcome page; a You page (your key, standing, authored guides with live status, review-vote history) with in-app identity backup and restore (the backup file is the key; no server holds anything); an Inbox derived entirely from the local store (submission outcomes, talk-page replies, jury duty) with an unread badge; and a Settings page (peer ceiling, media disk budget (5 GB by default, so the corpus spreads across many nodes), Tor bridge lines for censored networks) writing the same config.toml operators edit by hand.
• The locked design system (the website repository's design/), same shell, light and dark.

The genesis ceremony that pins the first manifest was held on 2026-07-15, so the app now follows a live chain with an approved library. Still ahead: a pin-baked installer rebuild and the macOS / Linux installers.

Build and run

Prerequisites: Rust (1.90+), Node.js (20+), and the platform webview (bundled on Windows 10/11 and macOS; on Linux install webkit2gtk-4.1).

npm install
npm run tauri dev      # run with hot reload
npm run tauri build    # produce installers

The first run bootstraps Tor (it can take a minute or two) and then publishes this node's onion service. The node's data directory (shown on the app's Network page) holds its onion key and identity: back it up, losing it changes the node's address.

In this repository the Rust core is fetched from the public node repository (src-tauri/Cargo.toml). In the maintainers' working copy those are local path dependencies; the publish script rewrites them.

Contributing

See CONTRIBUTING.md for how to contribute and the house rules, with CODE_OF_CONDUCT.md and SECURITY.md alongside it. In short: the protocol (SPEC.md, in the spec repository) is authoritative, the visual style is locked, and changes merge by the public forge rule, not a maintainer's say-so. Anyone can contribute, under any name.

License

AGPL-3.0-or-later, like all code in this project. See LICENSE.