shake-n-fries
Joined 6 years ago
Joined 6 years ago
Sounds like your setup achieves basically the same thing as Jotbus. If you've already got repo/server/skills wired up for this, Jotbus probably wouldn't buy you much.
I had basically 2 motivations for building it:
- I was frequently spinning up places to dump stuff for people/agents. I wanted to make it simple across environments, and have no infra or glue to manage.
- a lot of what I pass around is mid-work/transient - logs, partial implementations, screenshots, etc. Not ready for a commit, don't necessarily want it in git history. Wanted to make it easy to hand off and keep going.
So it's not exactly a novel primitive, it's just a tool to make it quicker/easier.
I frequently have to copy-paste context and files between different coding agents, either between my different environments/machines, or from me to teammates.
I built Jotbus so I wouldn’t have to keep doing that.
You can try it free with:
npx jotbus
No login or signup required. It creates a temporary shared workspace and connects it to the coding agents you use via MCP.
Once it's installed, you can just tell your agent something like
"write this handoff note to jotbus"
or
"send that PDF over Jotbus to @codex"
Then another agent can join the workspace and pull the context.
Messages and files are end-to-end encrypted. Encryption happens locally, and the hosted service only stores ciphertext; the workspace key never reaches Jotbus.
If you try it out, I'd love feedback!
Thanks!
1a. a joining client never generates or fetches a key, so there is no "failed to fetch" error path. The client needs a key to join, and it's wrapped as part of the invite. Keys are never generated server side, and only the workspace creator can create one for that workspace.
1b - All read and write attempts are fingerprinted against the encryption key, and if they don't match, the request is rejected. So it's not possible for an agent with a mismatched key to overwrite or change data.
2. A workspace owner can revoke a key and generate a new one in the browser dashboard (may add a terminal version of this soon). The contents of the workspace will be decrypted client-side with the old key, then re-encrypted with the new one. None of this ever hits the servers.
If a key is revoked, users with the old key won't be able to read from or write to the space anymore (but they will, of course, still have locally any content they had previously fetched). In other words, there is one shared encryption key per workspace. If the workspace owner wants other users to continue using the same space, they'll need to share the new encryption key / invite, and the other users will need to re-add the space to their agent.
I am currently looking at per-user key wrapping and revocation. Let me know if this is a feature you're looking for!
Hope this helps clear things up. If you have any more feedback or questions, please let me know!