First off, Atomic is genuinely interesting. The semantic graph over
markdown content, combined with self-hosting, the MCP endpoint, the iOS
app, and the Obsidian sync plugin, covers almost exactly the "knowledge
base accessible from anywhere, including AI agents" setup I've been trying
to assemble. Thanks for building it.
Two things I couldn't find in the README, docs, or existing issues, and
that determine how far I can adopt it:
1. Version history
As far as I can tell, update_atom / edit_atom (and edits from the UI or
iOS app) overwrite an atom's content in place, with no revision trail and
no way to view, diff, or restore a previous state.
I want to be upfront rather than file a drive-by feature request: for my
use, this one is a hard requirement. My notes are the kind of data I plan
to keep for decades, and once AI agents can edit atoms autonomously over
MCP, a bad edit is only recoverable if there's history — restoring the
whole SQLite database from backup is disaster recovery, not versioning.
Atomic is honestly the closest thing I've found to what I want, and
per-atom history is the single thing between me and using it as a real
system of record rather than as a search/reading layer beside a separately
versioned vault. I'd love for that gap to close.
Is per-atom version history (list revisions, view, diff, restore) on the
roadmap in any form? The storage mechanism matters much less than the
capability — anything that allows viewing and restoring past states of an
atom would do. Out of curiosity, since atoms are markdown underneath: have
you considered backing storage with git, or with one of the newer
agent-first SCMs — e.g. Oak (oakvcs.com) or the Atomic VCS (atomic.dev —
no relation to this project, amusingly)?
2. Multi-user / collaborative use
Today an instance appears to be single-user: one setup token, API tokens
for clients, no notion of separate identities. Is shared, collaborative use
on the roadmap — separate users, per-user attribution on atom edits
(especially agent edits), and some level of per-database access control?
The two questions compound: with multiple humans and agents writing,
history and attribution stop being nice-to-haves and become the audit
trail.
With versioning and collaborative use, Atomic could be the system of
record for a group of humans and their agents, not just a personal
search and reading layer. Very curious where you see it going.
First off, Atomic is genuinely interesting. The semantic graph over
markdown content, combined with self-hosting, the MCP endpoint, the iOS
app, and the Obsidian sync plugin, covers almost exactly the "knowledge
base accessible from anywhere, including AI agents" setup I've been trying
to assemble. Thanks for building it.
Two things I couldn't find in the README, docs, or existing issues, and
that determine how far I can adopt it:
1. Version history
As far as I can tell,
update_atom/edit_atom(and edits from the UI oriOS app) overwrite an atom's content in place, with no revision trail and
no way to view, diff, or restore a previous state.
I want to be upfront rather than file a drive-by feature request: for my
use, this one is a hard requirement. My notes are the kind of data I plan
to keep for decades, and once AI agents can edit atoms autonomously over
MCP, a bad edit is only recoverable if there's history — restoring the
whole SQLite database from backup is disaster recovery, not versioning.
Atomic is honestly the closest thing I've found to what I want, and
per-atom history is the single thing between me and using it as a real
system of record rather than as a search/reading layer beside a separately
versioned vault. I'd love for that gap to close.
Is per-atom version history (list revisions, view, diff, restore) on the
roadmap in any form? The storage mechanism matters much less than the
capability — anything that allows viewing and restoring past states of an
atom would do. Out of curiosity, since atoms are markdown underneath: have
you considered backing storage with git, or with one of the newer
agent-first SCMs — e.g. Oak (oakvcs.com) or the Atomic VCS (atomic.dev —
no relation to this project, amusingly)?
2. Multi-user / collaborative use
Today an instance appears to be single-user: one setup token, API tokens
for clients, no notion of separate identities. Is shared, collaborative use
on the roadmap — separate users, per-user attribution on atom edits
(especially agent edits), and some level of per-database access control?
The two questions compound: with multiple humans and agents writing,
history and attribution stop being nice-to-haves and become the audit
trail.
With versioning and collaborative use, Atomic could be the system of
record for a group of humans and their agents, not just a personal
search and reading layer. Very curious where you see it going.