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.
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'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)
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.
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.
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.
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
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 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.)
[1] https://automerge.org/
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...
I hope there are plans to support more OS.
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....
> 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.