Obsidian is the central hub of my note-taking. I use it since it was in closed alpha, and you needed to email the developers to get into a Discord server to download the application.

Since then, Obsidian exploded in popularity. And for many reasons: the fact that it is just a functional interface over a folder of Markdown files, the fact that is developed independently by two awesome developers, for its graph feature, because it started as a free alternative to expensive hyped beasts such as Roam Research, or for its plugin extensibility.

But I am not here to talk about why you should try Obsidian. I know you can find another 200 articles explaining that. What I want to discuss here is a side effect of the indiscriminate use of Obsidian’s plugin extensibility that may accidentally lock you into Obsidian and undermine the core principle of the application.

Obsidian’s Core Principle

The first thing you see on the Obsidian’s homepage is a gigantic phrase:

A second brain, for you, forever.

As explained below in the same page, this claim is based on a single cornerstone principle: Obsidian’s file are written in a public, free, interoperable format: Markdown.

Quoting Obsidian’s homepage:

Markdown is designed to be human-readable. It’s not obfuscated by encoding; you can directly edit the source files with Markdown editors, or edit them automatically with scripts.

The entire concept of future-proof (and the absence of any lock-in mechanism) is one of the biggest selling point of Obsidian for me.

This means that:

1. If Obsidian disappears tomorrow, I can just access my notes with any other markdown editor and be okay with it.
2. If I do not have access to Obsidian, or for some reason I do not want to, I can open, read, understand, edit and save my Obsidian vault with any other editor.
3. All the information is accessible by standard command line tools.

Note that this is not some weird hypothetical end-of-the-world scenario: I take advantage of that every day. For instance, I very often access my Vault from withing Emacs (using deft-mode just because I do not want to switch context while I’m using Emacs for other things.

Why some plugins go against this principle

By per se, plugins are not a problem. I use a lot of plugins (right now I have 22 plugins enabled, even if I wish for some of them to be just core functionalities). Moreover, Obsidian ability to be easily extended via Typescript plugins is the Obsidian’s killer feature. The fact that anybody can adapt this application to their specific use cases (or hire someone to do it) is a fantastic feature. In a sense, Obsidian is like a “modern era Emacs.”¹

Therefore, I am really pro-plugin. And I myself developed a couple of plugins for Obsidian. So, trust me, I love plugins.

However, if we develop or use plugins without a clear idea of what we are doing, we risk damaging the future-proof claim of Obsidian.

How? The problem arises from the plugins that add CSS snippets and pollute the markdown files with a lot of ad hoc syntax. As a result, our notes became “incompatible” with other editors, and they will depend on specific plugins to work.

Let’s take a look at one of my favorite plugins: Dataview. I love this plugin, and I think it is a perfect example of how powerful Obsidian is. I am using it as an example not because it is the worst offender (on the contrary), but because it is the most downloaded plugin out there and, therefore, you will probably understand better my examples.

Back to the example: if we make an indiscriminate use of Dataview, we may have our notes full of Dataview’s queries that are impossible to process outside of Obsidian. If I open a note with a Dataview query in Emacs, I cannot access that information: I need to open the note in Obsidian. That note is therefore locked in: it makes sense only in the purple rock software.

This is a clear problem for the future-proofness of the note. If, for instance, tomorrow Obsidian disappears or Dataview’s author kill his plugin and nobody jumps in maintaining it for future version of Obsidian, I will be forced to: keep using an old version of Obsidian, lose the notes, or spend time migrating them.

The same reasoning applies to many other plugins that add iframes, or a lot of custom-syntax and custom behavior to note rendering.

So should I stop using Dataview/whatever?

Absolutely not. As I said. I use a lot of this kind of plugins. What you should do is to ask you this questions every time you are using a certain plugin in a specific note: if I will lose the ability to use “Plugin X”, I can still get all the information I need from this note? And, if not, I will be okay with it?

For instance, I use Dataview as a way to build custom dashboards in my index notes (for instance, to get a list of notes I need to review). I am okay with that. I need these pages to be dynamically updated and to work only from Obsidian. It will never contain information that I should conserve/use in 50 years.

Yet, for other notes – the one commonly called evergreen notes – I prefer old-fashioned links because I know that such links will stay there forever.

I am a plugin developer. What can I do to make this easier?

A perfect example is the Obsidian-Kanban plugin: while the rendered version is very customized (after all, it is a Trello-like kanban board), the plain text note used as a source is incredibly readable, and I was able to add/move cards even from vim when I needed it.

If you are a plugin developer, try to follow these two simple rules:

1. If you need to add a custom syntax, if possible, prefer a syntax that can be read or edited by any other editor.
2. Plan a way to “make permanent” the data shown by your plugin. If your plugin disappears tomorrow, how can your user “save/export” that information?

That’s all.

Use your plugin responsibly, and you will never have to worry about losing your notes.