The way I see it, having lots of agents that work together across different computers is mostly about a sync-up problem dressed up as something else. Loopsy is a clean tool for sending messages, but I get tripped up on which agent has control of a file at any moment, and what happens when two terminal sessions write to the same file within half a minute.
I really need a tool that locks files for editing rather than just one for sending messages. Should the second machine's agent wait its turn until the file is free, or should it create its own branch of the file to merge later? With Loopsy, what we're getting is more like a mailbox system, but in my own setup, the lock would be the right approach in most cases.
I have a single rule listed in CLAUDE.md that just reads, "do not modify child project files from parent context." This is because the parent git repository only contains meta-files and automation, and the agent constantly forgets it during sessions, especially when switching machines. After about ten weeks, I added .sync-conflict-* files to my .syncignore.
Yeah that’s valid. Loopsy as it is is a coordination layer not a concurrency layer. There’s no file locking primitive at the moment. What is there is a task queue protocol which gets you close by having one agent claim a task while others wait.
For single files we’d need to build the lock key mechanism on top of the Loopsy context store.
Even if alternatives and (for now shoddy) 'official solutions' exist, I just like...
> I know I might be reinventing the wheel, but I love that it just works.
Not calling _you_ a learner, just calling out to this -- when teaching people to program I've almost invariably told them to focus on getting something practical working.
I hope that a lot more people get to experience this pattern as a result of LLMs. With enough experimentation I'm excited for what creativity we draw out of people.
Nice. CodeNomad looks solid for opencode. The differences I see, Loopsy works with other coding agents, control from your phone with a native app, and daemons that find each other on a LAN. With Loopsy, agents on different machines can drive each other over a standard protocol, not just human-to-machine. I admit though tailscale gets you true P2P encryption, something I'm still working on for Loopsy.
The way I see it, having lots of agents that work together across different computers is mostly about a sync-up problem dressed up as something else. Loopsy is a clean tool for sending messages, but I get tripped up on which agent has control of a file at any moment, and what happens when two terminal sessions write to the same file within half a minute.
I really need a tool that locks files for editing rather than just one for sending messages. Should the second machine's agent wait its turn until the file is free, or should it create its own branch of the file to merge later? With Loopsy, what we're getting is more like a mailbox system, but in my own setup, the lock would be the right approach in most cases.
I have a single rule listed in CLAUDE.md that just reads, "do not modify child project files from parent context." This is because the parent git repository only contains meta-files and automation, and the agent constantly forgets it during sessions, especially when switching machines. After about ten weeks, I added .sync-conflict-* files to my .syncignore.
Yeah that’s valid. Loopsy as it is is a coordination layer not a concurrency layer. There’s no file locking primitive at the moment. What is there is a task queue protocol which gets you close by having one agent claim a task while others wait.
For single files we’d need to build the lock key mechanism on top of the Loopsy context store.
Even if alternatives and (for now shoddy) 'official solutions' exist, I just like...
> I know I might be reinventing the wheel, but I love that it just works.
Not calling _you_ a learner, just calling out to this -- when teaching people to program I've almost invariably told them to focus on getting something practical working.
I hope that a lot more people get to experience this pattern as a result of LLMs. With enough experimentation I'm excited for what creativity we draw out of people.
Yes, LLMs lower the barrier such that we can skip “can this work” and just skip straight to building.
Well done.
Dependence on Cloudflare… have you considered making it a service that I could install on my own server?
Thank you. The relay is a small websocket server, isolated, so it could be adapted and self hosted. I’ll add it to the roadmap.
We also need to focus on our Roots (alternate for cloud focusing homelab)
Any plans to expose Loopsy as an MCP server?
love this. It feels less like “remote control” and more like turning all your machines + agents into one coherent organism.
Curious how you think about the overlap with something like Tailscale, and where you see Loopsy being strictly better or worse.
A coworker does this with OC + tailscale + https://github.com/NeuralNomadsAI/CodeNomad
Nice. CodeNomad looks solid for opencode. The differences I see, Loopsy works with other coding agents, control from your phone with a native app, and daemons that find each other on a LAN. With Loopsy, agents on different machines can drive each other over a standard protocol, not just human-to-machine. I admit though tailscale gets you true P2P encryption, something I'm still working on for Loopsy.