Security boundaries

memories 0.1 is development software. Do not treat a passing test suite as an independent security audit or a production security certification.

Protected against

A vault-sync relay reading or forging asset contents, substituting a peer identity after deliberate fingerprint verification, or modifying authenticated ciphertext.
Reading a copied local database without the local password or, when deliberately enrolled, the separate unattended wrapping key. The mobile local factor additionally depends on the platform secure storage.
A reader forging writes, an administrator changing ownership, or a revoked device using its user identity key to issue itself a new authorized device.
Ordinary CLI/MCP accidentally printing a stored credential, accepting a password on a command line, or allowing an MCP capability to inherit terminal elevation. Deliberate unattended credential reads intentionally deliver plaintext bytes.
Undetected modification of signed revisions or audit entries, chain gaps, and checkpoint truncation relative to the remaining current database state.

Deliberate limits

Optional Center hosted mode (memories-center --data) is a separate server-side encrypted vault, not end-to-end encrypted device storage. The operator-held MEMORIES_CENTER_VAULT_PASSWORD opens the daemon-format Store; host operators and anyone with the password plus disk can read all hosted plaintext. Hosted grant RPC is a closed vault-content surface with operation-local elevation, including private/file/protected writes and deliberate credential delivery. Daemon MCP remains unelevated and unchanged. Admin bearer alone cannot use vault APIs, but administrators can mint separate scoped grants or durable members. Hosted admin lock drops Store keys; unlock requires the operator password over trusted HTTPS. Durable member tokens in owner-only members.json are plaintext credentials, not vault keys: protect their files, backups and one-time responses. A Center-issued unlock ticket does not escrow the device password or elevate device/MCP privileges. SaaS-configured daemon clients share the injected hosted bearer; local MCP capabilities cannot inherit it. Legacy note migration retains a plaintext memories.json.bak; protect/remove it after verification. See docs/center.md for the complete threat model and intentional differences.
Compromised endpoints, OS administrators, malicious authorized programs, memory inspection, keyloggers and users deliberately copying plaintext are outside the confidentiality boundary. Rust key buffers are zeroized where owned; OS swap, crash dumps, dependency allocations and Dart garbage-collected strings are not guaranteed to be erased. Desktop unattended custody has Windows DPAPI, macOS Keychain, Linux Secret Service and owner-file backends. These provide OS-account protection, not a hardware-backed custody guarantee; owner-file stores its wrapping key as owner-only plaintext. Hardware-backed desktop custody is not guaranteed by any shipped backend.
The relay can observe traffic metadata, block connections, keep its own recording of ciphertext, delay revocations or partition the fleet. The shipped server writes no assets, but a malicious server cannot be forced not to record traffic. Vault peer sync (/v1/channel) is end-to-end encrypted. Remote daemon relay RPC (/v1/rpc/{room}/{slot}) instead carries authenticated JSON: the relay or TLS terminator can read the shared listen token and request/response payloads.
Offline revocation cannot erase past plaintext, keys or backups. An endpoint that has not received a revocation can still use its old local copy. Export to a known-revoked device is blocked and new epochs use fresh keys. Revocation also drops queued cloud exports and invalidates captured work before the next object operation. A network request already started cannot be recalled.
Audit proves signed content and continuity relative to known state, not that a compromised device recorded every access. Replacing the entire database and all local evidence with an older consistent backup cannot be detected without a newer peer checkpoint or external anchor. No trusted timestamp service exists.
Failed operations are audited when a usable authorized local signing identity is unlocked. Attempts while fully locked are rate limited but do not create a persistent signed audit record. Abrupt crashes leave previously committed delivery/execution intents rather than inventing outcomes.
A same-user process is inside the local OS account boundary. IPC authenticates the OS user; terminal elevation additionally uses the parent PID. This is not isolation from a malicious process running as that same user, nor a durable session identity immune to PID reuse. IPC accepts up to 16 concurrent clients. Windows named-pipe framing remains blocking: stalled same-user clients can occupy those slots, but one stalled client or cloud transfer does not block all other connections. Unix frame I/O has bounded deadlines. Service operations that hold the writer lock, including trusted child execution, still serialize. Run bindings are the exception: the service authorizes, decrypts and audits under the lock, then releases it while the bound program runs.
Run bindings (credential bind) are a deliberate, sudo-authorized widening of the elevation boundary for one program. While a binding is unexpired (default 8 hours, at most 720) and the store is unlocked, any same-user cli: caller can run that program with its bound credential without elevation. Those callers receive the program's output with exact occurrences of the credential replaced, not the credential, but the program, its plugins/extensions and its descendants receive the plaintext and can disclose it (encoded output, network, files). Bindings are device-local encrypted state, never synced, cleared on backup restore, and refused for MCP, remote (ws:/relay:), unattended and mobile callers. Deny rules are enforced by the service on the arguments the program actually receives; ask rules only by the Claude Code hook, which is a convenience router, not a boundary: a command it misses runs without the credential, and a same-user process can call run --binding directly (the hook also checks direct calls it can see). Put anything that must never run unattended in a deny rule.
Optional HTTP/WebSocket listen and relay RPC expose the same framed service::Request protocol after a shared secret is presented (WebSocket binary JSON: AuthFrame then Wire). The listen token is supplied only via --listen-token / MEMORIES_LISTEN_TOKEN (or generated and printed once); it is never stored in TOML. Comparison is constant-time. The token is wiped when the store locks. Remote callers use stable elevation namespaces ws:remote / relay:remote and cannot inherit a local terminal's cli:{pid} elevation; unlock/sudo over that transport elevates the remote namespace for subsequent one-shot connections. Desktop HTTP/relay hosts expose the ordinary local IPC operation set after unlock/sudo (including Run, CryptoJob, MCP grants, remote sessions, proxies, credential copy, and backup), subject to the same elevation checks. Token holders are therefore as powerful as an elevated local client on that host — protect the token accordingly. Mobile FFI and Share keep the mobile denylist (no Run/CryptoJob/MCP grant/remote/proxy on phone; Share also refuses credential plaintext copy and backup dumps). HTTP listen defaults to loopback; binding a non-loopback address requires --allow-non-loopback and prints a warning. Plain HTTP/WS needs no certificates; --tls-cert / --tls-key enable HTTPS/WSS when wanted. Relay RPC requires WSS for non-loopback relays, a 43-character high-entropy room id, and the listen token. Vault sync continues to use /v1/channel; direct RPC uses /v1/rpc and relay RPC uses /v1/rpc/{room}/{slot}. The restricted WebUI surface is separate and must not become a generic Request bridge.
Optional authorization Centers ([[centers]]) turn an endpoint into a Center-managed device: local self-bootstrap (init/restore) and local MCP grant minting are refused. Bootstrap and grants arrive as Center-signed tickets verified against configured public_key values. Grant tickets carry deliberate scopes (allow_all, read, write, read_write, read_write_delete); legacy write bool tickets map to read / read_write. Multiple Centers may be configured; any one is enough to forbid self-bootstrap. Vault password unlock remains local — Centers distribute policy, not vault keys. Protect Center signing secrets and admin tokens like root credentials. See docs/center.md.
Executable fingerprints are checked immediately before spawning. There is no OS sandbox, signed-code requirement, atomic file-handle execution, or descendant process containment. A trusted executable can load plugins or delegate work.
Clipboard copies of ordinary/private memory, deliberately copied credentials and exported files leave the encrypted store by user action. credential_copy is an deliberate local, sudo-authorized exception to credential output restrictions: its authenticated client receives UTF-8 plaintext for the system clipboard. CLI prints only copy status; mobile displays confirmation and success without rendering the secret. MCP cannot request copies. Clipboard contents persist after lock and can be retained by OS history/synchronization or other apps; there is no guaranteed clipboard erasure. credential generate creates key material inside the vault; its generation response and credential public return public keys or certificates, never private keys. Deliberate credential copying can deliver stored UTF-8 private key material to the clipboard under the same authorization boundary. RSA keys are 3072 or 4096 bits.
file exec is a CLI-side authorized file export followed by local execution, using the existing file-read permission and delivery audit. It cannot read credentials or widen MCP/mobile authority. The user-selected program receives a plaintext snapshot in an owner-only temporary directory, inherits the CLI environment and streams, and may disclose content without output redaction. No executable fingerprint is pinned, just as with manually executing an exported file. Lock/revocation cannot recall this copy. Normal child exit, spawn failure and handled interrupts trigger removal; forced termination, power loss or Windows console close can leave plaintext behind. Removal is not secure erasure. Only the direct foreground child is supervised, not detached descendants. File execution does not hold the daemon's service lock.
The HTTPS credential adapter supports Bearer and Cookie GET/POST and returns only status, not arbitrary response data. Daemon-owned SSH, FTP, TCP, MySQL, Redis and PostgreSQL sessions require sudo and per-instruction propose/approve/exec. Unapproved tickets cannot run. SSH host keys are pinned by SHA-256. SSH client authentication uses a stored password or an imported OpenSSH private key, and may attach a stored OpenSSH certificate. Encrypted private keys and SSH agent signing are not implemented. Credentials are not printed; remote output is bounded. MCP cannot open or approve remote sessions. Loopback SSH and database proxies are started with sudo, bind 127.0.0.1 only, and authenticate upstream with stored secrets so agents never receive keys. Any process able to connect to the local port can use the authorized remote account without per-command approval; loopback is not OS-user authentication. Local database traffic is plaintext. Lock, vault idle expiry and stop close listeners and active connections. Proxies expire after 30 minutes regardless of activity. MCP cannot start, list or stop proxies. Each proxy accepts at most 16 connections; authentication has a 30-second deadline and bounded handshake packets. Proxy database TLS uses rustls, including PostgreSQL/MySQL protocol negotiation. PostgreSQL SCRAM verifies the server signature. MySQL full SHA-256 password authentication is refused without verified TLS; RSA password exchange is not implemented. PostgreSQL cancellation/startup-option forwarding and MySQL compression are not supported. Database sessions use password authentication with TLS by default (hostname verification; optional extra PEM CA credential). --no-tls is deliberate. Certificate pinning and client certificates are not implemented.
Permissions apply to an entire vault. Readers can decrypt its assets; the client UI cannot enforce a cryptographic distinction between a member reading and copying content already granted to that member.

