Documentation glossary
Terms used throughout the documentation, and the docs-only additions that the product glossary does not define.
Terms are defined in two places, and this is the smaller one. The product glossary defines the vocabulary of Nexa and Rinko Hub themselves; this page adds the handful of terms the documentation introduces on top of it, and clears up one name that appears on the legal pages without explanation.
The product glossary
Every core term lives at /glossary, defined once, with its nearest Git equivalent named where one exists. Rather than repeat those definitions here, this page links to them:
- Repository — one object database, one set of references, one unit of synchronisation.
- Object and content addressing — immutable content, identified by the hash of what it contains.
- Version — a complete, selectable state of a tree. Not a delta, and not a commit.
- Branch — a named context holding a set of competing candidates.
- Workspace — a development context inside a branch where competing versions coexist.
- Candidate — a version offered as a possible answer within a branch or workspace.
- Selected version — the candidate a branch currently points at. Never "tip", never "HEAD".
- Label and label key, sealed content and .nexapolicy — how a path is protected by encryption.
- Reconciliation and merge — the synchronisation primitive, and resolving divergent trees.
- Remote and device identity — an address paired with the key that authenticates a machine.
If a term in the documentation is not defined on the page you met it on, it is almost certainly there.
Docs-only terms
These are introduced by the documentation rather than by the protocol, and the product glossary does not define them.
Development Root
The single folder that holds all your active work. You declare it once with nexa root, and every working context you bring in lands beneath it. Capitalised,
always, because it names one specific thing rather than describing a kind of directory.
Only the root carries a .nexa/ directory; the contexts beneath it are ordinary
directories containing ordinary files. See the Development Root model for the structure, and Set up a Development Root for the procedure.
Working context
One repository, one branch and one workspace, materialised as a directory beneath the
Development Root. It is the thing you actually work in, and it is what nexa get creates and nexa drop removes.
A working context knows which repository it came from, which branch and workspace it represents,
and — for hosted work — where it is hosted. That is why nexa record and nexa sync never take a destination: the context already holds the answer. Several contexts
of the same repository can exist side by side under one root without interfering.
The candidate model
Shorthand for the behaviour described on branches and workspaces: a branch holds several competing versions at once, and selecting one supersedes the others without deleting them. Used in the documentation when referring to the arrangement as a whole rather than to any single term within it.
Superseded
What a previously selected version becomes when a different candidate is selected. A superseded version is still present, still complete, and still selectable — the word marks its current standing in the branch, not a loss. Nothing in Nexa destroys a recorded version.
Nexaji is the company
Nexaji — formally Nexaji LTD — is the company. It is not a product name.
The three names are used consistently throughout this documentation:
- Nexa is the protocol, and the name of the command-line program.
- Rinko Hub is the hosted platform — two words, always.
- Nexaji is the company that builds both, and appears on the terms, privacy and other legal pages for that reason.
So a repository is never a "Nexaji repository", and nothing is ever "hosted on Nexaji". If you see the company name where a product name belongs, it is a mistake rather than a distinction you have missed.