Deliver encrypted content

Workflow

Use client-side encryption for secret-key URLs or recipient delivery, and fetch ciphertext with the matching signed capability.

When to use it

Use this when

The server should not receive plaintext for the shared content.
A recipient has published a delivery key and should be the only account able to open the paste.

Steps

Do this

Choose a recipient model Secret-key pastes are opened by anyone with the full URL fragment. Recipient-sealed pastes are addressed to an account with a published public key.
Encrypt locally Use the web UI, CLI, or an MCP client that encrypts before calling create_encrypted_paste.
Store metadata with ciphertext Encrypted creates include cipher and cipher_meta so authorized clients can decrypt out of band.
Read through the right surface Use get_encrypted_paste or the recipient inbox for ciphertext; raw plaintext URLs are null for encrypted pastes.

Examples

Copyable commands

CLI secret-key

pbca new --mode secret-key --file incident-notes.md --expires 3d

CLI recipient delivery

pbca new --to-recipient @teammate --file handoff.txt --expires 7d
pbca inbox

MCP recipient shape

lookup_recipient_public_key({ "recipient": "@teammate" })
create_encrypted_paste({
  "access": "e2e",
  "recipient": "@teammate",
  "ciphertext_b64": "...",
  "cipher": "sealed-box-x25519-aesgcm-v1",
  "cipher_meta": { "eph_pub": "...", "nonce": "...", "recipient_key_updated_at": 1760000000000 }
})

Operational notes

Keep in mind

Public feed visibility is not available for encrypted pastes.
Recipient public-key lookup is implemented, but plaintext MCP recipient-send convenience remains a deferred trust-model question.