Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open source collaborative text editors

juretriglav.si

Post reply on HN
Print view View original

61–70 of 167 posts

Re: Open source collaborative text editors

#61

Post by Fnoord »

arendtio wrote: post #60
Fnoord wrote: post #55

tmux + vim (akin to Windows Remote Assistance) can be good enough in some situations.

Not really. I use tmux + vim on a daily basis, but it starts with having just one cursor. Goes on with not being web-based and in the end, it has no offline collaboration support (that requires some kind of merge strategy). So yes, there are some use-cases when it is sufficient for collaboration, but most certainly not for the use-cases described in the blog post.

My use-case isn't similar to the ones described in the blog post.

You could easily make tmux + vim web-based if you desire (I don't see why, I'd just use Mosh or SSH instead). For merging you could abstract the content to a Git repository. For multiple cursors you could try Wemux [1].

[1] https://github.com/zolrath/wemux

Re: Open source collaborative text editors

#62

Post by arendtio »

What many people not fully grasp, at first sight, is that offline support for a collaborative editor is at least an order of magnitude more complex than just building a collaborative editor. In online collaborative environments, solving conflicts is relatively simple, as the changes are supposed to be small. But when two (or more) people are working on the same document without synching it for hours or days, the merge strategy has to be extremely good to come up with anything remotely intended (assuming the authors had a common intention).

So just because your favorite editor can be used offline and it has an (online) collaboration feature, does not mean it is capable of being an offline-capable collaborative editor.

Re: Open source collaborative text editors

#63

Post by AnthonBerg »

I 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 respect to correctness, time and space complexity, simplicity, applicability in real world co- editors, and suitability in peer-to-peer co-editing. The evidences and evaluation results from this work disprove superiority claims made by CRDT over OT on all accounts.”

And it is also argued that OT is a more direct approach to the fundamental issues of realtime multiuser editing, and that that directness brings effectiveness.

HN discussion: https://news.ycombinator.com/item?id=18191867

Re: Open source collaborative text editors

#64

Post by houshuang »

alalonde wrote: post #13

Indeed, 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…

Thanks for the component you provided for shared cursors in text areas (https://github.com/convergencelabs/html-text-collab-ext). I've been using it with ShareDB, and have been working on adapting it to work with single text inputs, which has been surprisingly difficult (mainly dealing with scroll/overflow behaviour).

Re: Open source collaborative text editors

#66

Post by arianvanp »

idleherb0 wrote: post #56

I’m new to the topic from a technical point of view. I was wondering if the conflict resolving issues are fundamentally different from online gaming scenarios. I.e., could the ways problems are solved in multiplayer games also be applied to collaborative editors and vice versa?

The quake3 netcode is eventually consistent and always reminded me of CRDTs. https://fabiensanglard.net/quake3/network.php

Re: Open source collaborative text editors

#67

Post by jlokier »

idleherb0 wrote: post #56

I’m new to the topic from a technical point of view. I was wondering if the conflict resolving issues are fundamentally different from online gaming scenarios. I.e., could the ways problems are solved in multiplayer games also be applied to collaborative editors and vice versa?

That's a great question.

One of the differences is real-time games do motion prediction, to hide latency. I haven't heard of editors doing so.

Re: Open source collaborative text editors

#68

Post by houshuang »

im_down_w_otp wrote: post #6

I would be very appreciative if Google made a stripped down version of Google Docs for plaintext editing. There are a bunch of basic integration features that would also be fantastic, but if the product was literally just Google Docs, minus the WYSIWYG bits, and all plaintext w/ maybe some syntax highlighting thrown in, I'd be super happy.

That's basically what I'm trying to build - we're starting with Quill.js and ShareDB, adding extensions, configuring, and then adding a plugin system based on React, which can take arbitrary components all based on ShareDB sync (think spreadsheets, forms, but I'd also love to integrate the Pyiodide stuff to have runnable Python code inside a rich text document, etc). We built this as part of a synchronous collaborative learning platform, but I'm currently trying to extract the key components so that it can be a stand-alone open source library that others can help build on. Very early prototype: https://www.npmjs.com/package/@chilifrog/reactive-rich-text

Re: Open source collaborative text editors

#69

Post by houshuang »

mochidusk wrote: post #22

I was able to get real-time collaborative text editing to work on one of my side projects by combining quill.js[1], ot.js[2], and firebase[3]. This was a few years ago when there weren't any fully open-source options. I'm in the process of switching out firebase for an elixir/phoenix backend[4]. I'm really glad for this article because it captures the exact feelings that I have. [1] https://quilljs.com/ [2] https://g…

tmbb has been doing work on writing a ShareDB compatible backend in Elixir (https://elixirforum.com/t/realtime-collaboration/9736/5), this has long been a dream of mine. If not, having a separate Node server that just deals with ShareDB documents would also be feasible - all the app logic could still be in Elixir. Happy to share stuff we've been doing with Quill, for example my company recently sponsored work on shared cursors/presence for Quill.

Re: Open source collaborative text editors

#70

Post by houshuang »

alalonde wrote: post #25
blotter_paper wrote: post #20

Earlier quoted context omitted.

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?

You can currently already do good-enough-for-most DOM-level synchronization using any editor, of which we have a few examples. A lot of the examples of RTC out there (apps using TogetherJS for instance) are doing this already. For rich text, we'd like to be able to provide 100% support for a particular editor's capabilities, which necessitates a deeper, custom data model. One of our value propositions is a unified ba…

I am curious about this argument - I think CKEditor 5 made a similar one in this epic blog post about how they implemented real-time collaboration (https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri...). We're using Quill.js with ShareDB, which supports JSON structures (which is great, because for us we often have documents with several rich text fields, and other complex structures). So far we've been able to do anything we wanted with Quill, and I've never felt limited by the data structures we have available... (We also do all kinds of other stuff with ShareDB JSON).

I guess one reason you could need custom types would be to ensure consistency - if two keys depend on each other, and one user sets one key, and the other user sets another key, and the document is now invalid, you'd need the engine to be able to reconcile at a higher level?

Post reply on HN