It warms my old heart when projects use the AGPL (or GPL) licence.
It's a "small" thing to do that tells me that you're not just waiting for VC but actually really care about your work and the world.
(I'm not saying that MIT or other similar licences are used exclusively by people that don't care, I understand that sometimes you just don't have the bandwidth)
I guess I’m curious how it applies here. The plugins communicate over a socket, and then the plugins are loaded into an editor. I assume the editor doesn’t need to be AGPL, because nvim is Apache 2 and VS Code is MIT.
But does the plugin need to be AGPL? Does it also have to be “replaceable” where a static build of nvim would violate the license? Can someone bundle a custom written client into a proprietary editor?
It just warms my heart to see the (A)GPL being used in the same way that seeing a friendly gesture, a patient caretaker, punks, hippies, queers or other things I associate with kindness and community building in the wild.
I don’t understand where you’re saying. A/GPL generally just means corporate won’t use your solution, and that others won’t integrate and as such, monetize your solution. You can still be VC funded and monetize your own GPL code yourself? The Zed editor is a great example.
In the early days, Zed's in-editor collaboration features were marketed as a key differentiator. I wonder how many Zed users have used these features on a sustained basis.
Honestly I don't see the value in multiplayer on its own. Where it becomes interesting is when a tool like Zed makes it easy for extension authors to do multiplayer. Let everyone else build the experiences, and let the tool provide the APIs.
'missing complement to git' seems to be a great value proposition. However, I think it is still a long way for this to become an alternative to Google docs or overleaf in the context of projects e.g. hosted on gitlab. We have moved many collabotative projects with external partners to gitlab, but the pain point is always realtime collaboration. Having something like this integrates in gitlab's vs code based online editor with a decent integration with actual commit/merge logic would be a game changer in many projects trying to convince people to switch from SharePoint/Google drive to a git based workflow. The local first thing would be just the cherry on top of it all.
This is awesome! I've been working on something similar but focused on Obsidian called Relay [0].
I'm super inspired by this. We use yjs with a hub (y-sweet) and spoke topology but I've been meaning to check out Iroh and make the hub into a "super peer".
This reminds me of Floobits (started around 2013) that offered cross-editor collaboration using centralized servers. It had plugins for Emacs, Vim, Sublime, and others.
Yep! Daemons on multiple computers speak the Automerge sync protocol. Between daemon and editors, we use a "one-sided operational transform" approach, in an attempt to offload as much work as possible into the daemon (and out of the plugin). If you're interested, you can learn more about Ethersync's architecture in the documentation: https://ethersync.github.io/ethersync/
My bet would be that people confuse it with Etherpad https://github.com/ether/etherpad-lite which is quite old stable project so probably not that exciting.
Writing a mousepad plugin is actually a bit of a pain.
> Note that you'll need all the Mousepad code to build your plugin, as the headers are not installed. We've never gone so far as to actually expose an API for writing plugins, choosing which headers should be installed and documenting this properly.
Which mostly means that you're on your own.
Whilst building one for Ethersync _should_ be fairly easy (exec and ionotify should get 90% there), without documentation - how do you ensure the text buffer gets updated correctly...? I'm not surprised no one has put this together yet.
It warms my old heart when projects use the AGPL (or GPL) licence.
It's a "small" thing to do that tells me that you're not just waiting for VC but actually really care about your work and the world.
(I'm not saying that MIT or other similar licences are used exclusively by people that don't care, I understand that sometimes you just don't have the bandwidth)
I guess I’m curious how it applies here. The plugins communicate over a socket, and then the plugins are loaded into an editor. I assume the editor doesn’t need to be AGPL, because nvim is Apache 2 and VS Code is MIT.
But does the plugin need to be AGPL? Does it also have to be “replaceable” where a static build of nvim would violate the license? Can someone bundle a custom written client into a proprietary editor?
I don't understand. What would prevent the authors from guaranteeing the VCs re-licensing under a different model?
Nothing.
It just warms my heart to see the (A)GPL being used in the same way that seeing a friendly gesture, a patient caretaker, punks, hippies, queers or other things I associate with kindness and community building in the wild.
I don’t understand where you’re saying. A/GPL generally just means corporate won’t use your solution, and that others won’t integrate and as such, monetize your solution. You can still be VC funded and monetize your own GPL code yourself? The Zed editor is a great example.
>corporate won’t use your solution
Look at all the liunx foundations dominated by ms, oracle playing out their corporate politics. Would take that as as good thing.
I'm just saying I get warm fuzzy feelings, that's all <3
Zed also has interesting collaboration features -- editing + voice: https://zed.dev/docs/collaboration
In the early days, Zed's in-editor collaboration features were marketed as a key differentiator. I wonder how many Zed users have used these features on a sustained basis.
Zed's collaboration tech is amazing, but coding just seems to be less collaborative than e.g. meeting notes.
It's pretty awesome that they were able to use the crdt for agent collab. I've been thinking about something similar for my project.
Honestly I don't see the value in multiplayer on its own. Where it becomes interesting is when a tool like Zed makes it easy for extension authors to do multiplayer. Let everyone else build the experiences, and let the tool provide the APIs.
Reminds me of Gobby (https://gobby.github.io).
'missing complement to git' seems to be a great value proposition. However, I think it is still a long way for this to become an alternative to Google docs or overleaf in the context of projects e.g. hosted on gitlab. We have moved many collabotative projects with external partners to gitlab, but the pain point is always realtime collaboration. Having something like this integrates in gitlab's vs code based online editor with a decent integration with actual commit/merge logic would be a game changer in many projects trying to convince people to switch from SharePoint/Google drive to a git based workflow. The local first thing would be just the cherry on top of it all.
The LiveShare plugin in VSCode works well. But maybe not open enough for you.
This is awesome! I've been working on something similar but focused on Obsidian called Relay [0].
I'm super inspired by this. We use yjs with a hub (y-sweet) and spoke topology but I've been meaning to check out Iroh and make the hub into a "super peer".
[0] https://relay.md
Much appreciate seeing the huge wave of new local-first libraries/tools !
Maybe someone can explain how this compares to other solutions like y.js or automerge ?
two people sit in front of same laptop: solved and for decades
Interesting -- compatible with agentic systems? Collaborative editing with an AI?
This reminds me of Floobits (started around 2013) that offered cross-editor collaboration using centralized servers. It had plugins for Emacs, Vim, Sublime, and others.
Obligatory mention of SubEthaEdit: "General purpose plain-text editor for macOS. Widely known for its live collaboration feature."
And, as of 2018, is now open source. Looks like it has had commits as recently as 2022: https://github.com/subethaedit/SubEthaEdit
See also a previous HN discussion at https://news.ycombinator.com/item?id=18550649
We picked our name because of SubEthaEdit (and later, Etherpad)! :)
We keep a table of related project here: https://ethersync.github.io/ethersync/related-projects.html
Ping us if you feel like something's missing! (Looks like we could add Zed, for example.)
Does Ethersync use CRDTs under the hood for conflict resolution, or does it implement a different approach to handle concurrent edits?
It uses automerge [1], so I strongly assume they use CRDTs.
[1] https://automerge.org/
Yep! Daemons on multiple computers speak the Automerge sync protocol. Between daemon and editors, we use a "one-sided operational transform" approach, in an attempt to offload as much work as possible into the daemon (and out of the plugin). If you're interested, you can learn more about Ethersync's architecture in the documentation: https://ethersync.github.io/ethersync/
In addition, we keep a directory of "Architectural Design Decisions" here, which go more into depth: https://github.com/ethersync/ethersync/tree/main/docs/decisi...
There's also a 10-minute talk from this year's FOSDEM: https://fosdem.org/2025/schedule/event/fosdem-2025-4890-ethe...
SubEthaEdit?
https://subethaedit.net/
Fantastic. Finally, something that can be used outside the browser.
I hope there are plans to support more OS.
So ,a glorified TMUX?
5 points and 0 comments? IMO this looks like a very well researched project, not sure why it went under the radar.
My bet would be that people confuse it with Etherpad https://github.com/ether/etherpad-lite which is quite old stable project so probably not that exciting.
Looks like we put it in the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), so it got a random placement on HN's front page a couple days later...where it happily resides for the time being.
If anyone is confused by the relativized timestamps, there are explanations here: About the timestamps, there are past explanations here: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que....
Having trouble finding plugins … mousepad?
Writing a mousepad plugin is actually a bit of a pain.
> Note that you'll need all the Mousepad code to build your plugin, as the headers are not installed. We've never gone so far as to actually expose an API for writing plugins, choosing which headers should be installed and documenting this properly.
Which mostly means that you're on your own.
Whilst building one for Ethersync _should_ be fairly easy (exec and ionotify should get 90% there), without documentation - how do you ensure the text buffer gets updated correctly...? I'm not surprised no one has put this together yet.