Invite people

rig share alice@example.com --role editor

Or for a quick capability link to copy-paste:

rig share --ops read,write,subscribe    # role-less, pure-capability link

rig share auto-enables [sync] and binds the rig the first time you run it, so this is also how you go live. (Bare rig share with no arguments just prints current access — it's an alias of rig who and doesn't bind.)

Prerequisites

You must be the binding's owner (the person who first ran rig share).

What you get

An invite URL of the form:

https://tap-relay.fly.dev/v1/invites/<secret>/accept

Send the URL via your channel of choice (Signal, email, paste in the team chat). The recipient runs:

rig login                       # one-time, if they haven't already
rig join <invite-url>

See Join for the receiver's side.

Member invites vs. pure-capability invites

Two flavors:

Member invite (rig share <email> --role editor|viewer): the joiner is attached to binding_members with that role. You can later kick them with rig unshare <email> or change their role with rig role. Requires the joiner to have a Rig Hub account.
Pure-capability invite (rig share --ops …, no role): the joiner gets a device credential bound to the invite but no member row. Good for external collaborators who shouldn't need a Hub account. They can pass --anonymous to rig join. To remove their access later, revoke the invite with rig unshare <id> — the cascade kills their token.

For internal team use, prefer member invites. --role and --ops are mutually exclusive.

Flags

Flag	Default	What
`<email>`	none	Bind the invite to a specific email; the joiner must be authed as that email.
`--role <r>`	none	`editor` or `viewer`. Creates a member invite.
`--ops <list>`	none	Capability ops, e.g. `read,write,subscribe` or `read,subscribe`. Creates a role-less pure-capability invite.
`--path <glob>`	all shared	Scope a capability invite to specific paths (repeatable).
`--expires <duration>`	none	e.g. `24h`, `7d`. Default: no expiry.
`--max-uses <n>`	1 (with email), unlimited (without)	How many times the invite can be consumed.
`--label <str>`	none	A human label shown in `rig who`.
`--new`	—	Rotate an existing pending invite (issues a fresh secret URL).
`--enable`	—	Force-enable `[sync]` if it was set to `enabled = false`.
`--json`	—	Machine-readable summary.

A duplicate rig share <email> returns alreadyExisted: true, url: null (the secret is shown only once, at mint time) — pass --new to rotate it.

Examples

Add Bob as an editor (member invite):

rig share bob@example.com --role editor --label "bob — Q2 research"

A read-only viewer that expires in 24h:

rig share reader@example.com --role viewer --expires 24h

An external contractor as a pure-capability link, single-use:

rig share --ops read,write,subscribe --max-uses 1   # no role; pure-cap

A read-only, path-scoped link for your team (3 uses, no member rows yet):

rig share --ops read,subscribe --path "data/**" --max-uses 3 --label "Team Q2"

List outstanding invites

rig who

members
  owner    alice@example.com
  editor   bob@example.com

invites
  id           label              ops    uses     expiry
  inv_a1b2c3   bob — Q2 research   rw    0/1      —
  inv_x9y8z7   Team Q2             ro    1/3      —

Revoke

rig unshare <inv_… | email | label>

Future rig join attempts using that invite are refused. The cascade also revokes every capability token that was minted via this invite — so already-joined pure-capability collaborators are kicked off immediately. Member collaborators (those who joined with --role editor or --role viewer) have a binding_members row that survives invite revocation; to kick a member, pass their email to rig unshare instead. An ambiguous email/label returns error.code = "ambiguous_target" with candidates.

Authoring guidance

Use member invites for teammates. --role editor creates a real membership you can manage later (downgrade, kick) without re-inviting.

Use pure-capability for one-offs. Contractors, external reviewers, or "I just want to share this with a friend for an afternoon" — use --ops and revoke the invite when you're done.

Use --ops read,subscribe for read-only collaborators. Auditors, observers, anyone who shouldn't be editing. Or --role viewer for internal read-only members.

Use single-use invites for named people. rig share alice@example.com binds to Alice and consumes on her first join.

Use multi-use carefully. A multi-use, no-email invite is essentially a team password. Treat it like one.

Label everything. Future-you (and rig who) will thank you.

Boundaries

An invite alone doesn't give file access — the joiner still needs the URL to be valid (not expired, not revoked, not exceeded --max-uses), and (unless the invite is pure-capability) needs to be signed in to Rig Hub.
Invites with write give full edit privileges on the shared files. They are not partial-access tokens unless you scope them with --path.
The invite URL contains a single-use secret. Don't post invites publicly.