[dead]
The Future of Obsidian Plugins
61–70 of 186 posts
Re: The Future of Obsidian Plugins
#62I want to use Obsidian... but I won't as long as it's not open source. I know I can keep all my files as plain text, but that's not enough for me. Using a KB on a daily basis shapes my workflows and having to change that from one day to another (e.g., because maybe Obsidian changes in a way I don't like) is too much for me. I could already handle all my plain txt files using simply the file system, but of course I wo…
Just use CherryTree then.
Re: The Future of Obsidian Plugins
#63I want to use Obsidian... but I won't as long as it's not open source. I know I can keep all my files as plain text, but that's not enough for me. Using a KB on a daily basis shapes my workflows and having to change that from one day to another (e.g., because maybe Obsidian changes in a way I don't like) is too much for me. I could already handle all my plain txt files using simply the file system, but of course I wo…
Trusted source > open-source As long as it's trusted, there is no lock-in, and the model supports maintaining the software, what do you have to lose?
I don't think it makes any sense given the history of tech companies to count any of them as a trusted source. Open source doesn't ask for your trust, and it is the only way to get off on the right foot.
Re: The Future of Obsidian Plugins
#64I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
>I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system. I want to say "and especially prevent them from touching my private data (i.e. the whole point of Obsidian plugins being to read/write the documents)". But if it can't talk to the internet, I kind of don't see the issue. EDIT: Apparently due to how JS and Electron works, Obs…
Confirmed: https://obsidian.md/help/plugin-security#Plugin+capabilities
There is no sandboxing at all. Every plugin has full access to your computer.
Re: The Future of Obsidian Plugins
#65I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
>I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system. I want to say "and especially prevent them from touching my private data (i.e. the whole point of Obsidian plugins being to read/write the documents)". But if it can't talk to the internet, I kind of don't see the issue. EDIT: Apparently due to how JS and Electron works, Obs…
Theoretically in an Electron app, you could run plugins in a separate v8 context without the node native FS libraries available. Short of OS-level sandboxing that's probably the best they could do.
Re: The Future of Obsidian Plugins
#66I want to use Obsidian... but I won't as long as it's not open source. I know I can keep all my files as plain text, but that's not enough for me. Using a KB on a daily basis shapes my workflows and having to change that from one day to another (e.g., because maybe Obsidian changes in a way I don't like) is too much for me. I could already handle all my plain txt files using simply the file system, but of course I wo…
[deleted]
Re: The Future of Obsidian Plugins
#67I don't use Obsidian, and my assumption when I saw the title was I guess they're gonna be limiting it to a small set of corporate-blessed plugins.
I've come to expect that "The Future Of XYZ" titles from software companies means severely limiting XYZ or preparing XYZ for a shut down!
Re: The Future of Obsidian Plugins
#68Earlier quoted context omitted.
Got any cool plugins you recommend? I'm finally getting comfortable after switching from OneNote and getting sync set up.
"Ink" for drawing (big miss in the standard feature set IMO, the only one thing I missed coming from OneNote which is horrible in every other way compared to Obsidian). "Self-Hosted Livesync" for syncing on your own server (I don't want my stuff on other people's computers even when encrypted) "Copilot" for AI integration (I use two local ollama servers as you might have guessed from the above :) ) "Whisper" for text…
My version of your list: Excalidraw, Git, Ollama/rarely Claude Code, Handy.computer, Obsidian Clipper
Re: The Future of Obsidian Plugins
#69Obsidian CEO here. We've been working for nearly a year to launch this new Community site and review system. I'm very excited about this first version but there are many more improvements to come. I've tried to be exhaustive with the blog post, FAQs, and next steps on our roadmap, but I am sure I forgot some things, so feel free to ask! This has been an incredibly challenging project for a number of reasons. We're on…
I have a bunch of projects with plugins and I've sometimes thought about introducing a "reviewed" mechanism where the project marks specific versions as reviewed and trusted. One of the things that's held me back (aside from the huge time commitment) is my fear that people will come to depend on that review process, such that if the process misses an obfuscated exploit the project itself will be blamed for the subseq…
I can't speak for other platforms but neither option you propose seems right for Obsidian. I think the right approach for us is somewhere in between.
If we were too controlling there wouldn't be the freedom of exploration that we see in the Obsidian community. There are so many niche use cases. Plugins can target a minuscule number of users, and that's a great thing. That's why malleability is one of our core principles: https://obsidian.md/about
I also believe in treating users with intelligence. Obsidian has always skewed towards giving you the maximum freedom at the cost of letting you shoot yourself in the foot.
It's impossible to guarantee that software has no bugs and no vulnerabilities, especially not third-party plugins. However that doesn't mean that we shouldn't try to detect dangerous or malicious behaviors. Any transparency we can provide in this regard seems helpful if it can be presented in a way that helps users make their own informed decisions.
Re: The Future of Obsidian Plugins
#70Earlier quoted context omitted.
I have a bunch of projects with plugins and I've sometimes thought about introducing a "reviewed" mechanism where the project marks specific versions as reviewed and trusted. One of the things that's held me back (aside from the huge time commitment) is my fear that people will come to depend on that review process, such that if the process misses an obfuscated exploit the project itself will be blamed for the subseq…
I can't speak for other platforms but neither option you propose seems right for Obsidian. I think the right approach for us is somewhere in between. If we were too controlling there wouldn't be the freedom of exploration that we see in the Obsidian community. There are so many niche use cases. Plugins can target a minuscule number of users, and that's a great thing. That's why malleability is one of our core princip…
Thanks. I think it's likely I'm seeing this as a binary situation when actually it doesn't need to be that way.