Candidates, not branches

Nexa has no single moving pointer to force-push over. A candidate is a named, competing reference to a version — multiple candidates can point at divergent history at once, and nothing is silently overwritten by a sync.

  • Union-never-overwrite reconciliation across devices and remotes
  • Fast-forward, already-current, and already-merged are detected automatically
  • Divergent work always survives a sync — it never disappears to make room for someone else’s push

Tree-level merges, not line markers

The three-way merge engine operates on the object tree, not on lines of text. Conflicts are reported by path and object identity — your working tree is the source of truth for resolution, with no <<<<<<< markers to strip out afterward.

  • Every conflict outcome from the merge truth table is handled explicitly
  • Sealed-tree conflicts are identified by label and object id — contents are never decrypted just to diff them
  • Resolve locally, then continue — no separate "mark resolved" step

Sealed content is a first-class state

Confidentiality lives in the protocol, not a permissions table bolted on top. A path sealed under a label is unreadable without that label’s key — for you, for a mirror, and for anyone forwarding it.

  • Five distinct states: accessible, sealed, key unavailable, sealed conflict, indeterminate
  • A keyless peer can store and forward sealed content without ever opening it
  • Never shown as fake plaintext — confidentiality is visible, not silently hidden

A terminal that operates the whole application

The integrated terminal isn't limited to repository commands. It shares one action surface with every button and link in the product, so it can navigate, search, open a merge, and post a comment — anything the mouse can do.

  • Persists across navigation — command history and output survive moving between pages
  • goto, open, find, click, search, and repo-inspection commands, with autocomplete
  • ⌘J to toggle it from anywhere in the authenticated app

Designed to be readable by more than your eyes

Every page is built from real semantics — labelled buttons, accessible tables, stable identifiers, described disabled states — so the same interface a person uses is legible to a keyboard, a screen reader, and eventually an AI agent operating Rinko Hub on your behalf.

  • No important state hidden behind hover-only affordances or canvas rendering
  • Interactive elements carry stable data attributes, not just generated class names
  • The terminal and the UI call the same underlying actions — nothing is a special case

No single point of failure in the backend

Every backend layer — identity, data, and sync — is architected to run on more than one independent service, not as a disaster-recovery afterthought but as the default write path. A change is only confirmed once it's landed durably; a second copy follows immediately after.

  • Reads are designed to fall back automatically to a healthy provider if one is slow or unreachable
  • A provider outage is logged and retried, never silently dropped
  • The protocol itself never overwrites divergent work to reconcile a sync — nothing is silently discarded

See it against a real repository

Create your account