Open Source Defined Obsidian Markdown Specifications to Combat Ecosystem Lock-in Fears

Use case or problem

Open Source Defined Obsidian Markdown Specifications to Combat Ecosystem Lock-in Fears.


I’m writing this request to propose a compromise I thought of regarding the topic of open sourcing the Obsidian code base.


  • Obsidianism: A deviation from the markdown spec that Obsidian uses. For instance the preferred use of wiki links instead of markdown links.

Proposed solution

A addition to the public facing Obsidian website clearly defining the mark down spec that Obsidian chooses to follow. This spec should be open sourced.

This documentation should be designed as a specification document outlining any obsidianisms that are used in favor of the official markdown spec. For instance the usage of wiki links instead of markdown links. Any other deviation’s of the official markdown spec should be documented and versioned in the Obsidian Spec Document.

Next provide a way for plug in authors to submit revisions of the spec that their plugins use and expect. This can be included in the official community plug-in’s repo. This provision should be namespaced to minimize collisions in spec extensions. Spec → Plug-in Author|Org → Plug-in Name.

A yearly (or bi-yearly) review of the specification, and a way for the community to vote on changes. if obsidian decided to add native functionality that a plug-in already provides this would allow the plug-in author to have a voice in the spec changes.

Having a clearly defined spec would be a solid start in preventing lock in, as author of common conversion tools (pandoc, etc) can reference the spec in order to extend the tool so they will work to allow the community to migrate to alternative tools. The added benefit would be to give a nod to the open source community and would be a good first step to open sourcing the ecosystem in the future if that is the direction that Obsidian goes.

1 Like

Thanks for your input.
I don’t think at this point this is necessary. Obsidian is (or tries to be) commonmark compliant and uses some commonmark extensions.

There are no modifications but 3 additions:
Wilikilinks [[]], block references ^ and comments %%.

I stress the difference between modifications and additions because you are not forced to use the additions.

I’ll move this thread to meta and we can use this thread and the help vault “how to format your notes” as a specification. I don’t expect major deviations to happen.
A page in the hub is also a good idea. Feel free to open a pull request.

Regarding plugins, I don’t think we want to bind plugin developers to adhere to any format.