Members

rig who, rig role, rig unshare — list, change roles, and revoke on a shared rig.

A binding's members are the Rig Hub accounts attached to it, each with a role: owner, editor, or viewer. Three verbs manage that list:

rig who                            # list members, invites, scoped tokens
rig role bob@example.com viewer    # change role
rig unshare bob@example.com        # kick (revoke a grant)

List

rig who

members
  owner    alice@example.com   usr_h7t9p3
  editor   bob@example.com     usr_2nq8mx
  viewer   carol@example.com   usr_v4r1ka

invites
  inv_a1b2c3   bob — Q2 research   rw   0/1   —

Anyone on the binding can run this — visibility into who else is on a shared rig is a basic collaboration affordance, not an owner-only one. rig who also surfaces pending invites and scoped capability tokens. (rig status --verbose embeds the same listing.)

--json for machine-readable:

rig who --json | jq

Remove

rig unshare <email | userId | inv_… | label>

Owner-only for members. rig unshare is polymorphic — it revokes whatever the target names: a member, a pending invite, or a scoped capability token. For a member, in one transaction the relay:

Deletes the member row from binding_members.
Revokes every capability token that user held on this binding.

The next sync request from any of their devices gets 401 immediately. Their local file copy stays intact — sync just stops.

If the target is ambiguous (e.g. a label matching several grants), the command returns error.code = "ambiguous_target" with a candidates list; re-run with the specific inv_…/dev_…/usr_… id.

Boundaries

You can't remove the binding's owner — the relay returns 400 cannot_remove_owner. Transfer ownership first (the ownership- transfer flow isn't built yet; it lives on the roadmap).
Removing yourself works the same way for non-owner roles — useful if you want to "leave a binding I was added to without coordinating with the owner." (For your own local disconnect, prefer rig disconnect.)

Change role

rig role <email | userId> <editor | viewer>

Owner-only. Role must be editor or viewer. owner is rejected with owner_transfer_unsupported — there's no role-change path to or from owner.

Roles map to capability ops:

Role	read	write	subscribe
`owner`	✓	✓	✓
`editor`	✓	✓	✓
`viewer`	✓		✓

The owner role additionally gates management operations: minting invites, revoking invites, removing members, changing roles.

Downgrades take effect immediately

The capability token in the demoted user's .rig/tap-binding.local.json doesn't change — but the relay intersects the token's stored ops with the user's current role on every sync request. So if Bob was an editor and you set his role to viewer, his next write request fails with 403 role_lacks_op. Reads keep working. He doesn't need to rotate his token or re-run rig join.

Boundaries

Changing to/from owner is refused with owner_transfer_unsupported.
Promoting a non-member doesn't make sense — they need to accept an invite first to land in binding_members.