Live data from Hacker News

Open source collaborative text editors

juretriglav.si

101–110 of 167 posts

Re: Open source collaborative text editors

#101

Earlier 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…

Well it's quite common for people using “normal” email-exchanged MS office revisions. I have no clue if there's specific tooling for these cases. Of course you could brush them off and say they wouldn't be a problem if they just used online editors.

Re: Open source collaborative text editors

#103

Another one missing: https://en.wikipedia.org/wiki/SubEthaEdit SubEthaEdit is a collaborative real-time editor designed for Mac OS X. The name comes from the Sub-Etha communication network in The Hitchhiker's Guide to the Galaxy series. From 2003.

Not sure why you got downvoted. SubEthaEdit was magical back when - here is the link to the github repo for the recently released source: https://github.com/subethaedit/SubEthaEdit

Re: Open source collaborative text editors

#104

Earlier quoted context omitted.

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 ab…

> (...) 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?

I am not sure if I understand you correctly here, but it's not really that. Could you give me a more concrete example?

The kind of problems for extra types are, for example: user A changes a paragraph to a list item and user B splits it. As a result you'd like to have two list items instead of a list item followed by a paragraph. This is impossible if you don't give more semantic meaning to the operations.

There are other problems though, as you mentioned - with invalid document. For example, you have this kind of a list:

* Foo

__* Bar

__* Baz

User A outdents "Bar" and user B indents "Baz" creating a list like this:

* Foo

* Bar

____* Baz

In CKE5 this is an incorrect list (we don't allow indent differences bigger than one). This cannot be fixed through OT so we fix it in post-fixers which are fired after all the changes are applied.

Re: Open source collaborative text editors

#105
A number of years back, I wrote an OT implementation in Clojure/ClojureScript as a hobby project [1] and learned a lot along the way. I even extracting out the core client/server implementations to their own package [2].

It's an incredibly fun topic, and one that's also really challenging. It also gave me first-hand experience with fuzz-testing where I could simulate all kinds of concurrent-edit conflicts and ensure both clients came out with the same end-result. While the end client/server implementations are working, it was a lot more effort than I anticipated building a full-fledged editor on top. I was too stubborn at the time to attempt to integrate with existing RTEs though, so the most notable part of the project was the core lib, not the end product.

For those interested in implementing it for themselves, I can't recommend this piece [3] by @djspiewak enough.

[1] https://github.com/jahfer/ot [2] https://github.com/jahfer/othello [3] http://www.codecommit.com/blog/java/understanding-and-applyi...

Re: Open source collaborative text editors

#106

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 merg…

Explains why we're never getting Confluence offline editing.

Re: Open source collaborative text editors

#107

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?

Good question, but it could be responded to by writing a thesis.

We frequently joke in our company that we'd love to write a thesis on OT and get a better academical grade ;).

Re: Open source collaborative text editors

#108
Until 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.

Re: Open source collaborative text editors

#109
Since it didn't make the list, nor has been mentioned in this thread, I want to recommend https://firepad.io/ - we use it quite heavily at our company. It's uses Firebase behind the scenes so is essentially 'serverless' and we use it for editing our e-mail newsletters live as a team. It literally takes minutes to throw into an app.

Re: Open source collaborative text editors

#110

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 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.

Post reply on HN