doobidoo/mcp-memory-service

What happens Every pull path in HybridMemoryStorage writes a memory fetched from the secondary with a bare self.primary.store(cf_memory): the drift path, the hash-diff pull, the update path and the full scan (storage/hybrid.py, the primary.store( calls around lines 950, 1315, 1391 and 1495 on main). Two arguments are missing: skip_semantic_dedup=True: the memory already exists, it was deduplicated when it was first written. Running semantic dedup again on the receiving device rejects it whenever that device happens to hold something similar, and the device then never gets that hash. The log shows Failed to sync memory <hash>: Duplicate content detected (semantically similar to <other hash>), and the next sync tries and fails again. store=: the memory lands in the default store whatever store it came from, so multi-store partitions (#1395) do not survive a sync. How I ran into it Startup sync on a hybrid VM on 2026-10-11 logged three such rejections in its first 1,000 memories, among

What happens _sync_memories_from_cloudflare (storage/hybrid.py) has two branches. When the secondary holds fewer or equal memories than the primary, it diffs hashes and pulls exactly the missing ones (#1255). When the secondary holds more, it falls through to the full scan, which pages Cloudflare newest-first in batches of up to 500 and stops after HYBRID_MAX_EMPTY_BATCHES (default 20) batches without a new memory. With ~8,760 memories that is up to ~18-35 batches. If the missing memories are old, the scan gives up before it reaches them. They are never pulled, by the startup sync or by a forced pull, no matter how often either runs. How I ran into it A VM running hybrid against the same D1 as my Mac was missing 142 memories that D1 had live, 136 of them created 2025-07-25 (an import that kept its timestamps). Local=8606, Cloudflare=8747, so the scan branch ran. /api/sync/force on the VM pulled 13. The 136 old ones sat behind thousands of memories the VM already had. Setting MCP_HYBRID

#1304 landed in #1470, #1471, #1474, #1476 and #1480. The client side is documented well: docs/mastery/configuration-guide.md, docs/guides/STORAGE_BACKENDS.md and docs/mastery/troubleshooting.md cover every MCP_HYBRID_SECONDARY_* variable, the auth styles and the model check. The other half of the topology is missing. Gaps on main: No hub-side setup. Nothing says how to run the hub: which storage backend it should use, that it must not run hybrid itself (the hub is terminal), which API key scope the clients need (read for GET /api/health/model, write for store and delete), and whether MCP_HYBRID_SYNC_OWNER still matters on a client whose secondary is http. Multi-client semantics. With three clients on one hub: does a delete on client A reach client B, how does a client that was offline for a day catch up, and what happens when two clients store the same content? The docs say "background sync" and stop there. Re-embedding the hub. Troubleshooting says a model change needs a hub re-embe

Since #1472 the Analytics graph has two controls that both filter on connection counts: Min Connections and Min Degree. They count different things, and nothing in the UI says so. Neither control has a tooltip, and nothing in docs/ or the wiki covers them. What each control actually does Min Connections (graphMinConnectionsSelect) runs on the server. Changing it reloads /analytics/graph-visualization?min_connections=N. The SQL in storage/mixins/retrieve.py (get_graph_visualization_data) counts each memory's distinct target memories across the whole database, has_entity edges excluded, and keeps the ones with >= N. It then takes the top limit by that count. This decides which nodes get loaded at all. Min Degree (graphDegreeSlider) runs in the browser, in _filterGraphData() in app.js. It counts distinct neighbours in the graph as drawn: only edges between loaded nodes, only visible relationship types, and a mutual A<->B pair counts once. It hides nodes below the value and makes no reques

Two small gaps in MemoryConsolidator._store_associations_in_graph_table (consolidation/consolidator.py, L1005-1110): 1. The similarity guard never runs. infer_relationship_type accepts similarity= and suppresses typed labels when it is below min_typed_similarity (guard 1 from #541). The consolidator calls it without that argument, so similarity is None and the guard is always skipped. The value is right there: association.similarity_score is passed to store_association a few lines further down. 2. The confidence is thrown away. The inferred confidence decides the label and whether a contradicts pair gets superseded (confidence >= 0.75), but it is never written to the edge. graph_storage.store_association already persists the metadata dict as JSON, so nothing downstream can tell a 0.51 supports edge from a 0.9 one, and nobody can measure later how well the scores are calibrated. What to change Pass similarity=association.similarity_score to infer_relationship_type. Add "relationship_co