Unattended desktop authority

Unattended CLI/MCP is a separate, opt-in local bearer authority, not an ordinary MCP grant or sudo session. Enrollment requires an interactive terminal, typed ENABLE consent, password unlock and password sudo. Later reads need the deliberately selected client file, not repeated password prompts. Its vault scope includes ordinary and private memory/cards, original file bytes and live-vault history, including deliberately requested stored credential UTF-8 plaintext. Generic reads reject credentials; protected card references aren't automatically resolved. Quarantined revisions are denied. There is no asset mutation, execution, admin, sync, backup dump, search/model execution or OTP-counter advancement surface. Current device membership and grant scope are checked on each read; a signed delivery intent is saved before output, and audit/storage failure denies delivery.

The independent master-key wrapper retains password-based unlock/recovery. Its wrapping key is held separately through deliberately selected windows-dpapi (current-user DPAPI), macos-keychain (nonsynchronizing Keychain), or linux-secret-service (session-bus Secret Service). owner-file is an deliberate lower-protection option: plaintext wrapping material protected only by OS-account permissions. There is no automatic fallback. Startup reads don't request keyring unlock or authentication UI; unavailable, locked or approval-needed custody fails closed. A protocol client cannot control arbitrary provider-specific UI behavior. These backends don't establish secrecy against same-account processes or OS administrators, nor a hardware-backed custody guarantee.

