Another one for the list:
https://github.com/ipfs-shipyard/peer-pad
Demo here:
(this version will launch soon as soon as we complete the “pinning” / backup link to ipfs-cluster and make some UI tweaks)
Built with:
Open source collaborative text editors
121–130 of 167 posts
Re: Open source collaborative text editors
#122Earlier quoted context omitted.
Are you working only with editors running inside web browsers or also native ones? What I would like to have is something that bridges two native editors, let's say emacs and VS Code, and let's a team share the editor (whatever each developer's preferred editor is) and not only the screen on Slack or similar. That would be great for remote pair programming. I guess there would be a protocol for selecting the buffer/t…
> What I would like to have is something that bridges two native editors The big failing of co-editors is that currently they all silo into a single editor. THat's OK for e.g co-editing stuff on a web platform (e.g Google Docs) but it totally sucks for collaborating on code/documents you edit locally, forcing everyone to use the same editor/IDE, which ultimately fails because no one will use the same editor/IDE acros…
For plain text, this is not so hard. The data model for plain text (e.g. a string) and the set of mutations on that model are pretty small. Also describing where a cursor is and what is selected is likewise fairly straight forward. Co-editing between plain text editors is completely doable, IMHO.
It's much harder for rich text editors (RTEs) because the various RTE's vary widely in the exact subset of rich text features they support. One will support tables, and another will not. One will support video and another will not. One will use a linear position to describe where the cursor is, and another will use a DOM Range. This makes it very hard to support co-editing between different rich text editors. It's not impossible, just hard enough where most of us are not tackling it.
Re: Open source collaborative text editors
#123Indeed, the space is growing quickly. I run a company that provides a backend for real-time collaboration, so we necessarily stay on top of what's out there. There's a reason the server-side tech tends be paid: it is extraordinarily difficult to provide guaranteed eventual consistency of data at low latency. The CKEditor guys (and us, for that matter) have put YEARS of development effort into their solutions. We're w…
I appreciate that you mentioned a competitor without shamelessly plugging your own product, but out of curiosity, and if you don't mind sharing, what editor do you work on?
I assume you found us already, but more info can be found at https://convergence.io. There are some examples that demonstrate a few of the editors as https://examples.convergence.io/
Re: Open source collaborative text editors
#124A few other CRDT / collaborative text editor links I've collected:
* https://blog.datproject.org/2019/03/05/caracara-react-dat-au...
* https://conclave-team.github.io/conclave-site/
* https://github.com/noffle/hyperpad
* https://xi-editor.io/xi-editor/docs/crdt.html
* https://github.com/atom/teletype-crdt
Re: Open source collaborative text editors
#125Awesome! Thanks for sharing :D
Re: Open source collaborative text editors
#126Some colleagues at work started to use https://hackmd.io/ for collaborative editing of markdown text. It works great.
Re: Open source collaborative text editors
#127Until last year and for two years I kept an Etherpad Lite to do shared text editing and it was amazing. It was in use for three years. The only reason I stopped using it was Google Docs, who bought the company or IP for Etherpad, can do the same thing and therefore I don't have to do the Linux maintenance. I even had it use SQlite as the database and it could handle as many as 30 simultaneous users without a hitch.
Etherpad has been open source since 2009, when it was bought by Google and immediately re-licensed. It stayed open source ever since. It was written in a mix of Scala & JS.
Etherpad Lite (https://github.com/ether/etherpad-lite) is a port to javascript, is backed by the Free Software Conservancy and is not owned by any corporation.
Yes, if you do not mind using Google's infrastructure, Google Docs is easier & more featureul. There are some cases in which running on premises may make a difference, and Etherpad strives to fill that palce.
Re: Open source collaborative text editors
#128This article from the NYT tech blog is a really good read on how they created a custom text editor for the newsroom: https://open.nytimes.com/building-a-text-editor-for-a-digita...
They built their custom app with the open source ProseMirror (http://prosemirror.net/) toolkit.
Re: Open source collaborative text editors
#129I found this recent paper highly enlightening: “Real Differences between OT and CRDT for Co-Editors” – Chengzheng Sun, David Sun, Agustina, Weiwei Cai, October 2018. Arxiv meta: https://arxiv.org/abs/1810.02137 PDF: https://arxiv.org/pdf/1810.02137.pdf It’s well written imo. The conclusions chapter is very good. “In this work, we have critically reviewed and evaluated representative OT and CRDT solutions, with respec…
BTW. there's also a more fresh paper from the same authors: https://arxiv.org/abs/1905.01302 I don't know how much they differ, though.
Thanks!!
Re: Open source collaborative text editors
#130Earlier quoted context omitted.
This is where differential synchronization shines (basically git). While OT/CRDT are really good for syncing small edits, they suck at being eventually consistent (with intentions preserved) on very large edits. We make a powerful collaborative word processor for the browser (Zoho Writer https://writer.zoho.com ) with complete offline support. This is one problem we'd like to solve in the long term. One way to solve…
> One way to solve this is to fallback to differential sync when syncing huge offline edits This is another question -- does automatic syncing make sense for huge differences in users' contents? The answer might be no. OTOH, isn't this a rare scenario? How perfect it has to be?How much of a compromise can the users accept? These are interesting questions which shows that creating this kind of software isn't easy -- b…
First of all when discussing about offline edits we should make effort to draw attention that "offline" could mean different thing to different people.
Offline editor from the point of view of the app's software developer might mean that editor can sometimes survive few minutes of lost connectivity, after which it will reconnect and possibly sync the team work.
Offline from the perspective of a team of scientists writing a joint paper means that some of them will take their work truly offline, to a secluded mountain hut, for an extended period (week or month) and will come back with a complete rewrite of the text to the point of being unrecognizable to the other authors. And then the coauthors will disagree with most of it, and will want to revert some of the pieces and keep some other pieces.
And scientists are not the only people needing joint collaborative environment. And not just for short papers. Few years ago, I was working in a larger team with a group of people doing revisions of a book, and there were so many revisions and revisions of revisions of revisions, and zillions of comments, that we had to split the book not in chapters, since Word got stuck even with 20-page chapters. We had to split the chapters in sub-chapters, of 5-10 pages in separate files, so that the processor would not get stuck with the myriad of comments and revisions.
These are all separate scenarios in collaborative writing, and there could be many other scenarios, so any solution should first explain for what type of scenario is it really targeting. Automated sync of collaborative work is not always the best thing to do.