266 karma · joined October 10, 2013
email me: hn@danielgk.com
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...
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.
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.
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.
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'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 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.
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.
Mine uses an Envoy sidecar on a sandbox container.
I use it with pocketbase and it is a delightful and very productive setup.
This guide [2] is for an older version of pocketbase and litestream, but i can update it if would be helpful/interesting for anyone.
[1] https://github.com/benbjohnson/litestream/
[2] https://notes.danielgk.com/Pocketbase/Pocketbase+on+Fly.io
For example, If I want to write a skill that can pull subscription cancellations from today, research the cancellation reason, and then push a draft email to gmail, then ideally I'd have...
- a 5 minute read-only token for /subscriptions and /customers for stripe
- a 5 minute read-write token to push to gmail drafts
- a 5 minute read-only token to customer events in the last 24h
Claude understands these APIs well (or can research the docs) so it isn't a big lift to rebuild authz, and worst case you can do it by path prefix and method (GET, POST, etc) which works well for a lot of public APIs.
I feel like exposing the API capability is the easy part, and being able to get tight-fitting principle-of-least-privilege tokens is the hard part.
1. You can issue your own tokens which means you can design your own authz in front of the upstream API token.
2. Macaroons can be attenuated locally.
So at the time that you decide you want to proxy an upstream API, you can add restrictions like endpoint path to your scheme.
Then, once you have that authz scheme in place, the developer (or agent) can attenuate permissions within that authz scheme for a particular issued macaroon.
I could grant my dev machine the ability to access e.g. /api/customers and /api/products. If i want to have claude write a script to add some metadata to my products, I might attenuate my token to /api/products only and put that in the env file for the script.
Now claude can do development on the endpoint, the token is useless if leaked, and Claude can't read my customer info.
Stripe actually does offer granular authz and short lived tokens, but the friction of minting them means that people don't scope tokens down as much.
Someone on another thread asked me to share it so I had claude rework it to use docker-compose and remove the references to how I run it in my internal network.
Here's the repo [1]. I modified it a bit to post publicly and remove the details of my setup within my tailnet/flycast network.
1. What do the tokens look like that you are you storing in the client? This could just be the secret (but encrypted), or you could design a whole granular authz system. It seems like tokenizer is the former and Formal is the latter. I think macaroons are an interesting choice here.
2. Is the MITM proxy transparent? Node, curl, etc allow you to specify a proxy as an environment variable, but if you're willing to mess with the certificate store than you can run arbitrary unmodified code. It seems like both Tokenizer and Formal are explicit proxies.
3. What proxy are you using, and where does it run? Depending on the authz scheme/token format you could run the proxy centrally, or locally as a "sidecar" for your dev container/sandbox.
The idea is that you can arbitrarily scope down credentials with macaroons, both in terms of scope (only certain endpoints) and time. This really limits the damage that an agent can do, but also means that if your credentials are leaked they are already expired within a few minutes. With macaroons you can design the authz scheme that *you* want for any arbitrary API.
I'm also working on a fuse filesystem to mount inside of the container that mints the tokens client-side with short expiry times.
Your skill will be tuned to your use case over time, so if there's something that you do a lot you can hide most of the back-and-forth behind the python script / cli tool.
You can even improve the skill by saying "I want to be more token efficient, please review our chat logs for usage of our skill and factor out common operations into new functions".
If anything context waste/rot comes from documentation of features that other people need but you don't. The skill should be a sharp knife, not a multi-tool.
https://notes.danielgk.com/Obsidian/Obsidian+E2E+testing+Cla...
I ended up using it (and enjoying yolo mode!) but then my sprites weren't pausing and i was worried about spending too much so i deleted them.
I can try to write it up (I am a bit behind this week though...), but I basically opened claude code and said "write a new skill that uses the chrome debug protocol to drive end to end tests in Obsidian" and then whenever it had problems I said "fix the skill to look up the element at the x,y coordinate before clicking" or whatever.
Skills are just markdown files, sometimes accompanied by scripts, so they work really naturally with Obsidian.
Plus, now it is personal software... just keep asking it to improve the skill based on you usage. Bake in domain knowledge or business logic or whatever you want.
I'm using this for e2e testing and debugging Obsidian plugins and it is starting to understand Obsidian inside and out.
What is the contract with sprites? Is it just built-with-linux but not promising Linux? Or is it more like a machine but y'all control the container image?
Tokenizer is an explicit proxy though right?
My use case is very similar, but I wanted a transparent proxy so I could run unmodified scripts. It is a tricky design decision though.
I also mount a little fuse filesystem that mints macaroon on read (with a shorter lifetime, probably inspired by y'all but i forget from where).
I work on realtime collaboration of markdown files (currently in Obsidian), which has become a shared-context substrate for agents, skills, etc.. Our own company workspace has skills that have scoped access to fly, stripe, gmail, etc. We're definitely drinking the file-over-app personal-software-for-teams Kool-Aid, so the problem space for us includes access control and auditing.
Love your work :)
I've been thinking a lot about how to run agents (and skills) securely while giving them a lot of powerful capabilities.
I recently used their macaroons library to turn arbitrary API keys (e.g. for stripe's API) into macaroons. I route requests for an upstream host (like stripe) through Envoy as a mitm proxy which injects the real creds after verifying the macaroon.
It is such a powerful pattern. I'm always worried about leaking sensitive keys through prompt injection attacks (or just sending them to anthropic), but in this model you can attenuate the keys (both capabilities & validity window) client side. The Envoy proxy lives inside my flycast network so it can't be accessed externally.
It would be so cool if fly built something like this into sprites.dev (though I can see how it would be spooky to have fly install their own certs for stripe, etc...)