Successful unattended startup loads keys while ordinary authorization stays locked. It doesn't unlock ordinary CLI/MCP, sudo, cloud or RAG operations. Manual lock clears keys and durably inhibits unattended startup across restarts; password unlock alone doesn't resume it. unattended resume requires password-authorized local terminal management. revoke durably removes one grant; disable disables authority and revokes all grants before backend cleanup. A failed durable lock write returns an error, so persistence can't be promised on an unwritable device. Already delivered plaintext can't be recalled by lock, revocation or disable.

The client file is a secret bearer capability, separate from ordinary MCP grant files, and bound to the selected store. The wrapping key is bound to the canonical store/header identity. Unattended authority isn't included in logical backups, device pairing or vault sync. Copying the entire raw database still copies its auxiliary wrapper/authority table; copying client files or custody material can also preserve authority. Whole-device rollback and secure erasure remain outside the guarantees. Keep these files out of source control, logs and shared backups.

Center-managed stores reject unattended authority. HTTP/WebSocket, relay RPC, mobile FFI/Share and WebUI can't use this route, even with ordinary elevation. Ordinary mcp serve --grant-file permissions and credential restrictions are unchanged. The separate mcp serve-unattended --client-file deliberately exposes secrets to the receiving client. Base64url is encoding, not encryption: AI providers, transcripts, tool logs and caches can retain or transmit decoded secrets or the encoded values. Read-only access doesn't make secret disclosure harmless.

