Treat Folders as First-Class Linkable Entities
Architectural Inconsistency
Obsidian already indexes every supported file in the vault—from Markdown documents to binary attachments (PDFs, images, audio, video)—making them valid link targets within the graph. However, folders remain the only filesystem entity excluded from the linking model, restricted to being passive containers despite being first-class objects in the filesystem.
Current Model:
├── Files (Markdown & assets) ✔ Linkable
└── Folders (Directories) ✘ Container only
In many local-first workflows, folders are not just storage buckets—they represent primary conceptual entities (e.g., a project, client, legal case, research dataset, or CAD workspace).
Scope Clarification
Note: This proposal does not introduce folder metadata, editable folder documents, or new object types. It simply extends the existing wikilink resolution system so directories become valid link destinations, just as files already are.
The Problem with Current Workarounds
Because folders cannot be linked, users are forced to create artificial placeholder files solely to make a directory referenceable.
Projects/
Apollo/
CAD/
Documents/
Photos/
Today:
[[Projects/Apollo]] ✘ Invalid
Users must create:
Projects/Apollo/Apollo.md
...solely to make the project linkable.
This creates two major issues:
- Structural Noise: Placeholder files exist only to compensate for a missing filesystem abstraction rather than representing actual knowledge, cluttering both the vault and the graph.
- External Tool Pollution: It pollutes directories shared with external software (IDEs, media software, CAD tools, scripts) with implementation artifacts.
Proposed Solution
Core Feature
- Folders become valid link targets in the wikilink resolution system.
Natural Consequences
By granting folders first-class status in the index, they naturally inherit standard Obsidian behaviors without new UI paradigms:
- Autocomplete: Native path resolution for directories (
[[Folder/]]). - Rename Propagation: Updating folder paths automatically updates incoming links.
- Backlinks: Track references to folders across the vault.
- Graph View: Option to render directory nodes and incoming structural links.
- Embeds & Hover Previews: Support
![[Folder/]]and hover cards to render inline tree previews of directory contents.
Why This Matters
- Architectural Consistency: Unifies the linking model so that every indexed filesystem entity is linkable (
Files
, Folders). - Plugin Ecosystem: Because folders would become indexed entities, plugins could build on a stable core API instead of implementing custom filesystem traversal and folder-reference conventions.
- Interoperability: Keeps vault directories clean and standard for external local-first applications.
- Complementary to Bases / Dataview: While databases query properties, folder links express structural and containment relationships. They solve fundamentally different problems.
- Cross-Platform Parity: Delivers a reliable, native experience across Desktop and Mobile without relying on fragile community plugin workarounds.
Backward Compatibility
- Existing vaults require no migration.
- Existing wikilinks remain unchanged.
- Folder links introduce a new valid target type without affecting existing file behavior.
- Existing placeholder files continue to work normally.
Proposed Principle: Every filesystem entity indexed by Obsidian should be a valid link target. Files and folders would then share the same fundamental linking model.