Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Security and Safety

zhiar edited this page May 29, 2026 · 1 revision

Security & Safety

Apricity is designed to run on a single trusted machine, bound to 127.0.0.1, against a MemPalace install owned by the same user. Two separate concerns: authentication (who can use it) and the safety model (how it avoids destroying your data).

Authentication

Setting it up

Apricity starts in open setup mode — until you create credentials, anyone who can reach the port can use it. Create a login immediately on first run via Settings → Account (see Installation).

How credentials are stored

  • Passwords are hashed with PBKDF2-HMAC-SHA256 (200,000 iterations).
  • The hash lives in MEMPALACE_CREDENTIALS (dashboard-credentials.json), written with mode 0600.
  • Credentials never leave the host.

Sessions

  • Sessions are stored server-side in MEMPALACE_SESSIONS; the browser only holds a cookie.
  • The cookie is HttpOnly + SameSite=Lax.
  • A normal login lasts 12 hours; "Remember me" extends it to 30 days.

Scripted access

For scripts, set MEMPALACE_TOKEN and send it as the X-Auth-Token header. It coexists with the cookie flow — it doesn't replace it. See the API Reference.

Forgot your password?

Delete the credential and session files, then restart — Apricity reverts to open setup mode so you can re-enroll. This does not touch your memories:

rm ~/.mempalace/dashboard-credentials.json ~/.mempalace/dashboard-sessions.json

Safety model

Apricity treats your palace as precious. Five guarantees:

  • No raw DB writes. Every mutation routes through the official mempalace Python package — Apricity never modifies the SQLite files directly. Reads go straight to SQLite (for speed); writes always go through the package.
  • Snapshot before destruction. Every delete (memory, room, wing, tunnel) is appended to the versions log before it happens, so it's recoverable from Recently deleted.
  • ETag concurrency. The editor records the content hash it opened with and sends it back on save; if the memory changed underneath you, the server refuses the overwrite. No silent clobbering.
  • Confirmation values. Bulk deletes (room/wing) and trash purges require typing an exact confirmation string.
  • Loopback by default. The server binds to 127.0.0.1. Nothing is exposed to the network unless you deliberately put a proxy in front of it.

Hardening notes for operators

Even though Apricity is local-first, you can tighten further:

  • Keep it on 127.0.0.1 and reach it remotely via SSH port-forwarding or a Tailscale/WireGuard tunnel rather than binding to a LAN-visible address.
  • If you must expose it, put it behind a reverse proxy (Caddy, nginx, Tailscale Serve) that terminates TLS and forwards to the loopback port. Never expose the raw port to the public internet.
  • Put MEMPALACE_CREDENTIALS and MEMPALACE_SESSIONS on an encrypted volume (both are mode 0600).
  • Rotate MEMPALACE_TOKEN when scripted access ends.
  • Periodically prune MEMPALACE_VERSIONS (or enable auto-delete) if it holds snapshots you no longer want recoverable.

Reporting a vulnerability

Please don't open a public issue for security reports — see the repo's SECURITY.md for the private disclosure process.

Next: Troubleshooting & FAQ .

Clone this wiki locally

AltStyle によって変換されたページ (->オリジナル) /