Linux end-to-end coverage uses owner-file custody with the real daemon and CLI/MCP. The isolated Linux Secret Service protocol fixture isn't a live desktop keyring test. Windows DPAPI, macOS Keychain and live keyring/native no-UI validation remain release gates; independent review is pending. See usage and validation details.

Retrieval and model services

BM25 indexes and normalized vectors are bounded in-memory caches of authorized ordinary memory/cards. They are invalidated by policy/content changes and cleared on lock. Indexes never contain credential bodies or deliberately private content; file assets and unresolved/conflicting revisions remain excluded. Deliberately ingesting a text/Markdown document creates an ordinary knowledge card, so the operator must not import confidential text as public-to-the-vault ordinary data. SQLite temporary storage for search is forced to memory; cached content is not included in backups or cloud exports. Process-memory limitations still apply.

Local EmbeddingGemma runs in-process using a native inference library; its public model files are downloaded only by an deliberate installation command or supplied locally. ONNX telemetry is deliberately disabled before inference sessions are created. Built-in downloads pin a repository revision and verify every file by SHA-256 before publication. Model files have their own Gemma license. They are not secret material and are not an independently audited security boundary.

Configuring a remote embedding URL allows authorized RAG operations to send all eligible document chunks to that endpoint. Generation sends the question and selected source chunks; learned reranking sends its candidates. The customer must trust configured model providers and proxies. Model steps targeting non-loopback providers are rejected for device-only vaults before inference. Local inference and deliberately configured loopback services remain available. Ordinary MCP clients cannot choose provider URLs, credentials or proxy settings in tool arguments, and remain scoped to their grant's vault and ordinary-content permissions. API keys are referenced by environment-variable name, never literal config or CLI values. Failed HTTP response bodies are suppressed, and direct authentication-material echoes in generated answers are rejected; a malicious configured provider remains outside the local confidentiality boundary.

Remote model URLs require HTTPS; HTTP is allowed only on loopback. Model API redirects are refused. Loopback requests bypass proxies; other requests can use HTTP(S)/SOCKS proxies or the proxy environment. Retries are bounded and restricted to transient connection/read failures, HTTP 429 and selected 5xx responses. Retries may repeat model computation/billing. TLS validation is not disabled.

