Looks pretty cool, although I'm not sure I see the advantage over a skill using something like a private git repo / file store / server?
So far, I've used that, a UNIX-socket inspired approach to push/pull with a remote git (hosted on my server) that the branches/files can be tossed to, and pulled via other agent. Skill instructs them to make a copy-paste ready instruction for the other prompt.
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'm very curious about the viability of this. Like many, I've built something along the same lines, twice (for personal, and work use); I staple on the features as I need them. On the one hand, it doesn't feel unique enough to attempt to polish and monetize. Then on the other, I expected thousands of these and yet when I look at my colleagues workflows, they aren't doing this. So I'm curious if it'll work out that its simply more efficient to use a paid service like this which you can drop into place, than rolling your own.
Two other quick thoughts. One is I think if people are struggling with costs, they really should explore a worfklow like OPs. Merely breaking up long running tasks by producing summaries / next steps and spinning up new agents off of them greatly reduces runtime costs. I'm regularly running out of time / mental energy these days than my $20 claude subscription, but I realize if I don't note share early and often, I can burn up the quota in 20 minutes. Its amazing the difference. Second is I feel encryption plays an important role. I feel like it is more important than merely keeping your own ideas private, and somehow impacts the generation and evolution of unique / diverse ideas _in general_.
Anyways, good luck OP, the use case is definitely there and important!
I too am curious about the viability of a shared knowledge MCP! Ha, as I did do the work to take the one I’ve built twice and turn it into something others can use. OzBrain.com ~ maybe you don’t have to build it a 3rd time now? :)
It is certainly a benefit that the server only ever sees encrypted data.
I have also worked on E2EE for multi-device shared spaces, and the trickiest bugs weren't in the encryption itself, but in edge cases related to key distribution. I have two questions regarding this:
1. When a new client joins but fails to retrieve the workspace key (due to temporary network issues or a 404 error from the server, for example), does it ever generate a new key locally? We encountered exactly this scenario: a device "helpfully" created its own key and encrypted data with it, rendering the message unreadable to other members (without any error notification). We ended up changing the server behavior so that instead of returning a "key missing" response, it signals that the key exists and the client should wait for it.
2. How do you handle key revocation? If you invite someone and later remove them, do you rotate (update) the workspace key and re-wrap it for the remaining members, or does the old key still allow access to past content?
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!
The concept of per-user key wrapping is interesting.
I learned this the hard way... just because a wrapped key exists on the server doesn't guarantee the recipient can actually unwrap it—for instance, if the recipient's identity key has changed due to a re-installation. Implementing a mechanism to verify successful decryption on the client side before discarding the old key helped prevent situations where users would lose access to their own data.
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.
Looks like a really cool project, especially for quick no-setup use cases.
If you prefer to keep things local and open source, and your agents' notes do fit in issues, you might want to check out Epiq too, which is a local but distributable issue board synced via an event log mechanism to ensure consistency when syncing across repos:
I built something similar recently but it also supports file sharing. So you can read a markdown file in the UI, read code in UI, share with a friend, share with an agent, etc. https://agentdrop.lol/
Looks pretty cool, although I'm not sure I see the advantage over a skill using something like a private git repo / file store / server?
So far, I've used that, a UNIX-socket inspired approach to push/pull with a remote git (hosted on my server) that the branches/files can be tossed to, and pulled via other agent. Skill instructs them to make a copy-paste ready instruction for the other prompt.
Why'd Jotbus be worth the overhead?
Thanks for the comment!
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'm very curious about the viability of this. Like many, I've built something along the same lines, twice (for personal, and work use); I staple on the features as I need them. On the one hand, it doesn't feel unique enough to attempt to polish and monetize. Then on the other, I expected thousands of these and yet when I look at my colleagues workflows, they aren't doing this. So I'm curious if it'll work out that its simply more efficient to use a paid service like this which you can drop into place, than rolling your own.
Two other quick thoughts. One is I think if people are struggling with costs, they really should explore a worfklow like OPs. Merely breaking up long running tasks by producing summaries / next steps and spinning up new agents off of them greatly reduces runtime costs. I'm regularly running out of time / mental energy these days than my $20 claude subscription, but I realize if I don't note share early and often, I can burn up the quota in 20 minutes. Its amazing the difference. Second is I feel encryption plays an important role. I feel like it is more important than merely keeping your own ideas private, and somehow impacts the generation and evolution of unique / diverse ideas _in general_.
Anyways, good luck OP, the use case is definitely there and important!
I too am curious about the viability of a shared knowledge MCP! Ha, as I did do the work to take the one I’ve built twice and turn it into something others can use. OzBrain.com ~ maybe you don’t have to build it a 3rd time now? :)
Thanks a lot for the thoughtful response!
It is certainly a benefit that the server only ever sees encrypted data. I have also worked on E2EE for multi-device shared spaces, and the trickiest bugs weren't in the encryption itself, but in edge cases related to key distribution. I have two questions regarding this:
1. When a new client joins but fails to retrieve the workspace key (due to temporary network issues or a 404 error from the server, for example), does it ever generate a new key locally? We encountered exactly this scenario: a device "helpfully" created its own key and encrypted data with it, rendering the message unreadable to other members (without any error notification). We ended up changing the server behavior so that instead of returning a "key missing" response, it signals that the key exists and the client should wait for it.
2. How do you handle key revocation? If you invite someone and later remove them, do you rotate (update) the workspace key and re-wrap it for the remaining members, or does the old key still allow access to past content?
Great questions!
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!
Thank you! That's a clean design.
The concept of per-user key wrapping is interesting.
I learned this the hard way... just because a wrapped key exists on the server doesn't guarantee the recipient can actually unwrap it—for instance, if the recipient's identity key has changed due to a re-installation. Implementing a mechanism to verify successful decryption on the client side before discarding the old key helped prevent situations where users would lose access to their own data.
Hey everyone,
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!
Looks like a really cool project, especially for quick no-setup use cases.
If you prefer to keep things local and open source, and your agents' notes do fit in issues, you might want to check out Epiq too, which is a local but distributable issue board synced via an event log mechanism to ensure consistency when syncing across repos:
https://ljtn.github.io/epiq
I built something similar recently but it also supports file sharing. So you can read a markdown file in the UI, read code in UI, share with a friend, share with an agent, etc. https://agentdrop.lol/
Oh neat - I’ve been looking for a provider-agnostic version of Claude Artifacts for a while. This might do the trick!
Thanks for the comment. Jotbus supports files as well :)
A priori sounds like delta by the same team as zed. Taking a look now
good
thanks!