You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Six months of research on MemPalace, and the one thing it couldn't do: a shared instance for a small group
#2680
Hello. I'm an independent researcher and I've run a ten-paper research project on MemPalace since the spring. I want to describe what it did for me, offer one thing back, and ask about one capability that doesn't exist yet.
What I used it for. The project (The Lagging Truth, laggingtruth.com) runs every paper through a fixed six-step verification protocol: register the question and the pass/fail test before touching data; seal the data with hashes; commit code so every printed number regenerates from a script; run an adversarial AI review that tries to break the paper; log every correction in public; date predictions before their outcomes. That work ran across hundreds of AI sessions over months. An assistant that forgets between sessions can't hold a protocol like that together: it loses which claim was already checked, which correction was already made, which hash was already sealed. MemPalace is where all of that lived, verbatim, and I don't think the project would have finished without it. The palace is about 140K drawers and 5 GB; most of that is imported conversation history (a raw-import wing of ~133K), with roughly 7K curated drawers across the research wings, organized as rooms per paper, plus a knowledge graph with time-bounded facts and agent diaries for session handoffs.
One thing I can offer back. A written set of requirements that a verification protocol places on its memory layer: verbatim not summarized, searchable, correctable only on the record (a correction is a new entry, never an edit), and portable/exportable. I'm writing these into a methods manual and would rather they match how you think about the tool than describe it from the outside.
What's already in the forum, and what isn't. I read the shared-memory threads before posting. #2671 (shanelord01, Oct 4) is a multi-machine hub: one brain, many clients, per-identity inbox cursors. #1856 (sefodo26) is a Go + PostgreSQL server fork with multi-tenant separation and API keys, now on the TechEmpower board. #1112 (perlowja) is an RFC for an export schema so a desktop palace can graduate to a team system. Between them, "many clients, one store" and "export to move elsewhere" are covered or in progress. What I don't see anywhere is the part a checking group needs: entries that are attributable to a person in a way that can't be repudiated, a formal layer that is append-only (a correction is a new entry, never an edit), and a periodic export-and-hash so the record can be fingerprinted. If I've missed a thread on that, please point me to it.
The capability that doesn't exist: one instance per group. The next step for this protocol is small groups (four to six people) checking each other's work, and the group's own deliberations recorded the same way as the research: who registered what, who filed which finding, who dissented, and what each decision predicted. For that, a group needs a single shared instance that several people's assistants write to and any member can retrieve later, with per-member attribution of every entry. As far as I can tell MemPalace is single-user by design, and I haven't found another tool that does this either. The pieces I think it needs:
a shared instance with membership and access control, and a notion of "a cell" in the data model;
an added_by that is signed or otherwise non-repudiable, and append-only semantics for the formal layer (opinions, findings, corrections);
a periodic export plus hash of the instance, so the record can be fingerprinted on a public ledger and nobody can later claim it was altered;
an open export/index format so that anyone can run their own retrieval assistant against the same record (retrieve-and-cite, never train on it).
For the first group test I'm planning to run the interim version: one instance, operated by a clerk who isn't a member, with each member's filings entered verbatim under their name, exported and hashed at each milestone. I'll log every bit of friction that causes and I'm glad to share that log here as design input, since it's the closest thing to a real-world requirements study for a group version.
Questions. Is a shared instance with signed, append-only entries anywhere on the roadmap, or is that deliberately out of scope for the core project? If out of scope, which of the existing routes would you expect it to sit on (the hub pattern in #2671, a server fork like #1856, or an export schema like #1112)?
Thank you for building this. It changed what one person can do.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hello. I'm an independent researcher and I've run a ten-paper research project on MemPalace since the spring. I want to describe what it did for me, offer one thing back, and ask about one capability that doesn't exist yet.
What I used it for. The project (The Lagging Truth, laggingtruth.com) runs every paper through a fixed six-step verification protocol: register the question and the pass/fail test before touching data; seal the data with hashes; commit code so every printed number regenerates from a script; run an adversarial AI review that tries to break the paper; log every correction in public; date predictions before their outcomes. That work ran across hundreds of AI sessions over months. An assistant that forgets between sessions can't hold a protocol like that together: it loses which claim was already checked, which correction was already made, which hash was already sealed. MemPalace is where all of that lived, verbatim, and I don't think the project would have finished without it. The palace is about 140K drawers and 5 GB; most of that is imported conversation history (a raw-import wing of ~133K), with roughly 7K curated drawers across the research wings, organized as rooms per paper, plus a knowledge graph with time-bounded facts and agent diaries for session handoffs.
One thing I can offer back. A written set of requirements that a verification protocol places on its memory layer: verbatim not summarized, searchable, correctable only on the record (a correction is a new entry, never an edit), and portable/exportable. I'm writing these into a methods manual and would rather they match how you think about the tool than describe it from the outside.
What's already in the forum, and what isn't. I read the shared-memory threads before posting. #2671 (shanelord01, Oct 4) is a multi-machine hub: one brain, many clients, per-identity inbox cursors. #1856 (sefodo26) is a Go + PostgreSQL server fork with multi-tenant separation and API keys, now on the TechEmpower board. #1112 (perlowja) is an RFC for an export schema so a desktop palace can graduate to a team system. Between them, "many clients, one store" and "export to move elsewhere" are covered or in progress. What I don't see anywhere is the part a checking group needs: entries that are attributable to a person in a way that can't be repudiated, a formal layer that is append-only (a correction is a new entry, never an edit), and a periodic export-and-hash so the record can be fingerprinted. If I've missed a thread on that, please point me to it.
The capability that doesn't exist: one instance per group. The next step for this protocol is small groups (four to six people) checking each other's work, and the group's own deliberations recorded the same way as the research: who registered what, who filed which finding, who dissented, and what each decision predicted. For that, a group needs a single shared instance that several people's assistants write to and any member can retrieve later, with per-member attribution of every entry. As far as I can tell MemPalace is single-user by design, and I haven't found another tool that does this either. The pieces I think it needs:
added_bythat is signed or otherwise non-repudiable, and append-only semantics for the formal layer (opinions, findings, corrections);For the first group test I'm planning to run the interim version: one instance, operated by a clerk who isn't a member, with each member's filings entered verbatim under their name, exported and hashed at each milestone. I'll log every bit of friction that causes and I'm glad to share that log here as design input, since it's the closest thing to a real-world requirements study for a group version.
Questions. Is a shared instance with signed, append-only entries anywhere on the roadmap, or is that deliberately out of scope for the core project? If out of scope, which of the existing routes would you expect it to sit on (the hub pattern in #2671, a server fork like #1856, or an export schema like #1112)?
Thank you for building this. It changed what one person can do.
Jae Kim · laggingtruth.com
All reactions