Model work does not hold the service writer mutex. Lock, expired/revoked grants or changed source state suppress late results and prevent subsequent steps. An in-flight request/inference can finish, and already disclosed remote text cannot be recalled. Retrieval sources are data, not instructions; generation has no application tools. Valid citation IDs do not prove an answer is factually grounded or eliminate prompt-injection risk from untrusted source text.

Desktop status dashboard

Local TOML configuration contains only non-secret storage/relay/desktop settings. Deliberate missing files, unknown keys and malformed values are rejected before opening a store. Relative storage paths are resolved beside the selected file. Changing the path selects another store and does not migrate data. Relay URL validation retains the existing remote-TLS and no-URL-credentials restrictions.

The optional WebUI listens only on 127.0.0.1. GET /api/status and the restricted POST /api/cards editor are protected by a random 256-bit token created for each process. The launcher puts the token in the URL fragment; the page removes it from the address bar, keeps it in tab session storage and uses an Authorization header. The full launch URL is a dashboard capability and should not be shared. Requests with an unexpected Host, foreign Origin or cross-site fetch metadata are denied. No CORS access, third-party resources or framing are provided. The status projection remains read-only. Card editing uses a separate deliberate allowlist in the sibling CLI, with at most four concurrent requests and a 1 MiB request limit. It permits ordinary card/type operations, not unlock, sudo, file reads, credential reads, secret reveal, grants or process execution. Private assets are checked before returning card content. Sensitive fields are masked and their internal structured body is never returned. Browser biometric/PIN enrollment is not implemented: verified native mobile/CLI paths handle sensitive values. The launch token now authorizes ordinary card writes and template CRUD; protect it accordingly. This is not a generic IPC bridge.

The local monitor probes the daemon through its normal authenticated IPC in a short-lived subprocess, with a three-second deadline to bound blocked Windows pipe reads. It clears details when probes fail; lock hides details on the next poll. Polling does not refresh unlock idle time or grant elevation. Desktop status remains unavailable to MCP capabilities. A malicious program in the same OS account remains inside the existing local trust boundary.

The tray can launch the local daemon through an deliberate menu action. Closing the tray/dashboard stops its HTTP listener and monitoring; it does not stop or unlock an independently running daemon. Authentication remains in the CLI.

Desktop cryptographic jobs

crypto_job requires local terminal elevation and a digest binding the exact public plan, input/tool fingerprints and credential references. MCP and mobile FFI cannot invoke it. Credentials must belong to the authorized vault. Signed intent is committed before external execution, and success/failure is audited. The toolchain remains inside the trusted OS-account boundary; executable hashing does not constrain libraries, helpers, child processes or network access.

Private keys/passwords are materialized as temporary files in an owner-only workspace (Unix permissions or a protected Windows DACL). Arguments contain file paths, never injected credential values. Tool output is suppressed. Normal cleanup removes the workspace and invokes GPG-agent/temporary-Keychain cleanup where applicable. Abrupt termination can leave plaintext or helper processes behind; there is no secure-erasure or process-tree-containment guarantee. iOS's temporary Keychain has an empty password and relies on workspace permissions. This is not hardware-backed key custody. Deliberately decrypted output is a plaintext file.

The first iOS adapter supports one provisioned .app with frameworks/dylibs, without nested apps/extensions or links. Code-signature verification does not verify Apple provisioning eligibility. OpenPGP output is detached signatures or encrypted data, not automatically assembled PGP/MIME. See cryptographic jobs for formats and platform limits.

CLI credential capture

catch requires the terminal's existing sudo session before prompting, reading stdin, or launching its deliberate source command. The service checks authorization again when storing the credential. Capture only imports into protected credential storage; capture itself doesn't expose credential read/export through CLI or MCP.

