Glossary — Nexa and Rinko Hub terms

Repository (Project) Git: repository: One object database, one set of references, one unit of synchronisation. “Project” is the user-facing word for what the protocol calls a repository; grouping several of them is a Rinko Hub concern, not a protocol one.
Object and content addressing Git: blob / tree / commit objects: Every file, tree and version is an immutable object identified by the hash of its content (BLAKE3). Identity is fixed before compression and encryption, so recompressing or re-encrypting a repository never changes an identifier. Nothing is rewritten in place; correction means adding a new object.
Version Git: commit: A complete, selectable state of a workspace: a whole tree plus who created it and when. There is no staging area — `nexa record` captures the working tree as it is. A version is a first-class alternative, not a transient state.
Branch Git: branch (loosely): A named context that holds a set of competing candidates rather than a single pointer. Selecting a candidate supersedes the others without deleting them. Structurally, a branch is a parentless workspace object; workspaces within it name it as their parent.
Workspace: A development context inside a branch in which several competing versions coexist — one workspace per problem, one version per attempt. A workspace has an explicit owner and members, its own visibility, and cannot contain another workspace. Deriving a workspace from another creates an independent sibling that records where it came from.
Candidate: A version offered as a possible answer within a branch or workspace. Two people, or two agents, attempting the same task produce two candidates; reconciliation keeps both. Rinko Hub shows a candidate count wherever there is more than one.
Selected version Git: branch tip / HEAD: The candidate a branch or workspace currently points at — its accepted state. Selection is a mutable reference, never a property of the version itself, so choosing differently later changes nothing about the objects. A branch that has selected nothing has no accepted state, and Rinko Hub says so rather than showing some workspace’s work as if it were accepted.
Label and label key: A named protection class for paths. Each label has its own key; a path assigned to a label is encrypted under that key, and everything labelled X is readable by holders of X’s key. Labels are referenced publicly by an opaque identifier — the human-readable name is itself encrypted, because “acquisition-2026” beside a filename can reveal more than the file.
Sealed content: What a labelled path looks like to someone without the label’s key: the object exists, is stored, verified and forwarded, but its name and contents are inside the ciphertext. A public tree shows that something is sealed and under which label, never what it is called. Rinko Hub renders it as “Sealed file” or “Sealed directory” with no name, because it has none to show.
.nexapolicy Git: .gitattributes (distantly): A tracked file at the repository root that binds paths to labels: which paths are protected. It names labels and never carries keys, so editing it grants nothing, and precedence is fixed rather than positional — an exact path beats a subtree rule and a deeper subtree beats a shallower one. `nexa policy show`, `check` and `explain` read it.
Reconciliation (sync) Git: push / pull: The one synchronisation primitive. Two peers exchange the objects each lacks — trivially convergent, since an object either exists or does not — and then reconcile references by taking the union of candidates. Divergence produces an additional candidate, never a rejection and never a silent overwrite. `fetch`, `push`, `pull` and `sync` are vocabulary over this single engine.
Merge Git: merge: A three-way merge that operates on the object tree, reporting conflicts by path and object identity rather than by comparing lines of text. The working tree is where resolution happens, and continuing the merge is what records it; a sealed conflict is identified by label and object id without decrypting anything.
Remote Git: remote: An address and a device identity — the identity is required, because the authenticated handshake needs the peer’s static key in advance, which is what stops anything substituting itself in the middle. A Rinko Hub hosted repository is a remote recorded by repository identity rather than by server address.
Device identity Git: SSH key (loosely): The key that authenticates a machine to its peers. It secures transport; it does not vouch for who authored a version, which is recorded separately as a claim. `nexa device protect` wraps the key with a passphrase at rest; `nexa login` authorises a device against Rinko Hub in a browser.
Development Root Git: the folder you keep your clones in: One directory, declared with `nexa root`, that holds everything you are actively working on. Only the root carries `.nexa/`; each project beneath it is an ordinary directory you can open, edit and search like any other. It replaces keeping every repository in its own isolated folder.
Working context Git: worktree (loosely): One repository, one branch, one workspace, materialised as a directory inside a Development Root. Bring one in with `nexa get`, list them with `nexa contexts`, remove one with `nexa drop`. Two contexts of the same repository can sit side by side on different workspaces, and neither can change the other’s working files.
Agent: An AI tool working in a repository. Today an agent uses the same Nexa CLI as a person: give it its own workspace within a branch, and the versions it records are candidates like anyone else’s, which a person reviews and selects. Agent-specific identities and scoped capabilities are planned, not yet available.