4 ms·

In this day and age, without serious evidence that the software presented has seen some real usage, or at least has a good reviewable regression test suite, sad

In this day and age, without serious evidence that the software presented has seen some real usage, or at least has a good reviewable regression test suite, sadly the assumption may be that this is a slopcoded brainwave. The ascii-diagram doesn't help. Also maybe explain the design more.

6r17 6mo ago
I kind of agree with the comment here that a lot of stuff happening around comes out from an idea without proof that the project has a meaningful result. A compacting memory bench is not something difficult to put off but I'm also having difficulties understanding what would be the outcome on a running system
- pranabsarkar 6mo ago
  I have been using the memory while building it. I have a central server and all my workspaces are connected to it via the MCP server. This changed everything for me. But that's me. Now I don't have to repeat things, the agent knows my preferences, can connect different projects I am working on without me asking and it knows my infra so can plan the test deployments and stuff on its own. That is somewhat I was aiming for.
pranabsarkar 6mo ago
Fair. "Does consolidation actually improve recall quality on a running system?" is exactly the benchmark I haven't published, and it's the one that would settle the question. What I do have right now: 1178 core unit tests including CRDT convergence property tests via proptest (for any sequence of ops, final state is order-independent) Chaos test harness: Docker'd 3-node cluster with leader-kill / network-partition / kill-9 scenarios (tests/chaos/ in the repo) cargo-fuzz targets against the wire protocol and oplog deserializer Live usage: running on my 3-node homelab cluster with two real tenants (small — a TV-writing agent and another experiment) for the past few weeks. Caught a real production self-deadlock during this period (v0.5.8), which is what triggered the 42-task hardening sprint. What I don't have and should: a recall-quality-over-time benchmark. Something like: seed 5,000 memories with known redundancy and contradictions, measure recall precision@10 before and after think(), and publish the curve. That's the evidence you're asking for, and you're right it's missing. I'll run that and post the numbers in a follow-up. The ASCII diagram fair point too — website has proper rendering (yantrikdb.com) but the README should have an SVG. Appreciate the pushback — this is more useful than encouragement.

6r17 6mo ago

I kind of agree with the comment here that a lot of stuff happening around comes out from an idea without proof that the project has a meaningful result. A compacting memory bench is not something difficult to put off but I'm also having difficulties understanding what would be the outcome on a running system

pranabsarkar 6mo ago
I have been using the memory while building it. I have a central server and all my workspaces are connected to it via the MCP server. This changed everything for me. But that's me. Now I don't have to repeat things, the agent knows my preferences, can connect different projects I am working on without me asking and it knows my infra so can plan the test deployments and stuff on its own. That is somewhat I was aiming for.

pranabsarkar 6mo ago

Fair. "Does consolidation actually improve recall quality on a running system?" is exactly the benchmark I haven't published, and it's the one that would settle the question. What I do have right now: 1178 core unit tests including CRDT convergence property tests via proptest (for any sequence of ops, final state is order-independent) Chaos test harness: Docker'd 3-node cluster with leader-kill / network-partition / kill-9 scenarios (tests/chaos/ in the repo) cargo-fuzz targets against the wire protocol and oplog deserializer Live usage: running on my 3-node homelab cluster with two real tenants (small — a TV-writing agent and another experiment) for the past few weeks. Caught a real production self-deadlock during this period (v0.5.8), which is what triggered the 42-task hardening sprint. What I don't have and should: a recall-quality-over-time benchmark. Something like: seed 5,000 memories with known redundancy and contradictions, measure recall precision@10 before and after think(), and publish the curve. That's the evidence you're asking for, and you're right it's missing. I'll run that and post the numbers in a follow-up. The ASCII diagram fair point too — website has proper rendering (yantrikdb.com) but the README should have an SVG. Appreciate the pushback — this is more useful than encouragement.