The plugin is still a little unstable & inconvenient, so that will be my focus before adding more features.
I’d like custom settings per device, but there’s a big problem with enabling lazy loading only on a specific device: Obsidian Sync syncs disabled plugins (which lazy loaded plugins technically are).
(Ideally Sync could separate specific plugin settings based on device for you.)
That said, the plugin is actually incredibly simple. Most the code written is for the settings panel. . I’m hoping to get a real release by the end of the week.
In short, I’m concerned about slow downs after implementing device specific settings.
For example, If a plugin is lazy loading only on your phone, due to how Obsidian Sync syncs plugins, my plugin would have to load it on your computer as well. This would likely cause a startup delay instead of an improvement.
That said, I have yet to fully test the scenario. Hopefully I’ll find some middle ground for implementation.
I’ll try to get BRAT compatibility before next update; however, this is a priority as I have a bias against BRAT.
Thanks for the feedback.
I highly disagree with that sentiment. Comments inside a program are a poor version of documentation.
A literate program is first and foremost meant to be read by a human. Extracting the code for execution is a secondary issue, which in my case is solved by Org-mode.
@ohm.one I was casually flipping through this thread not having really read the actual initial post. I had the idea of plugin management & lazy loading in my mind, then found myself reading Securing Obsidian - Boxes and Walls from your blog. Long story short I pictured that perhaps you were developing some sort of plugin that would temporarily give certain plugins access to the system in some way that it would allow them to be functional after the fact without still having that access. I can’t imagine something like that is possible, but I just felt like mentioning it. Also, thanks for the time you have put into this and the thought you put into the article I mentioned. Good luck!
But it ignores a much more common way to familiarize oneself with a codebase: looking at snippets of code in its actual context, and making use of IDE’s understanding of code to jump around and see what what a reference means. I can’t do that by clicking in a README. In fact, I don’t need an IDE anymore as I can use GitHub’s new feature: https://docs.github.com/en/repositories/working-with-files/managing-files/navigating-files-with-the-new-code-view
The idea of literate programming is not new. There’s a reason it hasn’t taken off in all these decades. But let’s revisit in another decade when you will inevitably agree that the situation will not have changed
I appreciate the thought. Thanks. However, I agree with you, there’s no way to securely manage plugin permissions from within the same JavaScript environment. It would be nice though.
Please feel free to look at the code in its “actual context”. You can find it here in the repository.
And yes, this current code-base isn’t actually meant to be read. I haven’t had the time to finish it as it was originally a TypeScript project, which I wrote several months ago.
I don’t mind speaking to why I like literate programming, but that’s not for here. If you would like to “change my mind”, please do so somewhere else.
It should work with BRAT now. Let me know if it doesn’t.
It most certainly seems like a useful tool; however, I have a bias against most all extended packaging of binaries. They’re woefully insecure.
That said, it’s not as if the Obsidian Package Manager is different. I’m not particular for it either. Ideal “package” management is hard to come by, so I suppose this wasn’t a appropriate place to speak my thoughts on the matter.
P.S.
I failed you realize you were BRAT’s creator. At the very least, I was very happy for the brief moments I used it to confirm my plugin was working properly. I wouldn’t expect more. Thanks.
Actually, counter-arguments to its usefulness or concerns about security are interesting to me. BRAT is very dangerous if people don’t know what they are doing or who they trust.
I thought you might have a specific instance of concern.
Regarding packages uses by plugins, this is a hard balance. Plugins make the difference for me to use or not use obsidian. But we need just one bad plugin to sneak in and well… that will be a lot of fun.
Actually, the idea of “one bad plugin” isn’t a big concern to me. The real problem is with potential malicious updates. For instance, if you, the maintainer of BRAT and others, were to be “hacked” with intent, the attack could easily push a malicious update to far too many users under your credibility.
Furthermore, BRAT worsens the issue in the worst case scenario. There is no delay to updates, nor is there a way to inform the user of a malicious update.
The easiest way to improve credibility–security–would be to embed a GPG key from the plugin author along with a relevant hash to each installed plugin. This way, an attacker would also have to gain access to the keys in order to push a malicious update.
. I’m hoping to get a real release by the end of the week.
