I've been using Joplin for some time now (migrated from Evernote). It is a wonderful tool <3
I still have one directory of notes, that is outside Joplin (and inside of one of my git repositories). The reason for it not being inside of Joplin is that I need to have those notes as files on my desktop filesystem. That is because I add those files to my IDE workspaces (vscode, intellij) so I'm able to search for answers from the context of IDE search.
If I stored those notes in Joplin, I would need to alt-tab to the Joplin app. And that is something not very useful, as I use those notes very often, while working in the IDE.
So the question is - do you have any solution for that? Because if not - I already started thinking about designing a service, which would sync 2-directionally notes from specified Joplin tree to the filesystem and other way around (using API provided by the Joplin app)
As graphit0 linked, I have done some groundwork towards filesystem sync, but stopped at the demo stage. If you're looking to build it out further (or your own more complete version), or potentially collaborate, feel free to reach out to me via dm here. I'd love to chat!
It feels like that between JoplinFS and the hotfolder plugin some kind of external file sync could be created. But that makes new notes each time I think...
I went briefly through your project just to get a better understanding of it. I really like the idea of using the fuse for this to make it work - very smart imo
What I don't like tbh is the Python part (not the code, but the technology), as it makes installation a bit cumbersome on the user platform (proper Python version, dependencies etc). It might be easier to use w/containers but it would add another unnecessary dependency (on the container engine if Docker or libs like Podman). And that again might be problematic, as not sure what's the current state of things for native containers outside of Linux.
Also, the mentioned limitation "This only a thin wrapper around the Joplin API, so mass operations (like grep) will be very slow and are not recommended." is smt I can see is an issue for the use-case I'm thinking about.
Some of loose ideas I had when thinking about the mentioned use-case:
It is not about mounting the whole Joplin notes tree, but rather for selected leafs/directories. This could help with the performance. Ofc optionally, the user could mount the whole Joplin tree, but it I'd discourage doing this.
It is only for Markdown text files. So all those notes could be held in-memory. I went through all my notes since 2003, and can tell, that text is only around 35Mb. This is a very low amount of memory for today PCs. Ofc, there could be some potential cache involved, so it could make the starting app a bit faster and not cause a huge number of api calls to the Joplin api-server.
No support for attachments. Only pure text.
I'd like to have just a binary, which would be used to run and mount the FS. Go, Rust - seem like languages with proper fuse support and are very safe in terms of memory management.
From the performance point of view, I'm not sure if syncing events from Joplin API could be done simultaneously via more than one thread or not. I don't know the Joplin API yet that well, to tell, how performant it is. But in a case when it could be done, I'd go w/language where threads are safe and stable. Again - Go or Rust.
At this point I don't have any opinion on dealing with notes conflicts, as basically, I haven't went too far with the Joplin API.
Also - for starters I'd think about RO mode first, but implement it in a way, that holds doors opened for the RW a bit later.
Also - there are plenty of things to think about. E.g. how to support events like moving notes, renaming, deleting etc. Not sure how Joplin events API support those, and how to theoretically, support it on the FS side.
That's it for now. So as you can see - I haven't really think about it too much yet - just touching the ground and thinking about possible options.
Agreed, this was a demo project where performance/distribution were not the primary goals. Funny enough, at the time I started the project the pyfuse3 library was officially maintained by the libfuse team, but was moved to no-maintenance shortly after I released JoplinFS.
This would certainly speed things up, but I wonder if the hotfolder plugin would be a better fit for this use case? I'm not sure if it has bi-directional syncing, but some sort of sync might be a simpler/more robust solution. It would also allow co-mingling of note files inside other projects. For example, there have been more than a few people request the ability to manage readmes and other markdown files in Joplin.
With the FUSE/API approach, there won't be any conflicts.
The api emits events to some of those things (maybe all, I can't really remember).
When thinking about what an actual releasable version of this would be I have basically 2 directions I see it going.
A standalone binary (rust or go) that interacts with Joplin through the api and caches as much as possible. This is similar to what the demo I created does, but I would use sqlite to build a better cache.
Use nodejs bindings to libfuse and build the project into the Joplin desktop app. This is probably the best solution because we wouldn't be limited by the api, and could interact with notes in an almost identical way as the UI. This would be the most performance AND the most easily distributed. The catch is that it might be the most challenging to develop, and it might not be desirable to include it for the few users that need that extra functionality.
I went through dos of this plugin and learnt, that it's rather a one-directional sync:
Each newly created file in the hotfolder is automatically created as a new note. The files are added as attachments unless the file extension is defined as Add as text. After processing the file are deleted from the hotfolder.
So, not really my use-case, as I'd say, that 80% of my workload would be reads, and rest would be about writing. I thought about possibility of extending this plugin, but first, unfortunately, I'm not a JS person, and second - that would completely change this plugin goal.
I agree, that the second approach, with direct communication to the Joplin DB would be much more performant. However - as I wrote before, I'm not really a JS person, thus I was mainly thinking about the first approach. Also, because I'm rather a systems engineer, very closely working to filesystems, so I have some skills and exp on this side. I'd love to help you with mentioned, JS approach and extending the Joplin app, but unfortunately, I'm not able to do this at this point.
