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

91–100 of 167 posts

Re: Open source collaborative text editors

#91

Post by lloeki »

pmontra wrote: post #34
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…

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 across a whole company/team/project, so although useful I've never seen one take hold for anything but a very short amount of time in any company.

We desperately need (a couple of) well-defined protocols that get implemented across editors, and one to emerge as a widely supported winner, whatever its shortcomings.

Re: Open source collaborative text editors

#92

Post by nailer »

VSCode is collaborative and Open Source. You install a plugin and send someone a link - you are then hacking on their document, in your VScode on your keyboard with your plugins installed.

Sorry I can't remember what the plugin is called, I used it every day at my last contract though. Made pairing super easy.

Re: Open source collaborative text editors

#93

Post by tjungblut »

atomanek wrote: post #81

A CKEditor 5 team member here. Thanks a lot for such an in-depth analysis, the article is a great read and we truly appreciate being a contender there. As for the existing implementations of CKEditor 5 with real-time collaboration, I'm afraid since the collaborative editor is usually a component of a larger platform (publishing, e-learning, CMS, intranet, documentation management system etc.) it'd be difficult to fin…

> The platform is ready to fully support "offline" writing

how did you solve the merge when somebody comes online again but creates a conflict with his changes?

Re: Open source collaborative text editors

#94

Post by houshuang »

VvR-Ox wrote: post #85
houshuang wrote: post #59

Surprised the author didn't mention Quill.js, which works really well with ShareDB, and is fully open source. We've been doing a lot of fun stuff with it - here's a talk I gave recently as a job talk: https://www.youtube.com/watch?v=gN37rJRmISQ . (It worked, I got hired :)). As a side project, I'm working on a ShareDB backed wiki, where we can use rich text for editing pages, but also other components, like spreadshe…

I like what you've done. Is the FROG repo you linked the repo of the wiki? I'm just curious as it doesn't mention anything about it being a wiki in the readme (it's also a bit unclear how/what to use it for from the description).

Yeah, we need to do a lot around messaging, to be clear - the wiki is in an early prototype and there are known bugs, etc. However if you want to try it out, install the repo (run initial_setup, then npm start server), then go to localhost:3000/wiki/ANYTHING. It will create a new wiki named ANYTHING?login=YOURNAME, and there you are.

Or go to https://icchilisrv3.epfl.ch/wiki/hn/Home?login=YOURNAME to test it immediately. (I added a tiny bit of content).

Re: Open source collaborative text editors

#95

Post by scofalik »

tjungblut wrote: post #93
atomanek wrote: post #81

A CKEditor 5 team member here. Thanks a lot for such an in-depth analysis, the article is a great read and we truly appreciate being a contender there. As for the existing implementations of CKEditor 5 with real-time collaboration, I'm afraid since the collaborative editor is usually a component of a larger platform (publishing, e-learning, CMS, intranet, documentation management system etc.) it'd be difficult to fin…

> The platform is ready to fully support "offline" writing how did you solve the merge when somebody comes online again but creates a conflict with his changes?

I don't like "merge" word because it implies how the problem is solved. "Synchronise" would be better, as there is no merging, actually.

We use Operational Transformation, so all the changes are stored as operations (with their most important property being path - the position where the operation happened).

When a user comes online, they try to re-send all the operations that are buffered and not yet sent to the server. Then it is a matter of transforming these operations by the new operations that happened in the meantime (when the user was offline). Of course, the user also has to accept the new operations.

This is a bigger / more complex version of the basic problem of the real-time collaboration. During real-time collaboration with all users online you might need to transform your operation by maybe several other operations at most. When you go offline, it might be tens or hundreds of operations but the problem is basically the same, just bigger.

The quality of the transformation algorithms will make a huge role in how well the user intentions will be preserved.

"Platform is ready" means that the theory behind our solution is correct and that we checked some moderately complex scenarios.

Edit: still, the base scenario is that the users write "online" and "offline" kicks in when you lose a connection (for hours, even). If we are talking about "everyone writes offline and then they magically merge" then I think this might be a totally different feature (and maybe even outside of the editor and inside the CMS).

Re: Open source collaborative text editors

#96

Post by bachmeier »

lewisjoe wrote: post #83
arendtio wrote: post #62

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…

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…

> sync large offline edits, with the intentions preserved

How would that be possible if none of the users can see what the others are doing? If you have three users that start with version 1 and they all make their own version 2, even the users don't know what the "correct" version 2 should look like. Or to put it differently, I don't even know what is meant by "intentions" in this scenario.

Re: Open source collaborative text editors

#98

Post by scofalik »

houshuang wrote: post #70
alalonde wrote: post #25

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…

Author of the linked blog post here.

The example cases for additional types / custom implementation are in this section: https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri...

These content-preservation edge cases weren't possible to solve with what was available (at least at the time we started the project).

Even apart of that, ottypes/json0 was lacking some basic things, like moving objects. I see they came up with a new implementation recently (https://github.com/ottypes/json1) and it allows moving objects. Maybe the new implementation would solve some problems. However, it is in "preview" state, and the last update was 2 months ago, so I am not sure how well it will be maintained.

Also, there are some edge cases when transforming ranges (which CKE5 use to represent, for example, comments on text or content created in track changes mode). I don't want to bury you in difficult to understand examples but if you are interested you might want to check the examples listed in inline codes for this function: https://github.com/ckeditor/ckeditor5-engine/blob/master/src....

As far as Quill.js is concerned, it is based on the linear data model, which brings limitations when it comes to complex features. Transformation algorithms for linear data models are much simpler and there are more implementations and articles in this area. Everything depends on your needs. If Quill.js features set and functionality fit your needs then the solution you chose is correct.

With CKE5 however, we didn't want to go on any compromises. We needed complex structures for our features, and for having a powerful framework - to enable other developers to write whatever feature they want and have those features working in real-time collaboration. We wanted transformation algorithms which will handle all the edge cases. It is true, some of those cases are quite rare. And the old "10/90" mantra applies here, in this case "10% of use cases brings 90% of complexity". But those edge cases happen and we didn't want to disappoint our users.

Re: Open source collaborative text editors

#99

Post by scofalik »

AnthonBerg wrote: post #89
mkl wrote: post #82

Earlier quoted context omitted.

I'm not sure what to make of that, though, as there seem to be quite a few different JSON CRDT libraries, for example. Just after that it says "The contradictions between these realities and CRDT’s purported advantages have been the source of much debate and confusion in co-editing research and developer communities." That's kind of my question/confusion: people writing CRDTs really talk them up, and I can't tell wha…

I found that I could eventually power through the paper. I thought it was beyond me at first. Then I got angry and just shoved piece by piece into my head :) Not in linear fashion, and it didn’t happen quickly. Actully not that slow either once I got going. I found I was maybe rather more of a paper-reader than I assumed I was. Probably you too!!

So, what is your conclusion after reading it?
Post reply on HN