Sidecar for Notes

Plugins ideas
#1

I’d like to propose the idea of Sidecar files for our Obsidian Notes. Much like sidecar files are used in digital photo file formats, they hold nothing but constructive modifications to the main file. In other words, if the sidecar disappears, nothing distructive happens to the original.

The sidecar exists to enable advanced operations that couldn’t or shouldn’t be done in markdown. It has the potential to be incredibly powerful. But also safe, so if a plugin retires or sidecar function stops working or disappears in any way, our Note content remains as is.

The sidecar could have the same name as the Note.md but with a period prefix .Note.sc so as to be hidden from view.

Any plugin that works with sidecar files could stake claim of a section of the sidecar with unique heading identifier for that plugin. Then use its section however it wants. I envision lots of XML structured data.

I think a whole ecosystem of intelligent data accessories could be created from this structure. I’ve only thought of a couple ideas so far.

External Link and Transclusion Management

A snapshot of markdown from any embedded content from external sources can be held in the sidecar. Then if the orignal, which we have no control over, changes at some future date, a plugin could either notifiy us by our preferred messaging app, or provide an indicator in our Note that signals that the content is different than originally referenced. Then give us the choice to keep the new transclusion and update the sidecar, or forsake the transclusion for a static version of the original content.

Version Control

Playing of the Transclusion Management idea, sidecars could provide the foundation for a version control system for our Notes.

Better Template Access and Management

Hidden Area for Auto-generating Content

One plugin could manage sidecar space and scraping data from the web, another plugin could then process that data on a set schedule and generate or replace static content in the main Note. We could have our Obsidian Daily Page show a set of icons at the top of the page that show weather predictions for that day.

I’m curious what kind of ideas this inspires from the Obsidian community. What would you do with a sidecar?

3 Likes
#2

I’ve dealt with sidecar files in other app development. Biggest problem is that end users modify them, delete them, rename them… For me, metadata should be hidden for end users.

#3

I agree. Hiding the stuff that will ruin things is a very good idea!

But that’s why I like the non-destructive photography model for sidecars. If you mess up, you lose some of the added value, but never the original content. I don’t know what decisions were made behind the sidecars you were using, but if sidecars are designed to add non-destructive value to your workflow, there’s really not much someone can do to screw up. Besides, if someone is bent on messing with stuff and does break something, they learn what not to do and how to use their tools better. I generally wouldn’t admit it in the moment, but I’m thankful for many of the things I’ve broken in the past, hahaha! Best lessons ever!

If done right, sidecars are a pretty low-risk thing to mess around with. Plus, they could be easily hidden from the Obsidian file explorer.

#4

Yes if the added value is discarded, which should be the case for sidecars in general, then this is doable. However, we got so many complaints from end users forgetting to copy the side-car files with the content they moved around, or tweaked the sidecar files so the system could not parse it properly, and for them it was considered a data loss.

Well some end users even edited the sqlite database file but that’s then a totally different story.

1 Like
#5

I wonder if there’s a programming equivalent of “No lifeguard on duty. Swim at your own risk!” :sweat_smile:
Well, it’s not like anyone reads the signs anyway :skull_and_crossbones: