All: this may be more of an advanced concept, and is decidedly for more technical folks here. But I’m extremely curious to see if anyone has implemented something like this before, of if they’re interested in this idea to begin with.
Background
I’m getting perilously close to implementing the first of two separate systems for my JD setup: one for work (my business) and the other for personal. As I’ve been working through the videos and the workbook, I’ve come to appreciate the power of the index.
But I have one potential issue with it: the “entry point” for a system is often enough the index itself. It’s a top-down hierarchical thing. Add something to the index, jump into your filesystem, then add that same thing.
My question / idea
Preamble: I’m very comfortable with the command line and scripting, and when I need to really to really move around fast I use the command line almost exclusively.
During a normal work day, the the common entry point is the filesystem itself. Looking ahead a few weeks toward my operational JD system, I feel like I’ll want things like this to work:
If I create a new category or new ID within an existing category, the index is automatically updated to reflect this change. That is, the ability to work from the “bottom up” without worrying about sync. issues with my index.
A process automatically sweeps the index and looks for inconsistencies inside of the corresponding folder structure. If something isn’t right, log it and notify me.
If I start from the “top” (the index) and add something there, it’ll automatically be added to my filesystem.
The index needs to support proper metadata (this is why I’m leaning heavily toward Obsidian: yaml frontmatter). This same metadata can make its way down into the filesystem (or vice versa) in the form of hidden files.
I suppose what I’m getting at here is that I want the index and my filesystem for a given structure to flow both ways, and have rules in place that ensure that:
They’re always in sync
Regardless of my entry point, the filesystem structure and metadata for a given category or ID is always only a single step away from me (or another user).
I hope I’m making sense here. If you’ve done something like this or have thoughts, I’d love to hear about it (or them).
I think an underlying problem is that you may have more than one “file system”. For example, I have indexed files in onedrive and in dropbox (I am in the process of moving residual older files from my hard drives into the cloud). It is clear that many people might have physical files, or separated files on multiple computers. So a single two way sync may just not be possible unless you are absolutely certain that all your stuff is in one electronic location.
That said, I believe you could actually accommodate at least some of this by adding a local filesystem entry for that external thing. That entry acts like a pointer (symlink) to a specific email, google drive document, etc. Imagine a Location: entry that points to an external system. This would in turn create a local pointer to that external system. At least I think
Pontification aside, your point stands. This is one of the areas I’ll need to strongly consider in order to keep things consistent. It does feel like a problem that can be solved.
Last note: I plan on taking all of this on after the system is built and I’ve started using it exclusively. Only then will I know if going in for these extra layers is worth it or not…
You definitely describe an ideal future-state, Matt. It’s one of the reasons I want to write my own app.[1]
Imagine being able to ‘watch’ locations and just have stuff you create there picked up and added to your index. And be notified of conflict. (Or just have it corrected in the background!)
Or creating a note in your index and, on adding the ‘local filesystem’ location tag, having the folder created there. Along with some sort of URL scheme pointer file that you can open to bring you back to this point in your index.
And many other such dreams… so for now, I say be careful, because these tools don’t exist. I’m sure one of the smart people here could hack you together some sort of interim script. All it would need to do would be to scan your FS and compare to Obsidian and alert on conflict. I could hack a version of this together so if nobody else has a go, remind me of this in a week.
By the way, I know people come up with variants on the JD system all the time, which is great. This whole thing is just an idea; tweak it to your needs.
But if we’re to have this sort of software, your systems must conform to a standard. As per the website: no deviations, nothing clever. Otherwise all of the assumptions baked in to such software will fail.
This is why I’ve started the index file spec. If you build an app and I build an app, they should all be interoperable via a well-documented format.
I started a similar project like this about a year ago. (During a pretty pointless and boring meeting) It wasn’t bidirectional – you opened the command line and told it what to do. (Make a new ID, build/show an index) That’s pretty easy – J.D. enforces a very strict structure which is easy to parse. No corner cases.
I stopped the project when I realized my system is scattered across many places; two mail accounts, an iCloud Drive, physical binders, todo-app, notes app, … Just as @PhillyChuck said.
Building integration between all these would be necessary for it to have any value (to me), and it was just too much work. And to custom for sharing with anyone else.
I’ve come to appreciate the simplicity of the J.D. system and the index idea. It’s like pen and paper. It never breaks. You type - you get.
That said, these are only my experiences, but you might want to consider the boundaries before you embark on this. Good luck!
The embarking happened long ago haha, I have a usable product out on Github that you could download and use if you wanted, although it’s still early and a bit rough around the edges. The way I design this stuff is largely to cooperate with my personal ecosystem, but I include as much flexibility as I can to make it helpful to the widest group of people possible.