Command capture reads stdout only, closes child stdin, and discards child stderr. Captured text and parser errors are never printed. Failed commands, timeouts, oversized input, ambiguous regex results, and duplicate JSON object keys do not save credentials. Parsed JSON strings are cleared on success and on parse failure; dependency-owned scratch buffers remain subject to the memory limits above. The caller must trust the selected program: it retains ordinary OS permissions and may write its own files, logs, or network traffic. Timeout cleanup kills the direct child, not its descendants. Capture is deliberate input/command processing, not monitoring of other terminals or keyboard input. Existing source files and shell history are unchanged. Use synthetic data for tests and keep secrets out of command arguments.

Cloud authorization

Cloud login uses browser authorization code with PKCE and state validation. Mobile uses AppAuth and a registered native redirect; backgrounding locks the vault, and returning from the browser requires fresh local authorization before token exchange. Mobile access/refresh tokens stay inside Rust. Foreground sync runs outside the FFI registry and service locks; background lock invalidates late imports, token refreshes and responses. The CLI exchanges codes with fixed HTTPS endpoints outside the service mutex, then submits tokens through local authenticated IPC. The service requires a one-time, expiring ticket bound to caller/provider/client ID plus current sudo. Lock and logout invalidate tickets, including responses from in-flight network requests. The local CLI remains inside the trusted OS-account boundary.

OAuth tokens/client secrets are encrypted inside device-local state and excluded from exported backups, device pairing, vault synchronization, search, and MCP. Status exposes account metadata and expiry only. Logout removes local tokens, not provider-side consent or historic copies of the local encrypted database. Remote revocation uses the provider's connected-app settings. Account authorization does not grant vault access. An immutable-object runner queues and applies recipient-encrypted vault envelopes through OneDrive and Google Drive application folders. Provider adapters and token refresh are tested with local fixtures; live provider accounts have not been validated. Outbox/inbox receipts stay in encrypted device-local state and are excluded from backups, pairing packages, and MCP. Lock and logout invalidate in-flight transfer acknowledgements; incomplete jobs remain resumable after unlock. Cloud object names are ciphertext hashes, not vault titles or account identifiers.

Protected card boundaries

Protected card creation/replacement requires sudo and atomically stores a public metadata card plus a credential. Account passwords, dotenv values, HTTP tokens and OTP seeds never enter the ordinary full-text index. Dotenv previews mask every value with a fixed ***; generic reads and exports never return the secret. The deliberate local credential-copy operation also supports protected cards, including their seeds/tokens/passwords, under the clipboard boundary above. Ordinary MCP can search ordinary summaries but cannot create protected secrets, generate OTP codes or send authenticated requests. Metadata and full revision content remain encrypted at rest and during synchronization.

Website logins are a login protected card (public site URLs and username; the password is the stored credential). login_import requires sudo and a writable role; it normalizes browser CSV (parsed in crates/core), a read-only Firefox profile, the Windows Credential Manager, or a decrypted export into the same import path. Deduplication compares an existing login's decrypted password in constant time inside the service boundary; identical logins are skipped, a differing same-site-and-username login becomes a separate card unless --update is given, and a single import is capped (2000 rows). The browser note column is dropped unless deliberately requested, because notes enter the ordinary index. Firefox direct read supports only the modern PBES2 (PBKDF2-HMAC-SHA256 + AES-256-CBC) key4.db wrapping with 3DES-CBC login values and a known or empty primary password; the legacy 3DES-PKCS#12 wrapping is reported, not decrypted. Reading a browser's own store does not weaken that browser's protection and is subject to the OS-account boundary above.

login_export requires sudo and refuses device-only vaults. The encrypted format (memories/logins/v1) seals entries under an independent password with Argon2id and XChaCha20-Poly1305 and can be imported into any vault. The Chromium-compatible CSV format is plaintext that leaves the encrypted store: it is an deliberate local exception like credential_copy, allowed only for a local cli: caller (never MCP, HTTP/relay remotes, or mobile FFI/Share, enforced both by a caller allowlist and the mobile denylist), commits a signed delivery intent before returning plaintext, and writes an owner-only file with spreadsheet formula-injection defused. The operator must protect and delete that file.

