It took my AI months to learn how I think, code, and ship. When a teammate joined the project, their AI started from zero — same codebase, same con...
For further actions, you may consider blocking this person and/or reporting abuse
Building something with a similar shape - a ledger that logs agent decisions over time.
A memory file says "we chose Postgres." Six months later the team migrates off it. Nothing tells the next reader the decision's gone stale, unless something re-checks it against current state.
Does memshare version individual memories, or is it one file per uuid, last write wins, no history at all? An old bundle could still hand a teammate a decision that's long dead.
The PII scan before export is the right call. Most memory tools skip that step. They just ship whatever's sitting in the buffer.
Thanks - the decision-decay problem is real and you're right to flag it.
Today it's one file per UUID, last write wins, no history. Each memory carries createdAt and updatedAt timestamps, and there's an optional expiresAt TTL you can set explicitly (e.g. --expires 90d for architectural decisions you know will need revisiting), but there's no active staleness warning - nothing that says "this is 8 months old, maybe re-check."
Bundles carry those same timestamps plus a content hash for tamper detection, so a recipient can at least see when a decision was recorded and last touched. But you're right that an old bundle can hand someone a dead decision with no signal that it's dead. That's a real gap.
I've been thinking about a lightweight "confirmed at" timestamp - something that gets bumped when a memory is explicitly re-validated rather than just read. That plus an age-based flag in the export preview ("3 items older than 6 months - still current?") would catch the worst cases without adding versioning overhead. Not there yet, but it's on the list.
Good to hear the PII scan resonated. That was a non-negotiable from day one - if you're building something similar, happy to share what patterns worked and what tripped us up with false positives.
Uri, the "confirmed at" idea is the right shape for it. Bumping a timestamp on explicit re-validation instead of just on read makes a real distinction - "last touched" and "last confirmed correct" are not the same fact, and conflating them is how a decision nobody has actually looked at again ends up getting trusted anyway. The age-based export warning on top of that sounds like the cheap, honest version of versioning - it tells the recipient where to be suspicious instead of pretending the tool knows.
I'd take you up on the PII pattern comparison - full disclosure, I've built something in the same space (Sentinel Vault, a secrets/PII scanner). What trips us up most is anything that looks like an identifier out of context - internal ticket numbers, short alphanumeric codes - false-positiving as secrets/PII when they're actually just noise. Curious whether memshare's scan hits the same class of false positive or something else entirely.
Different class of false positive, actually - and that's interesting in itself.
memshare doesn't try to detect "anything that looks secret-shaped." The credential patterns are all prefix-anchored (sk-, ghp_, xox, AKIA, etc.) or need an explicit label nearby (api_key = "..."). So short alphanumeric codes and ticket numbers pass right through — they never enter the scanner's world. Credit cards need a Luhn check, phone numbers go through a filter that rejects dates, version strings, and bare digit runs. Government IDs only fire when the surrounding text names them ("passport number", "SSN", etc.).
Where we do get bitten is the keyword layer - health and financial terms. "Depression" in "cache hit depression under load" flags as health information. "Salary" anywhere flags as financial. It's a word-boundary match with zero context about whether the word is clinical or metaphorical. That's the trade-off we chose: over-flag and let the user dismiss it in the export preview, rather than try to be clever about context and miss the real thing.
So you and I are on opposite ends of the same problem: you're pattern-matching structure (anything that looks like an identifier) and getting noise from things that have the right shape but the wrong semantics. We're keyword-matching meaning (anything that names sensitive information) and getting noise from words that have the right spelling but the wrong domain.
Would be curious whether Sentinel Vault has a keyword layer at all, or if you've kept it purely structural. The hybrid is where it gets messy.
Uri, I need to correct something before answering that, sorry. Sentinel Vault isn't a secrets/PII scanner - I described it that way earlier in this thread and got it wrong. What we actually built is an attachment-locking and classification app for Confluence, nothing to do with credential or PII detection. I mixed it up with a different idea I'd been turning over and put the wrong project's name on it. So I don't have a real answer to the keyword-layer question, that's not something Sentinel Vault does. Apologies for the confusion upthread.
So I guess I'm the only one that read this as "memeshare" 😅
On the consent model, one gap sits on the receiving side rather than the sending one. An imported item is a copy with no link back to where it came from, so when the sender later corrects a memory, the recipient keeps the old version and nothing tells them it changed. Staleness by age, which the thread already covers, catches old items. It does not catch an item that is recent and already superseded at the source.
The bundle format looks close to handling it. If each imported item kept the id it had in the sender's store, a later bundle from the same sender could say that item X replaces item Y, and the recipient's preview could show that one of their imports now has a newer version, with the same item-by-item accept or reject. Consent would then cover corrections as well as first shares, which matters because a correction is exactly the thing a recipient most wants and is least likely to know to ask for.
You're pointing at a real gap, and a well-shaped fix.
What's interesting is that half the plumbing already exists. When memshare imports an item, it records the sender's original ID in importedFrom.originalId, along with bundleId and exportedBy. Right now that's used for provenance display only - "this came from Alice, bundle xyz, originally item abc." Nobody reads it back for update matching.
But the data is sitting there. A second bundle from the same sender could match on exportedBy + originalId, find the local copy, and surface it in the import preview as "updated version of something you already have" rather than "new item" or "duplicate." The recipient would see the old text and the new text side by side, same accept-or-reject consent model. No silent overwrites, no magic sync - just an informed choice.
The thing that makes this harder than it looks: identity. exportedBy is a display name, not a verified identity. Nothing stops two people from exporting as "Alice." So the matching would need to be scoped to exportedBy + some bundle lineage, not just the name string. And even then it's advisory - "this looks like a correction from the same source" - not authoritative.
The dedup today is content-hash based (same text = duplicate, regardless of source). Adding origin-aware matching would be a second axis: same source + same original ID + different content = candidate update. That's a meaningful step past what's there now.
Good suggestion - it's on the list, and the fact that originalId is already tracked means it's not a schema change, it's a behavior change in the import planner.
The identity problem has a small fix that stays serverless: generate a keypair at init, sign each bundle, and let the recipient pin the sender's key fingerprint on first import, the way SSH pins a host. Matching then runs on fingerprint plus originalId instead of the display name, so two people exporting as Alice stay two sources, and a bundle claiming to update an item from a key the recipient has not seen before shows up as a new source rather than as a correction. It stays advisory in the sense you describe, but a forged update now has to steal a key rather than type a name.
You're right that this is the correct fix once update matching exists. Today it's simpler than that — bundles are handed directly to someone you know, so identity is implicit in the delivery channel. The spoofing problem I raised only shows up once the import planner starts automatically matching incoming items to previous imports by originalId, which isn't built yet.
So the sequence is probably: build origin-aware matching first (the behavior change), then add key-based identity when the matching makes it necessary. Signing the bundle is a small addition to the format, but there's no point signing something nobody verifies yet.
Good to have the design ready for when it matters, though.
You're right that this is the correct fix once update matching exists. Today it's simpler than that - bundles are handed directly to someone you know, so identity is implicit in the delivery channel. The spoofing problem I raised only shows up once the import planner starts automatically matching incoming items to previous imports by originalId, which isn't built yet.
So the sequence is probably: build origin-aware matching first (the behavior change), then add key-based identity when the matching makes it necessary. Signing the bundle is a small addition to the format, but there's no point signing something nobody verifies yet.
Good to have the design ready for when it matters, though.
Consent at share-time is not the same as consent at re-read time.
A memory that was safe to export last quarter can become wrong after a contract, migration, or incident. If the receiving agent treats an imported note as durable truth with no provenance link back to the source decision, you get retrieve-first theater: fluent context, expired warrant.
The check I’d want before any memory export: re-evaluate each item against current policy and mark items that lack a living source link as non-authoritative until refreshed.
The consent model is what makes this different from every other "AI memory" tool I've seen. The four gates — tag at creation, PII scanning, preview that shares one code path with the real export, and per-item import choice — are the right shape. Most tools treat sharing as "export everything and trust the other person not to leak it." You're treating it as a series of decisions.
I'm a beginner — I'm learning Python and writing tutorials about it on Dev.to. I don't have a teammate's AI to sync with yet. So this is coming from someone with no skin in the game.
But here's what it made me think about:
In a few months, if I start working with other people, the first thing I'd want is the "how we do things here" context — the conventions, the decisions, the stuff that never makes it into the README. Right now that lives in someone's head, or in a Slack thread nobody reads, or in a commit message from 2024.
If AI memory really becomes a data type, then the thing I'd want to trade isn't "here are my notes." It's "here is how this team thinks."
The preview-runs-the-same-code-path detail is the one I'd steal. Preview that drifts from real behavior is worse than no preview, because it makes consent feel safe when it isn't.
Bookmarked. Genuinely interested to see where this goes.
The consent model is what really stands out here. Treating AI memory as portable, human-readable data instead of locking it inside a specific AI product makes a lot of sense, especially for teams using different tools. The preview-before-export and per-item approval flow are particularly thoughtful touches.
Really interesting open-source approach. For more AI and developer tools, check out Codecan.net.
This is a really interesting way to think about AI memory. The part that resonates most with me is that teams already have all this valuable context, but so much of it lives inside individual conversations, tools, or someone’s head.
I especially like the decision to make the memory plain, human-readable data rather than another opaque feature tied to one AI platform. The consent model also feels important here—sharing context shouldn’t automatically mean giving someone everything an assistant has learned.
The biggest challenge I can see is the one that came up around stale memories. “What we decided” and “what is still true” are two very different things, especially on long-running projects. A simple timestamp or provenance trail could become just as important as the memory itself.
Still, the idea of making AI context portable between people and tools feels like a missing piece of the ecosystem. The “how this team thinks” aspect is particularly compelling. Really cool project and definitely something I’d keep an eye on.
A memory can be safe to share when it is written and sensitive after a contract or incident changes. Does memshare recheck old shareable items against current policy before exporting them?
The short answer: yes for PII, not yet for arbitrary policy.
Every export runs the full PII scanner against every candidate item at export time, not at write time. So if we add a new detection pattern (say, a new credential format or a health keyword), items that were written months ago and marked shareable will still get caught and blocked in the export preview. The user then decides per item whether to redact and include, or skip entirely. The scanner is deliberately over-eager - a false positive costs one click, a false negative leaks something real.
What we don't have today is a pluggable policy engine - something that could encode "after contract X was signed, mentions of project Y are now sensitive." That's an interesting direction. Right now the tool trusts the visibility label the user set (shareable vs private) and layers the PII scan on top at export time. Re-evaluating the visibility label itself against evolving rules is something we haven't built, but the architecture would support it - selectForExport is the single gate everything passes through, so a policy hook there would cover both preview and actual export without drift.
Thanks for raising this — it's the kind of thing that matters more as teams grow.