Overview
Glyph’s storage system consists of:- Space Files - User-created markdown files in
notes/ - Assets - Content-addressed files in
assets/(SHA256 hash) - Cache - Derived data in
cache/(link previews, thumbnails) - Atomic Writes - Crash-safe file operations
Content-Addressed Storage
Why Content-Addressing?
Storing files by their SHA256 hash provides:- Deduplication - Same file stored once, even if used in 100 notes
- Integrity - Hash mismatch = corrupted file
- Immutability - Content can’t change without changing hash
- Cache-friendly - Hash is permanent, perfect for CDNs
Implementation
src-tauri/src/notes/attachments.rs
Example
Frontend
logo.png is attached to 10 different notes, only one copy exists on disk.
Atomic Writes
The Problem
Naive file writes can corrupt data if:- App crashes mid-write
- Disk full during write
- Power loss during write
The Solution
Write to temp file → fsync → rename → fsync parent directory.src-tauri/src/io_atomic.rs
Usage
src-tauri/src/space_fs/read_write/text.rs
Path Safety
Preventing Path Traversal
All user-provided paths are validated:src-tauri/src/paths.rs
Examples
Cache System
Link Preview Cache
External link metadata is cached to avoid repeated fetching:src-tauri/src/links/cache.rs
Space Structure Summary
.gitignore Recommendation
.gitignore
File Watching
Filesystem Watcher
src-tauri/src/space/watcher.rs
Performance Considerations
Large Files
For files >10MB, use streaming instead of loading into memory:Batch Operations
Use database transactions for bulk inserts:Next Steps
Tauri Commands
Learn IPC communication
Components
Frontend component structure