TOTP and HOTP generation is an deliberately authorized output of a short-lived code, not a seed export. Generation is audited without the code or seed. HOTP persists the incremented counter with the card revision on each generation. Standard SHA-1 OTP support exists for interoperability; the application otherwise uses its existing modern authenticated-encryption and signing algorithms. TOTP requires a correct local clock. This client cannot prevent a verifier from reusing an accepted code. otpauth:// URI import accepts only totp/hotp types; otpauth-migration:// import decodes Google Authenticator MigrationPayload exports into totp/hotp cards only and never exposes the seed through search or ordinary MCP. Deliberate unattended credential reads can disclose the stored seed.

Client-controlled device-only vault IDs are persisted in encrypted state. Their contents are excluded from device pairing and exported backups, and sync/member export is denied. A machine compromise or a modified trusted client can bypass these application-level controls. There is no claim of secrecy against an authorized member who already holds a shared vault's cryptographic keys.

The template protects dedicated secret fields. Users must keep secrets out of ordinary titles, notes, tags and source fields. Import does not securely erase an existing dotenv file, clipboard contents or prior shell history.

Wiki secret references

protect_secret requires local sudo and write access. It atomically creates a credential and replaces all exact matches of the supplied nonempty secret in one current memory/card body with {{secret:LABEL}}. A typed, same-vault mapping resolves the label to its credential; the marker alone grants no access. Labels are 1-64 ASCII letters, digits, underscores or hyphens. A secret also present in metadata is rejected, as are conflicting documents and reused labels. Ordinary edits preserve the mapping; generic writes cannot attach or change references. Read, search, list, graph and MCP do not resolve these references. Copy resolves the current credential after authorization and commits an audit delivery intent without the secret before returning plaintext to the local client. This intent does not prove the subsequent OS clipboard write succeeded. Clipboard copies require UTF-8 without NUL bytes; copying an OTP card delivers its seed, not a generated one-time code.

Replacement affects only the current body, not signed revision history, recovery archives, other documents, backups or previously shared copies. It is not automatic secret discovery or provider-side key rotation. Already exposed keys must be revoked/rotated with their issuer. New protected references require updated clients; old clients cannot decode the added content field. See the usage guide for replacement rules and client behavior.

Resource and operational limits

Argon2id: 64 MiB, three iterations, one lane, 32-byte output; fixed versioned parameters, 16-byte random salt. No application-level password length restriction.
XChaCha20-Poly1305 with random 24-byte nonces; separate authenticated contexts for master keys, state, checkpoints, backups, transport and 256 KiB content chunks.
At most 16 MiB of encoded asset body per revision (binary imports have base64 overhead). The entire encrypted state is rewritten transactionally in SQLite; this is intended for small libraries, not multi-gigabyte file storage.
Full sync envelope: 32 MiB relay limit. Four simultaneous rooms, two peers each, bounded queues, 16 inbound frames/second, 60-second receive idle limit and ten-minute maximum connection lifetime. No offline delivery.
A busy trusted child process can occupy the local service for up to five minutes; a run-binding child occupies only its own IPC connection for that time. HTTPS operations have a 30-second timeout. Retention is append-only; audit/version pruning and incremental synchronization are deferred.
Permission conflict resolution requires the same owner to remain authorized on both branches. More complex ownership disputes fail closed and require an deliberate future recovery procedure.

Deployment

Bind the relay to loopback behind TLS. Disable reverse-proxy request/response body logging, disk buffering, core dumps and persistent container volumes. TLS protects transport metadata from intermediate networks; end-to-end encryption protects assets even from the TLS terminator. The sample container uses a non-root user.

Back up from the client. The relay is not a backup system. Keep the independent backup password separately and test recovery before relying on a backup.

Report security defects privately to the repository owner. Do not include real passwords, credential values, decrypted content or complete production packets in public issues.