Interest in contributing — mempalace fork maintainer, production palace for testing

[jphein]

Hey — congratulations on shipping palace-daemon. The multi-client coordination problem (bulk mine starving interactive queries, multi-machine access, fairness under load) has been in the upstream mempalace backlog for a while — see MemPalace/mempalace#904, #357 — and it's good to see someone took it seriously.

I maintain jphein/mempalace, a production fork of MemPalace running a ~165K-drawer palace in daily use since 2026-04-09. A few things we've been building that might intersect with your roadmap:

• ThreadPoolExecutor-based mining (MemPalace/mempalace#1088) — single-client --workers N for cold mines, ~5× speedup on our palace. The semaphore-lane pattern you're using for mine coordination is exactly what I'm trying to apply in-process.
• ChromaDB hardening stack — quarantine_stale_hnsw (merged in MemPalace 3.3.2), _get_client() get-then-create guard (#1089), .blob_seq_ids_migrated skip marker (#1090). Your correctness-floor claim (">=3.3.2") aligns closely with where the internal-reliability work lands.
• Deterministic silent save hooks (MemPalace/mempalace#673) — externally approved, waiting upstream merge. Decouples save reliability from "AI remembers to call MCP tools."

Wanted to open an issue rather than land code unbidden.

A few questions if you have a minute:

1. What's your next ~2-3 weeks of focus? (Happy to avoid duplicating; also happy to contribute if it's in our wheelhouse.)
2. Is there a specific class of contribution that would be most useful right now — integration tests against real large palaces, docs, a particular feature, or something else entirely?
3. Any known pain points when running palace-daemon against a bigger palace? We have a ~165K-drawer one handy for real-world stress testing if that'd help.

Either way — thanks for architecting this as a coordination layer rather than forking the storage. That's the right shape.

— JP / jphein

[rboarescu]

Hi @jphein, thanks for reaching out!

I'm very grateful for the generous feedback. Serves as a great motivator that I may be on the right track(we humans do love validation).

First off, I should mention that this is actually my first open-source project and I’m quite new to GitHub, so
I’m still learning the ropes of maintaining a repository. This is a side hobby for me rather than my main job, so my time for it is limited, but I’m very excited to see interest from a power user. It’s impressive to hear you're running a 165K-drawer palace — that’s a fantastic stress test for palace-daemon.

Regarding the next few weeks:

• Stability & Hardening: This is the top priority. I just pushed a fix to handle port conflicts (using fuser in the systemd unit) to ensure the daemon restarts cleanly after improper shutdowns.
• API Maintenance: Keeping the _READ_TOOLS registry in sync with upstream MemPalace.
• New Endpoints: I'm considering a /reload endpoint to refresh internal state without a full service restart.

The most valuable contribution right now would be performance data at your scale. If you could run /stats or the mempalace_status tool against your 165K palace and report back on latency or any stability issues, it would be incredibly helpful. I’m curious to see how the metadata batching (currently 1000-item chunks) performs at that volume.

Also, huge congrats on getting PR #673 merged into upstream MemPalace yesterday! I was following that closely and I'm excited to integrate support for the silent save hooks now that they're official.

For now, since I'm still settling on the API surface and learning how to manage the project, opening a Discussion rather than a PR is the best way to coordinate. That way we can align on things before you spend time on code.

Looking forward to your findings!

[jphein]

Thanks for the thoughtful reply, and congratulations on the first open-source project — palace-daemon doesn't feel like a first at all. The architecture is tight, the scope is clean, and "coordination layer, not storage fork" is the decision most first projects get wrong.

(On the validation front: consider yourself validated. The problem you picked has been in the community backlog for months, and you shipped something working.)

Happy to run the benchmark. I'll kick off mempalace_status against the 165K palace tonight or tomorrow and come back with the metadata-batching latency profile and anything else that surfaces. Will open a Discussion rather than filing issues unless something breaks cleanly.

Thanks for the #673 congrats, by the way — good timing from bensig, merged yesterday after the silent_guard default question cleared. If you want integration pointers when you wire it up: the silent-save architecture is config-flag-gated (hook_silent_save: true is the upstream default now), so you can start from the flag-on behavior and layer a block-mode fallback for users who explicitly toggle it off. The deterministic path is strictly safer (save marker only advances after confirmed write), so no new failure modes over the pre-#673 flow. No hurry — integrate on whatever timeline fits.

Looking forward to reporting back. Keep going.

— JP

[jphein]

Moved this benchmark report over to a Discussion so the numbers stay referenceable without cluttering this thread: discussions/3.

TL;DR: 165,981 drawers, ~9.9s mempalace status wall time (stdev ~0.4s over 3 runs), no errors, no HNSW drift, no SQLITE_MAX_VARIABLE_NUMBER. Full numbers + a note on your 1000-item chunk sizing at the Discussion link.

— JP