I have a matte black Pixelbook Go running PopOS and i love it.
The hardware feels great to hold (though the touchpad is still meh). I covered the Google logos with a glossy black vinyl Obsidian sticker.
HN user
working on: https://relay.md
email me: hn@danielgk.com
I have a matte black Pixelbook Go running PopOS and i love it.
The hardware feels great to hold (though the touchpad is still meh). I covered the Google logos with a glossy black vinyl Obsidian sticker.
let's collab! daniel @ relay.md
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).
(I'm the developer of Relay / https://relay.md )
There are a handful of plugins that might help. Obsidian sync works well for device sync and the CLI is great for agentic stuff.
For real-time collaboration, some options are:
- Relay
- Peerdraft
- Screen garden
(full disclosure - I am the developer of Relay)
Yeah, the answer definitely isn't "hey claude is this a good plugin?" as the only gate.
But for defense in depth, we've never had a more powerful tool to figure out if a plugin is being respectful of user-intent at scale.
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.
Thank you <3
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).
Thanks for the kind words Chris :)
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.
It seems like you're using stable IDs for the links. Did you run into issues using the name like Obsidian does?
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.
Nice! Do you have a skill that describes this workflow?
The Obsidian kanban plugin does this. I recently added support for it in my real-time-collaboration plugin (Relay).
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.
This is really wholesome. Thanks for sharing.
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.
IMO Obsidian Sync is a fantastic solution for e2ee device sync in Obsidian. It is a good/honest business model to fund the development of Obsidian.
What complaints are you hearing?
Great work Kavin!
This is a super interesting space, and lots of fun and difficult problems to tackle.
A few trailheads of interesting complexity:
1. Concurrent machine edits - in particular handling links to renamed files across devices. This is a case where CRDTs fall over because they converge but are not idempotent. For example renaming a file [[hello 1]] to [[hello 2]] when multiple devices are online can result in [[hello 22]] because deletes merge before inserts.
2. Ingesting disk edits in the age of claude code. The intended behavior can change based on what I'm calling the "intent fidelity spectrum". I've been using that spectrum as a guide for when to apply merges in "text space" vs. "crdt space", including sometimes withholding ops based on origin (e.g. from obsidian processFile calls), cancelling them) or offline status. For example, if you made edits while offline and have a least-common-ancestor you may be able to look for conflicts via diff3 and then conditionally use diff-match-patch if there are no conflicts, or surface the conflict to the user if there's not a good merge strategy based on the low levels of intent.
3. History and memory management - how do you recover state if a user has a competing sync service which causes an infinite loop in file creation/deletion. This can be difficult with CRDTs because the tombstones just keep syncing back and forth between peers and can be difficult to clear. This is significantly worse if you use Y.PermanentUserData (do not recommend...).
I'm working on something similar with https://github.com/dtkav/agent-creds though I keep growing the scope.
The model is solid. It feels like the right way to use YOLO mode.
I've been working on making the auth setup more granular with macaroons and third party caveats.
My dream is to have plugins for upstreams using OpenAPI specs and then make it really easy to stitch together grants across subsets of APIs.
I think there's a product in here somewhere...
Hey, developer behind Relay here.
Yes, our sync engine is home-grown. We use CRDTs to provide real-time google-docs-like collaboration which is not something Obsidian supports (yet... i think they are working on it).
Note that you can self-host a Relay server and join it to our network. This gives you complete control over your data and unmetered storage. We do still charge for seats if you have more than 3 collaborators.
I've been working on something similar (with claude code).
It's a sandbox that uses envoy as a transparent proxy locally, and then an external authz server that can swap the creds.
The idea is extended further in that the goal is to allow an org to basically create their own authz system for arbitrary upstreams, and then for users to leverage macaroons to attentuate the tokens at runtime.
It isn't finished but I'm trying to make it work with ssh/yubikeys as an identity layer. The authz macaroon can have a "hole" that is filled by the user/device attestation.
The sandbox has some nice features like browser forwarding for Claude oauth and a CDP proxy for working with Chrome/Electron (I'm building an Obsidian plugin).
I'm inspired by a lot of the fly.io stuff in tokenizer and sprites. Exciting times.
I think mostly social accountability.
My cofounder actually has a bunch of skills with claude code that surface context into our daily notes (from our meeting notes, transcripts, crm, gmail, etc), but it's sort of on him to show that it is useful... so while he is still "hoarding" outside of the shared context it is with an eye toward delivering actual value inside of it.
Feels pretty different from the fauxductivity traps of solo second brain stuff.
I work on a plugin/platform that makes Obsidian collaborative (relay.md).
Working with other people gives you good habits against hording because you have a sense of the audience and what might be useful to them.
We also support the kanban plugin so that works well to track and share what we're working on.
I'm rendering a few dozen terminals in a website, and for all of the inactive ones i render and serve a jpg of the "current screen" of ansi escape codes from kitty.
I've found this to be a difficult thing to get. abduco doesn't have current state, and I dont want all of the complexity of tmux. I also don't want the entire scrollback history (until i click into a given terminal and connect with xterm).
I'll give zmx a closer look. Thank you.
We just have all meeting transcripts go to Obsidian (and get processed/mined) as well as our collaborative notes (our startup makes Obsidian collaborative) for our standups and then use claude code to summarize each day into the next.
We avoid the browser agents entirely, and thus avoid the scattered context. Claude code + markdown files in our vault.
It works remarkably well. I am bullish on unix tools and text files - dom parsing, rag, etc feels like solutions to unnecessary problems.
ooh nice. Is there a way to get snapshots of the current view? I hacked together something with kitty and abduco but it is definitely a hack...
I dont want tmux or anything that gives me additional key bindings or modes, just the ability to pick up my work on another machine.
nice, I'm working on something similar with macroons so the tokens can be arbitrarily scopes in time and capability too.
Mine uses an Envoy sidecar on a sandbox container.