Are we moving away from portability? How much is Obsidian locking our notes in?

I think the security risks are overblown.
Risks from lack of maintenance and data loss are higher. This is especially true for complex plugins with multiple functions. As always I’d advise backups.

The plugin code is inspected before first deployment and is available for inspection thereafter. As you say, most users aren’t actually capable of checking things out but there are probably enough who are to pick up the most nefarious concerns quickly enough, especially for popular plugins.
I think you are more likely to be caught by a scam or phishing than an Obsidian plugin.

Practically, I have a large number of vaults, including a number which exist only for testing. Any new plugin I might consider goes there first. I don’t install highly complex plugins (maintenance, complexity and data loss risks). I have an effective multiple backup regime, with versions.

Remember that this depends on a plugin.
And .txt files are still not treated as .md equivalent in Obsidian.

In Obsidian there are two options for link syntax.
markdown and [[wikilinks]]
Wikilinks are much easier to write and are becoming more common; markdown links will be recognised by all programs that work with markdown. Converting one to the other isn’t that hard, and converters are available. For me, the speed and efficiency of wikilinks trumps any issues of compatibility with programs that remain stuck on markdown linking.

I’m afraid I can’t help there. Not an Apple user (I dislike their security practices!!). But I’ve seen frequent references to both programs here, so there ought to be plenty of specific help if you need it.

4 Likes

Thanks for the detailed answers, very helpful thank you.

A significant one is this:

Notion and Roam believe in the rent-to-use model. Month after month, year after year, these applications will nickle and dime you. Sure, it may not be a lot in of itself. But add the subscription cost to all of the other subscriptions in your life and it starts to look a little bleak.

2 Likes

You can always use iA Writer or Typora to work on your markdown documents. Markdown and text documents will always be usable under hundreds of different applications out there.

Wiki versus markdown links is a key portability issue. I switched to markdown links and there is a plugin (of course) that hekps make this relatively painless. It is obsidian-consistent-attachments-and-links. If you want portability, make sure to use this to help. There are also several other variations from markdown but those are more easily handled.

The big issue for portability is the reliance on plugins. Many add enormous convenience and value but are proprietary. Great example is the tasks plugin. The good news is there is that the tasks can be converted into todo.txt (extended) format fairly easily with a python script that won’t be complicated to write. Excalidraw can create an svg file so you can move that but perhaps not the raw Excalidraw content. If you want maximum portability, be aware and judicious in what you adopt for critical capabilities.

Many apps support wikilinks, including some that don’t use markdown. Wikilinks are generally quicker and easier to read and write.

So decision about which to use in terms of compatibility depends on which apps you want compatibility with. But easy enough to bulk convert one to the other.

I’d say idiosyncratic rather than proprietary.

How future-proof is really Obsidian, with a heavy use of plug-ins that add a lot of code to the notes which is specific to those plugins?
A plugin is often created by a single developer that could abandon it at any moment. Then a new version of Obsidian comes out that doesn’t support that plugin anyore and boom, hundreds of notes suddenly become partially or totally unreadable.

Here are my thoughts on this topic.

4 Likes

I make sure to only use plugins/workflows that keep to clean simple Markdown. So no dataview or fancy front-matter stuff for me, for this exact reason.

1 Like

Can only agree. As .md is basically a text file and can be open by a lot of applications.

My thoughts regarding the modification through plugins. I’m using YAML Front matter, dataview and breadcrumbs as plugins who “modify” the markdown. But even then I can open the md file in Notepad, VSCode, … And as it is a text file, You can easily write a script in Python or your preferred language to modify the md files.

I can imagine many people reinventing the wheel. We need a pandoc extension/filter that handles all markdown formats, including plugin syntax extensions, for all.

I find the “extras” of Obsidian to be very helpful. However I am using folders to keep things organized. I can open files without Obsidian and do so at times for quick reference. But the plugins are really nice and useful. Moving from Evernote.

Obsidian to Craft
.
The process of getting my notes back out of Obsidian was surprisingly tricky.
.
While notes in Obsidian are simple Markdown text files, maintaining the critical links between note files, images, and other embedded files is complicated without a proper export function (which Obsidian lacks). Thanks to a tip from Curtis McHale, I used Bear, a competing notes app, to import my notes from Obsidian. Since Bear doesn’t recognize folders, I had to consolidate all my notes from a dozen folders in Obsidian to one catch-all folder to avoid losing links. Bear was able to import all my notes, complete with links between notes, images, and PDFs, and then export them in a format that worked fine for Craft. Once in Craft, I had to refile all my notes back into my folder scheme, which took some time. For software that touts itself as the ultimate in future-proofing, I honestly didn’t expect it would be such a hassle to move my information back to Craft. Bear gets high marks here for serving as the go-between, but it seems like a pretty big gap for Obsidian not to have a proper export function.
.
Despite the time it took to retrieve my files from Obsidian, I discovered how easy it was to export my information from Craft, which isn’t something you usually figure out until it becomes a critical necessity. I now have very little hesitation with trusting my notes to the Craft with its top-notch export capabilities.

2 Likes

Hmmm, I think the devs should perhaps keep and eye on how portable core obsidian is, but I don’t think it’s their concern if 3rd party plug-ins make obsidian less portable.

