Thought UmweltThought Umwelt

thought umwelt

How Dynalist or Workflowy stores data

2 min read

Obsidian Metadata

sourcehttps://gemini.google.com/app/abcb480f396111d8

The data model

A node structure Here each node is an independent data object with parent and child association instead of a flat file

{
  "id": "node_123",
  "content": "Buy groceries",
  "parent_id": "root_001",
  "children": ["node_124", "node_125"],
  "metadata": {
    "completed": false,
    "collapsed": true,
    "color": "blue"
  }
}
  • Every bullet is an object → Allows zoom in / zoom out and independent rendering
  • Parent and Child relationship → parent id is stored in each node as an ID and children id as an array → this allows to easily move one node to another by simply moving the parent id

Why store both parent and child id? why not just one Ordering and performance - Only parent id → need to save additional position or index to know where the child should be. - With children array → you just move the ID within the array When you do move, you just update the parent_id and update the children of that parent. You don’t need to touch any of the children of the node you moved, no matter how big it is.

Backend storage

Relational vs NoSQL → NoSQL would mean storing a JSON as a flat file → this might not be efficient at all so probably Relational.

Storage might be in the form of Adjacency Lists and use Recursive Common Table Expressions (CTEs) to fetch one whole branch quickly.

Real-Time Sync & Collaboration

Two approaches

  • Operational Transformation(OT): use by google docs etc. where the instruction will look like insert 'C' at position 5 and the server reconciles everything
    • Possibly server heavy
  • Conflict-free Replicated Data Types (CRDTs): Newer approach where any two edits can be merged automatically without server deciding reconciliation. (works well for offline first and lots of simultaneous users).
FeatureOperational Transformation (OT)CRDT
”Source of Truth”The Server. The server is the referee that decides the final order of events.The Data Itself. The logic for merging is baked into the data structure.
ComplexityExtremely high on the server side (handling edge cases).High on the client side (memory/storage overhead).
Offline SupportHarder. Long offline sessions can lead to massive “rebase” conflicts.Excellent. Designed for “offline-first” and peer-to-peer sync.
Server LoadHeavy. The server must process every single keystroke in real-time.Light. The server acts as a simple “mailbox” to pass data along.

Graph View