Product
Built around what the protocol actually does
Rinko Hub is code hosting for the Nexa protocol — a Git alternative whose repositories, workspaces and merges behave differently because the protocol underneath does. Every concept below maps onto a real, tested capability of Nexa, not a feature layered over it.
Candidates hold competing versions
A candidate is a named reference to a version, and a branch can hold several at once. When two devices or two people diverge, Nexa keeps both candidates and reconciles them the next time it syncs, rather than picking a winner and discarding the rest.
- Reconciliation is a union — devices and remotes converge on the full set of candidates, never a subset
- Fast-forward, already-current, and already-merged states are detected automatically
- Divergent work survives a sync intact, so two attempts at the same problem can both stay around until you choose between them
Merges operate on the object tree
The three-way merge engine works directly on the tree structure, so conflicts are reported by path and object identity rather than by comparing lines of text. Your working tree is the source of truth for resolution.
- Every outcome in the merge truth table is handled explicitly
- Sealed-tree conflicts are identified by label and object id, so contents are never decrypted just to diff them
- Resolving in your working tree is what continues the merge — there is no separate "mark resolved" step
Sealed content is a first-class state
Confidentiality is enforced by the protocol itself. A path sealed under a label is unreadable without that label’s key — for you, for a mirror, and for anyone forwarding it along the way.
- Five distinct states: accessible, sealed, key unavailable, sealed conflict, indeterminate
- A peer without a key can still store and forward sealed content without ever opening it
- Confidentiality is always visible in the interface — sealed content is shown as sealed, never as plaintext
A terminal that operates the whole application
The integrated terminal shares one action surface with every button and link in the product, covering the full application rather than just repository commands — it can navigate, search, open a merge, and post a comment.
- Persists across navigation — command history and output survive moving between pages
- goto, open, find, click, search, and repo-inspection commands, with autocomplete
- ⌘J toggles it from anywhere in the authenticated app
Real semantic structure throughout
Every page is built from labelled buttons, accessible tables, stable identifiers, and 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.
- Important state is never hidden behind hover-only affordances or canvas rendering
- Interactive elements carry stable data attributes for automation, alongside their class names
- The terminal and the UI call the same underlying actions, so nothing behaves as a special case
Redundancy is the default write path
Every backend layer — identity, data, and sync — writes to more than one independent service as its normal write path. A change is confirmed once it's landed durably, and a second copy follows immediately after.
- Reads fall back automatically to a healthy provider when one is slow or unreachable
- A provider outage is logged and retried rather than silently dropped
- Sync reconciliation preserves divergent work rather than overwriting it to resolve a conflict