Collaboration

A repository on Rinko Hub is owned either by a person or by an organization. Ownership decides who administers it and who can be granted access to it. This guide covers organizations, teams, members and repository access, and ends with the distinction that matters most: how hosted access control relates to the encryption-based privacy described in the privacy guide.

Organizations

An organization is a shared owner. Repositories it owns are administered by its members rather than by one individual, and its name is the owner half of an owner/repo reference — exactly where a personal handle would otherwise sit.

Organizations have their own visibility, public or private, and a join policy that decides how people get in: invite-only, request-to-join, or open.

Members

People join an organization by invitation, or by requesting to join where the join policy allows it. Both are handled in the Rinko Hub web interface. An invitation is accepted once and only once — accepting is atomic, so two clicks on the same invitation cannot produce two memberships. An approved join request always grants the base member role, never anything higher.

Teams

A team is a named group of organization members that can be granted access to repositories as a unit. Teams belong to an organization, and a team can only be granted access to repositories that same organization owns — a grant that crosses an organization boundary is refused.

Team access is resolved when access is checked, rather than being copied onto each member. Adding someone to a team grants them its repository access immediately; removing them, archiving the team, or their leaving the organization withdraws it just as immediately.

Roles and access

Rinko Hub has two separate role systems: one for the organization, and one for each repository. A role in the first does not substitute for a role in the second, though an organization role does establish a baseline.

Organization roles

Three roles are built in — owner, admin and member — and an organization may define custom roles beyond them. Roles are ranked, and the rank is what prevents privilege escalation: you cannot invite someone at or above your own rank, define a role that ranks at or above your own, or grant a permission you do not hold yourself. A custom role can never rank above the built-in admin tier.

What a role may do is expressed as a set of named permissions rather than hard-coded per role — viewing the organization, inviting members, removing members, managing roles, creating repositories, managing repository access, transferring ownership, deleting the organization, and others. Custom roles are assembled from that same catalog.

Repository roles

Access to an individual repository is one of five roles:

When several sources grant access, the strongest wins, resolved in a fixed order: outright ownership first, then an access grant made to you directly, then the strongest role any of your teams confers, and finally the baseline your organization membership provides.

Visibility

A repository is public or private. A private repository is hidden from people without access rather than refused to them: they are told it does not exist, not that they lack permission. This is deliberate — a refusal would confirm the repository exists, which for a private repository is itself information worth withholding.

Access from the CLI

Your account's access governs what the CLI can do. Listing what you can reach is verified behaviour:

$ nexa repos

ID	OWNER	SLUG	VISIBILITY	PROVISIONING
rh_repo_…	acme	capture-demo	private	ready

Bring one into your Development Root with nexa get acme/capture-demo, using the owner/repo form — the owner is a personal handle or an organization name, and the CLI resolves it either way.

Two further commands connect local work to the platform. nexa publish creates a Rinko Hub repository from the recorded work in the current directory and publishes it — the code is live when the command returns — and nexa link <repository> associates work you already have with a repository that already exists on Rinko Hub. A published or linked repository is owned by whoever you publish it under, and takes its access rules from that owner.

How this relates to sealed content

Everything above is access control: Rinko Hub deciding which requests to answer. Sealed content is encryption: the file is unreadable without the key, whoever is holding it. They are independent mechanisms, and they fail in opposite directions.

Managing label access on Rinko Hub

Each repository has a Label access page, in the repository's own tab bar. It lists the labels the repository's policy declares, which devices hold a key for each, and who those devices belong to. From it you can grant a label key to a person's device, expand a grant across a team in one operation, and rotate a label to withdraw access. Every one of those actions is recorded in an audit trail you can read back on the same page.

Granting is deliberately a separate authority from the rest of repository administration. It belongs to the repository's owner and admin roles, and is not implied by being able to contribute work or to merge it: proposing and accepting changes is ordinary repository work, and neither should carry the authority to widen who can read a protected path.

Labels themselves are still created from the CLI, in the repository's .nexapolicy file — Rinko Hub distributes keys for labels that already exist, rather than defining them. See Privacy and file control for how labels and policy are written.