NyxNiri: every install URL names ech678/Nyxuri, two wikis live in the repository while a third lives on GitHub, and monitor.kdl survives by exact filename

The recommended clone names a repository this one is not called

The repository is `ech678/NyxNiri`. Every code reference inside the README names `ech678/Nyxuri`:

# shallow clone: latest snapshot only; drop --depth 1 for full history
git clone --depth 1 https://github.com/ech678/Nyxuri.git ~/Nyxuri
cd ~/Nyxuri && ./install.sh

The project states that it was rebranded from NyxNiri to Nyxuri, and says that running `nyxuri` migrates existing configs, snapshots, and state and cleans up legacy paths. The rename was applied to the commands and the prose and not to the hosting side, so the URL in the recommended install path is not the URL of this repository. The same skew appears in the raw installer address, which fetches `install.sh` from the `Nyxuri` path, and the website link still points at the old `nyxniri.com` domain. Repository name, code references, and site domain are three different answers to one question.

Two wikis in the repository and a third on GitHub

The root of the repository contains `humans-wiki/` and `llms-wiki/`, two directories with wiki in the name. Meanwhile every documentation link on the page points somewhere else entirely: a Configuration Guide, a Presets Guide, a Keybindings page, a CLI Reference, a Troubleshooting guide, and an Extensions guide, all under the `wiki/` path of the GitHub-hosted project. Those are two different storage locations, since the wiki feature keeps its content outside the repository tree. So the repository ships two wikis, the README cites a third that lives on GitHub, and the page also links a Home wiki in the header. Nothing states which of the three is authoritative, which is current, or whether the in-tree copies are generated from the remote one. For a project whose selling point is that you can read and edit everything, the documentation layer is the part with the least clarity about its source of truth.

An online installer pipes a script into bash through an optional mirror

Two installation routes are offered and the difference matters more than the word recommended suggests. The checkout route clones with `--depth 1`, so you get the latest snapshot rather than full history, and then runs `./install.sh` from the directory, which means you can read the script before it runs. The standalone route fetches the same script over the network and pipes it into a shell:

curl -fsSL --connect-timeout 10 https://raw.githubusercontent.com/ech678/Nyxuri/main/install.sh | bash

A third variant of the same idea is offered in a collapsed section: both the script fetch and a full clone routed through `gh-proxy.org`, a third-party GitHub proxy. That is a reasonable accommodation for a network where GitHub is slow, and it means the script that installs your desktop environment is retrieved through a host that is not GitHub and not you. The `--connect-timeout 10` flag bounds the wait but says nothing about what is verified, and no checksum accompanies the download in any of the three routes.

monitor.kdl survives by exact filename while everything else needs the marker

The survival model is precise and worth reading closely. Configs deploy atomically, and personal tweaks persist through what the page calls the Dunder protocol: any file or folder whose name contains `__custom__` is preserved, with `__custom__.kdl` and `__custom__.conf` given as examples. `monitor.kdl` is then called out separately as also preserved. That exception is an exact filename, not a pattern and not a documented extension point, so a user whose compositor configuration is called something else, or who keeps monitor definitions in a differently named file, gets it overwritten on the next deploy with no way to register another exception. Presets layer between the defaults and those custom files so switching a preset never touches personal edits, which is the same careful intent. The word atomic is doing unearned work in the sentence that introduces all of this, since a set of files copied into a home directory is not atomic without a staging directory and a rename.

The layout diagram omits six of the repository's root entries

The Included Configs section draws the tree the installer deploys:

Nyxuri
├── install.sh                  # lightweight bootstrap entrypoint
├── nyxuri/                     # Python core engine (zero pip dependencies)
├── assets/                     # static assets (wallpapers, fcitx5 skin templates)
└── configs/
    ├── niri/                   # window manager (.kdl, .toml)
    │   └── scripts/            # glue scripts & action gateways
    ├── noctalia/               # shell + theme sync & companion tools (Orbit, wallpaper picker)
    ├── xdg-desktop-portal/     # portal routing (Settings / screencast)
    ├── kitty/                  # terminal

This is a deployment diagram rather than a repository diagram, so it is not wrong to omit the rest. What it does mean is that the tree ends at `kitty` with four config directories shown and no statement that the list is complete. The repository root also holds `.editorconfig`, `.gitattributes`, `.github/`, `.gitignore`, `AGENTS.md`, `CHANGELOG.md`, `LICENSE`, `README.md`, `README.zh-CN.md`, `ROADMAP.md`, `humans-wiki/`, `llms-wiki/`, and `tests/`. Six of those are project infrastructure rather than deployed configuration, and none appears in the diagram. The claim that the Python engine has zero pip dependencies is the notable part of the diagram.

The installer will bootstrap paru for you, which means running AUR recipes

One tip note says the installer auto-detects Shelly, paru, and yay, and that if none of those are present, `nyxuri install full` bootstraps paru automatically. So on a machine with no AUR helper, the documented full install acquires one first. That is the standard Arch model rather than something unusual, but it is worth being explicit about what it means: an AUR helper downloads a PKGBUILD and its sources and executes build instructions on your machine, usually as your own user, and a `full` install pulls a package set that the page never enumerates. The three helpers are treated as interchangeable here even though each has different build behaviour and different defaults for clean-up and review. Nothing in the page asks you to read the package list before the run, and the `full` argument name suggests completeness rather than the scope that a helper bootstrap implies.

Three commands share the job and diagnostics come through two of them

Three executables appear across the page. `install.sh` is the shell bootstrap, the Python engine is invoked as `nyxuri` and is said to manage install, update, snapshots, and diagnostics, and `nyxhelp` is described as an instant cheatsheet in the terminal, with `nyxhelp keys` as the keybinding quick reference. Troubleshooting then says that when you hit a problem you should run `./install.sh doctor` first, while the tooling section says `nyxuri` handles diagnostics. So the same check is documented under two different entry points, which means a reader following the troubleshooting advice on a machine where the Python engine is only half installed is relying on the shell bootstrap path having the capability. Keybindings are described as dispatching through a single script, `shell-action.sh`, which is a reasonable shape for a dotfiles repo and is the one piece of internal structure the page actually names.

An LLM is in the credits and an agent file is at the root

The special thanks list credits a commercial model first among contributors, with the note that it burned through a pile of free tokens, ahead of three named humans credited with community management and support. The repository root also contains `AGENTS.md`, a file whose entire purpose is to instruct a coding assistant. For a configuration repository this is unusual and mildly consequential in a specific way: dotfiles are read once, copied into a home directory, and then trusted implicitly, so a large share of the shipped `.kdl` and `.toml` may have been produced by a model rather than written by hand. Nothing on the page asks you to review the configuration before deploying it, which is the step a model-authored config most needs. The feature list also includes fish aliases for proxy and cache management, so the configuration makes a network and privacy choice for you as well as a visual one.

Editorial conclusion

This is a carefully built configuration with an unusually explicit survival model, and the preservation rule plus the atomic deploy claim are the parts worth borrowing. Two things to resolve before you install it. First, the repository is still named NyxNiri while every code reference names Nyxuri, so the recommended clone and the standalone one-liner both point at a path that does not match this repository; find the working URL before running anything. Second, the online installer executes a script fetched at runtime and one variant routes it through a third-party mirror, so use the shallow-clone path where you can read the script first. Read the extension list too, since a desktop config that ships proxy and cache aliases in your fish configuration is making a privacy choice on your behalf.

Frequently asked questions

Official sources

1. ech678/NyxNiri on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases