IMO Obsidian is currently the king of "personal software frameworks". You can look at YT channels for inspiration of what other people are doing, but I'd avoid trying to copy someone else's setup (for the vague promise of productivity), and instead just start to tinker and tailor your environment to yourself. The base experience is really good. What matters most is that you spend time actually writing useful things down.
For personal use - Obsidian + AI (claude code / codex) + self-authored plugins is the best AI experience available. Folks like Karpathy have been writing a bit about LLM-powered wikis and context management. That seems to be causing a big wave of interest at the moment.
What I see from our business customers is all about AI in a collaborative context. The more advanced customers are typically developing an in-house plugin for their agent so they can make setup really easy, centralize token tracking, and aggregate learnings (while respecting employee privacy/customization). We also see strong interest in the privacy/security aspect from red teams (trying to track the huge influx of vulnerabilities).
IMO the practices for using Obsidian effectively in a work environment are under-represented on YT and in tutorials (we have done some light consulting in this area).
Speaking as someone who has been building a business around an Obsidian plugin - I think you're on the right track.
What actually matters is that the plugin developer is pro-social, discloses the behavior, the user accepts that disclosure, and that the user isn't duped by their inability to review all of the code for every update.
For those not aware, it has basically been impossible to submit new plugins due to the manual review (and how easy/fun it is to write a plugin with AI). The developer community was becoming increasingly frustrated, and the team was burning out under the load.
So congrats to the team! This relieves a huge scaling bottleneck. It has been really cool to see how y'all build and scale.
Hey kepano - can you please grandfather in existing plugin IDs?
Forcing a migration seems really user-unfriendly unless there's a symlink or something.
We have a "caution" score because our plugin (system3-relay) has a 3 in it (part of our business name), and we have thousands of daily active users that would need to essentially download a new plugin if we change it.
IMO this is an outdated view. Existing developer platforms have had to rely on static heuristics and capability-based permission systems, but now AI can run at scale and surface a lot of user-unfriendly intent that wasn't possible before.
The permission system are definitely useful for hard limits - but AI review can surface way more detail (what kinds of things are actually sent over the network, etc).
> I don't think Obsidian does synchronous collaboration well (could be wrong) but for asynchronous collaboration it ought to be fine.
If you want to do real-time collaboration in Obsidian there are a few plugins available. relay.md (mine), peerdraft, screengarden, and YAOS are some options.
This is really cool. I'm excited to dive into the code later today.
Im building something similar but have been working from the opposite direction.
I started by making Obsidian real time collaborative (relay.md), and have been slowly heading in the direction of yjs backed filesystem (that supports the obsidian graph "protocol").
IMO the obsidian editor is best-in-class, and the important thing is owning sync. I also wish it was open source, but I'm also impressed with their business model (100% user funded) so I'm happy to support them.
I've found that many devs starting with the infrastructure tend to hand wave conflict UX with yjs. It can be useful to support LWW in certain scenarios like updating links across many files, or frontmatter updates.
Automated find-and-replace is particularly bad in yjs/ytext because deletes are idempotent but inserts are not. race conditions trigger broken links. (I call this the "machine edits" problem, not sure if there is a better name).
I think the other underexplored discussion for local first apps is how to build a business so that you can afford to work on it full time.
I was early at Planet (and fresh out of college) and the transition internally towards govt money was very painful for the bright eyed save-the-world hackers internally.
The initial technical architecture was aligned with broad good (low res, global, daily, openly available), but the shift towards selling high res satellite capabilities directly to governments has been tough to see.
Their role of providing a public ledger is still a net good thing IMO, and i doubt Planet is adding much increased capability to the US war fighter (they have way better stuff). Harder to say for their deals with other governments that have fewer native space capabilities.
We let docs converge independently. This is a problem for bases in the current sync engine, but something we're resolving soon with "continuous-background-sync". I think it is also more scalable and matches the file model better.
We landed on folder-level sync rather than vault-level sync, so we have a map CRDT that corresponds with each shared folder. In our model these CRDTs are the ones that can explode, whereas the doc-level ones can kind of be fixed up by dragging it out of the folder and back in again which grabs a new "inode" for it.
If I were to start again I think I'd try to build a file-based persistence layer based on prolly-trees to better adhere to the file-over-app philosophy.
The hardware feels great to hold (though the touchpad is still meh). I covered the Google logos with a glossy black vinyl Obsidian sticker.
https://notes.danielgk.com/Hardware/Travel+Laptop