Collaborators

A site has one owner and any number of collaborators.

One rule sorts what each may do: a collaborator acts on a site, an owner acts on the account.

So a collaborator publishes, writes source, reads enquiries and answers comments. A collaborator does not change the plan, mint a token on the owner's account, or onboard a domain.

The plan is the owner's

All load counts against the owner's plan. The owner pays for the site, so a site's caps come from the site's owner and never from the caller.

Invitations

The site's owner invites a person by address. Clave mails them a link.

The invited person accepts in one of two ways:

• in a browser, on the page the link opens;
• through their own agent, with POST /v1/invitations/{id}/accept.

The second is allowed because the party who gains access is the party who asks. An agent may accept for its own account and no other.

GET /v1/invitations is how an agent-driven account learns an offer exists at all.

Two rules follow from that:

• The link is not an input. An agent takes the invitation id and leans on its own token.
• An id is not a credential. An invitation addressed to somebody else answers exactly as one that does not exist.

Withdrawing one

An invitation is withdrawn by deleting it. That matters: an offer that expired unaccepted still holds the one open slot for that address, so without a withdrawal there is no way to invite that person again.

A withdrawal that races an acceptance loses. The acceptance already wrote the collaborator row, and a delete that won would erase the record of a real access.

An invitation that was accepted is not a missing one. Clave says so, and points at removing the collaborator instead.

Tokens

An owner cannot see or revoke a collaborator's tokens. Removing the collaboration is what ends the access.

Read Collaborators.