When I wrote this back in December, importing an Obsidian vault into Craft created all sorts of problems with links and required the Bear app as a go-between. I just tried this again and now everything comes across great in Craft without any conversion. I think this must have been an import limitation on Craft vs. a problem with the way Obsidian stores its files and related links.

2 Likes

That does sound like a Craft import issue. There’s not much Obsidian itself can do, because all parts are just files and the user can control where files, attachments are etc.

There is a clash between Obsidian’s more widely used wikilinks and Craft’s @links, but I’d assume Craft’s import algorithm should deal with that.

OTOH, a few parts of the Obsidian syntax may be unique, plugins can set themselves up however they want (how well can Longform export to other writing programs?) and it is true that the whole functioning and linked system is greater than the files alone. I thought your blog was an interesting illustration of the types of problem that can be encountered. And a challenge to the idea that files are necessarily safer long-term than databases.

2 Likes

I took a big step back from dataview for precisely that reason. I really like the idea of keeping my knowledge base as platform-independent as possible.

If you’re able to write simple scripts, portability doesn’t mean adhering to standards, but being able to convert from one format/convention to another.

A simple regex replace can go a long way in converting wiki links to markdown, nested tags to flat tags, dataview to another query, etc.

Also, there are two things that cause lock-in into obsidian:

  • relying on the custom indexing of files
  • relying on the custom rendering (i.e. dataview converts a code block to a list or table)

I have written my own script that indexes the markdown files and extracts information. I can export this as a JSON file.

I have created custom web components (e.g. there are html tags like strong or div or main, but with a custom render function). For example zk-tags will display the tags of a markdown file. And zk-list will run a query and list the results. (It will download the JSON file to query the vault)

Basically, markdown is a simple way to write html. With custom web components, you add new stuff to html in a standard way. All it takes is adding a script and stylesheet to the rendered html.

This way, I have a portable way based on web standard to index and render whatever I want, in any environment.

Having an open source index library and by using web components, Obsidian could do the same. Instead, we rely on a closed source API and custom rendering that is only available inside of obsidian.

2 Likes

This is why I avoid plugins that insert a lot of non-human-readable custom syntax on the note just to function

I really do not know where the problem is.

There are good reasons, why there is only a limited number of core-plugins in obsidian (which are in themselves already quite useful, imho), and even those can be turned of if it pleases you. You can do away with more or less all Plugins, with yaml, with tags, if you like, and rely completely on links, if you wish. And you even dare use different sorts of links, since obsidian interprets most of them. Even if you have 20 plugins cluttering your frontmatter, you can turn them of and work with the remaining functionality. It’s all your choice, which is more than one can say about most of the competitors I know (and that’s saying something).

Still, you have to be aware that every program that works with a linking system, needs some kind of metadata to provide this functionality. The index for that is either in some kind of database that is being maintained by the program and tucked away from the user (doing things you can not control) or in the document itself. Again: You decide.

The obsidian devs have decided to place most of the indexing in plain sight in the .md, by using yaml. (that is, e.g. if you add aliases to a note, and have the links-pane open, you can see obsidian querying for unlinked mentions in real time). Yes, there is an index too, but it seems to be rather compact than extensive.

And in the end, the core idea of a “second brain” is about discovering connections you did not know about. Links you create yourself are all about things you already know. If that’s what you strive for: have fun!

Still, my advice would always be: prefer using plugins and metadata that only facilitate your workflow and give your vault a comprehensive structure. And use other plugins only for special cases. You don not need advanced slides, breadcrumbs, or other plugins that clutter your frontmatter in all your notes, but in some they might be helpful to achieve you goals. It really is all up to you.

Don’t get me wrong, there are numerous elements, where I would have taken different decisions, if I had been asked. But I am not. And I am not developer, so I have, in a way, to live with what I get. And Obsidian is a hell of a way better, than everything I could dream of during my time at university. I still have my notes from that time: full portability, no functionality …

If a different app suites your needs better than Obsidian: take that chance! But do not dream about not being “locked into” some app if you are invested in it. That’s just not possible. For some things you just should take your time to decide, where to invest. There is always some kind of “lock-in”. Most times you are just replacing one lock-in with another. Portability always comes with the price of sacrificing functionality. And there comes a time when dreaming of resetting your brain is just nuts.

But what about the fear of Obsidian “going away” some day? Or one of the devs leaving and taking away the code?

First: Your notes will still be there. So the important part, your work, won’t be gone. No one at obsidian.md ever promised more than that. Obsidian provides a functionality, not knowledge. And this Program can’t just be “shut off” from “somewhere else”. So you will have all the time in the world to continue working while finding another app and transfer your notes.

Second: Even the metadata in your notes will still be available. So every search function in your System will still be useful, if obsidian does not work anymore. But you have to decide: is it your knowledge you care for, or the functionality?

Third: There are a number of devs that are rather invested in Obsidian already. And lots of users that are investing their time in their vaults. Creating another version of Obsidian, open source or else is definitely no rocket science. Its rather fast development cycle is proof of that. In the end it relies completely on publicly available libraries. And the more users of obsidian there are, the more people will look for a replacement. If I were a developer, I would know what to do …

Again: Portability always comes with the price of sacrificing functionality. If that’s what you are interested in, go ahead. It’s all about your choice.

I, for my part, are - for the time being - more than happy for a versatile, open, evolving, and becoming more and more functional app for my knowledge management needs. I am still haunted by the handwritten notes from my classes that I have never touched again …

5 Likes