Seed Hypermedia uses a capability-based access control system that enables multi-writer collaboration without centralized permissions. Document owners can grant fine-grained access to collaborators using cryptographic capabilities — signed tokens that prove delegation authority.

Unlike traditional platforms where a central server decides who can edit, SHM collaboration is built on cryptographic proof. When you grant someone access, you create a signed capability that they present when making changes. No server needs to "allow" them — the math proves their authority.

This means collaboration works even in fully peer-to-peer scenarios. Two people on a local network can collaborate on a document without any internet connection or central authority.

A capability is a signed statement: "I (the owner) grant account X permission to do Y on resource Z." Capabilities are cryptographic — they can't be forged, and they travel with the data they protect.

Each capability contains:

Issuer — The account that created the capability (must be the document owner or have delegation rights)

SHM defines two collaboration roles:

Full editing access. Writers can create, modify, and delete documents within their capability scope. They can also create sub-capabilities to delegate access further (unless restricted).

Use cases:

Team members co-authoring documentation

Designed for AI agents and automated systems. The AGENT role provides write access but signals that changes come from an automated source rather than a human author. This helps readers and other systems distinguish between human-authored and machine-generated content.

Capabilities can be scoped to specific path prefixes, giving precise control over what a collaborator can access:

# Full account access (all documents)
Path: /

# Only the /guides subtree
Path: /guides

# Only a single specific document (with no_recursive=true)
Path: /guides/publishing

# The /projects subtree
Path: /projects

By default, capabilities are recursive — granting access to /guides also covers /guides/publishing, /guides/embedding, and any future documents under that path. Set no_recursive to restrict access to a single document.

To grant access, the document owner creates a capability specifying the delegate's account ID, the path scope, and the role.

In the Seed Hypermedia desktop app, open the document you want to share and use the collaboration panel to add editors. You'll need their account ID (the z6Mk... string from their profile).

For programmatic access, use the AccessControl.CreateCapability RPC:

grpcurl -plaintext -d '{
  "signing_key_name": "main",
  "delegate": "z6MkDelegate...",
  "account": "z6MkOwner...",
  "path": "/guides",
  "role": "WRITER",
  "no_recursive": false,
  "label": "Documentation team access"
}' localhost:55002 \
  com.seed.documents.v3alpha.AccessControl/CreateCapability

This returns a Capability object with a unique ID that can be referenced later.

View all capabilities for an account, or query by delegate:

# List all capabilities for an account
grpcurl -plaintext -d '{
  "account": "z6MkOwner..."
}' localhost:55002 \
  com.seed.documents.v3alpha.AccessControl/ListCapabilities

# List capabilities granted TO a specific delegate
grpcurl -plaintext -d '{
  "delegate": "z6MkDelegate..."
}' localhost:55002 \
  com.seed.documents.v3alpha.AccessControl/ListCapabilitiesForDelegate

When multiple writers edit the same document simultaneously, SHM uses Conflict-free Replicated Data Types (CRDTs) to merge changes automatically. There's no "lock" on a document and no merge conflicts in the traditional sense.

Each change to a document is recorded as a "change blob" — a signed, immutable record of what was modified. Changes reference their parent versions, forming a directed acyclic graph (DAG):

Initial Version (v0)
       |
    +--+--+
    |     |
  Alice  Bob
  (v1a) (v1b)
    |     |
    +--+--+
       |
  Merged (v2)
       |
   Alice (v3)

When Alice and Bob both edit concurrently, each creates a new version referencing the common ancestor. When either node sees both changes, the CRDT automatically merges them into a consistent state.

The CRDT handles different types of operations:

Block insertion — New blocks are placed in order based on their position hints and timestamps

Every change is preserved in the document's history. Unlike centralized platforms that may compact or discard history, SHM keeps the full DAG of changes. You can:

View the complete change history of any document

# List all changes for a document
grpcurl -plaintext -d '{
  "account": "z6MkOwner...",
  "path": "/my-document"
}' localhost:55002 \
  com.seed.documents.v3alpha.Documents/ListDocumentChanges

Grant WRITER access to team members at the root path. Everyone can create and edit documents, with changes merging automatically. The owner's account ID is the canonical URL — team members publish to the owner's namespace.

Use path-scoped capabilities to give external contributors access to specific sections only. For example, grant a guest WRITER on /community/guest-posts without exposing the rest of your site.

Use the AGENT role to let automated systems maintain documentation, archive content, or generate reports. The AGENT role ensures readers can distinguish automated contributions from human ones.

Anyone can fork a document using branching refs, make changes in their own namespace, and share them back. The original owner can review and incorporate changes — similar to pull requests in git, but for documents.

The capability-based system provides strong security guarantees:

Unforgeable — Capabilities are cryptographically signed; they can't be created without the owner's private key

Being honest about current limitations:

No read access control — All published documents are readable by anyone who has them. Access control only covers write permissions.

Related documentation:

Signing & Verification — How documents are cryptographically signed

Identity Verification — Cross-platform trust and key delegation

Branching & Refs — Forking documents and creating references

Agent Collaboration — Patterns for AI agent multi-authorship

Change Blobs — The underlying data structure for document changes