Rich Filesystem Embeds and Automated Associations

While the support for embedded images and PDFs is solid, I’m wondering if providing a plugin to handle more complicated or specific workflows might be a good idea.

Use Case #1: I am researching Topics A, B and C. I have multiple notes for each topic, and discovering connections between all three which coalesce in evergreen notes. My research requires me to download files of different formats than are currently supported—or likely should be supported—in the core engine. I want to be able to embed these files and reference them them independent of an initial embed statement, by an Obsidian reference, once they have been initially uploaded.

Use Case #2: Same as Use Case #1, but this time, I am able to do this laconically, by identifying a “watch folder” created in the filesystem. Any file dropped in this folder is automatically added to folder-specific index note that’s generated by, say, grabbing a trimmed string of the watch folder title and appending a suffix. So, Topic A Watch Folder generates a corresponding note called Topic A Watch Folder Index. This is essentially the same idea referenced in this post on “Watch Folders” but with the added special sauce of multiple file formats from Use Case #1.

Use Case #3: Dangerously operating-system specific, but following on #1 and #2, use the OS tagging system as a mechanism for automating the import of specific files across a defined portion (e.g. the vault folder) or (full crazy) the entirety of the accessible filesystem for a given user. Tag-specific indices would be generated in roughly the same fashion as Use Case #2.

I’m a MacOS user, and a super-brief scan found this Node package that allows for tag manipulation in MacOS. It’s likely outdated but points toward a path. Not to mention that Christian Tietze of and The Archive fame built a Tag Converter for converting Finder/Spotlight metadata into #hashtags, “putting them inside the files.” It seems likely similar things could be built in more recent Windows and certainly Linux.

The only other alternative to these approaches for encapsulating and making addressable the non-Markdown content that’s part of one’s KMS (imho) is a deeper integration with URIs. My initial exploration down the path of e.g. referencing specific e-mails in an e-mail client by URI returned wildly varying levels of support in different applications for the URI spec, and wildly different levels of specificity in what was used.

Disclaimer: I could be very, very wrong.


I have pretty much the same idea as yours, and I hope the developer could do more about this, especially the support of embeding more file format(at least generate links to them),which is the foundation of other more advanced usage of obsidian.

Yep. Anything with the word “Rich” in it gets my vote.

  • Rich text
  • Rich embeds
  • More rich text
  • More rich embeds.

And I’d pay for anything that adds more “rich”, “wysiwyg” functionality to the app.