Remix.run Logo
kepano 4 hours ago

Obsidian 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 only seven people but we have thousands of plugin developers and millions of users. There are many competing priorities to balance.

We wanted to make sure the new system would be easy to adopt, backwards compatible, and not completely break people's workflows, while still being a major improvement over the old approach, and allow us to gradually continue enhancing security and discoverability of plugins.

Consider it a work in progress. We're listening to everyone's ideas and gripes, and will keep iterating :)

zie 11 minutes ago | parent | next [-]

I love that under disclosures "Plugin might make requests to 1 external domain", if you click on it, it shows the domain: "github.com". great work!

Example from https://community.obsidian.md/plugins/zotlit

trvz a minute ago | parent [-]

I'd say that doesn't help at all and may actually be harmful in some cases. Amateur users may have heard of Github and would therefore trust that domain, but you can upload malware to Github just as easily as anything else.

simonw 3 hours ago | parent | prev | next [-]

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 subsequent attacks.

How are you thinking about that?

To me it feels like the difference between the Debian/Ubuntu approach - everything in their registry is tightly reviewed - and the PyPI/npm approach where there's no review guarantees at all.

kepano 2 hours ago | parent [-]

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.

simonw 2 hours ago | parent | next [-]

Thanks. I think it's likely I'm seeing this as a binary situation when actually it doesn't need to be that way.

an hour ago | parent | prev [-]
[deleted]
AntiUSAbah 12 minutes ago | parent | prev | next [-]

Finally!

When i tried obsidian and discoverd that the data table thing was not build in but some plugin which has full access, i deleted Obsidian quickly after.

But you are only 7 people? Crazy :D

obsidianbases1 7 minutes ago | parent [-]

Obsidian Bases are built-in data tables.

AntiUSAbah 3 minutes ago | parent [-]

Wow true since last year of may.

btown 3 hours ago | parent | prev | next [-]

Congrats on the launch! Curious about whether the automated scanning system flags expansions of scope and network domain access for internal/human review.

For instance, an AI summarization plugin that starts by saying it accesses url="api.openai.com"+path with a user-supplied OpenAI key is going to be incredibly common - and I'm really excited for what the community builds here!

But what if that plugin has an update that allows the "user" to choose an arbitrary endpoint as an OpenAI-compatible API - how do you ensure that's not a malicious update that has coopted that flexibility to create a network egress that will bypass your scans, and might subtly prefill that with a malicious endpoint?

kepano an hour ago | parent [-]

Every update is scanned, and we will be regularly re-scanning all the latest versions of every plugin as we improve the system. The review system is based on our eslint plugin which itself open source and reproducible, so anyone can contribute to improving it: https://github.com/obsidianmd/eslint-plugin

And since plugins are open source, users can also audit the code and flag issues via the Community site.

chrisweekly an hour ago | parent [-]

Longtime (early adopter) Obsidian user here. Thank you for such an amazing tool. And congrats on the launch!

Curious if you considered oxlint^1? (It's a a faster, simpler, near drop-in replacement for eslint.)

1. https://oxc.rs/docs/guide/usage/linter.html

kepano an hour ago | parent [-]

It's the first I am hearing about it, but I'll take a look!

jjice 3 hours ago | parent | prev | next [-]

Fantastic work from the Obsidian team! I'll gladly continue to be a Obsidian Sync user and can't wait to feel more comfortable using community plugins. Seriously excellent work from y'all.

sneilan1 24 minutes ago | parent | prev [-]

Awesome!! Super excited to try this out. Amazing work.