VendorLock (or: create an Obsidian-specific file format)

It’s an interesting dilemma. I think the plugin architecture of Obsidian is the ideal approach—it puts power in the hands of users. If you don’t want a feature that might potentially lead to compatibility issues in the future, don’t use it.

The light syntaxes Obsidian (and its future plugins!) provide are really neat, I think. The best plugins will add functionality in plaintext while still being interpretable in other apps. See, for instance, the “Expander” plugin. It adds cruft to the text, but it’s easy to tell what it is by looking at it.

For that reason, I vehemently disagree with the idea of switching to a novel file format (and I suspect many others will, too). I want to be able to open and use these files with the rich markdown ecosystem that has developed over the past decade or so. Those apps and services will add their own cruft. That’s fine! It’s like the Web. There’s lots of weirdness with how HTML, CSS, and JavaScript is interpreted depending on your operating system, browser, browser extensions, preferences and settings, and even window size. Sometimes that hurts the experience, but most of the time it affords a rich and delightful canvas for makers and users to create and consume things from.

For what it’s worth: the developers are encouraging app metadata to be added to YAML headers at the front of each document (another markdown semi-standard).

(Note: I added detail to the topic title for clarity.)

5 Likes