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: Navigating files with the new code view (beta) - GitHub Docs
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
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.
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.