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

111–120 of 167 posts

Re: Open source collaborative text editors

#111

Post by jkaptur »

jlokier wrote: post #67
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.

Arguably not an “editor”, but I think the mosh shell input does something like this.

Re: Open source collaborative text editors

#112

Post by js4ever »

nailer wrote: post #92

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.

You are talking about LiveShare plugin for VSCode

Re: Open source collaborative text editors

#113

Post by nailer »

js4ever wrote: post #112
nailer wrote: post #92

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.

You are talking about LiveShare plugin for VSCode

That's it - thanks!

Re: Open source collaborative text editors

#114

Post by OJFord »

petercooper wrote: post #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.

It's in the headline image.

Re: Open source collaborative text editors

#115

Post by lilmoelil »

lloeki wrote: post #91
pmontra wrote: post #34

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

I think 'Google Wave Operational Transformation' was an attempt at this. I believe there is some merit in this; though my doubts come from the failure of Google Wave.

Re: Open source collaborative text editors

#116

Post by AnthonBerg »

scofalik wrote: post #99
AnthonBerg wrote: post #89

Earlier quoted context omitted.

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?

I found the arguments convincing, and will be moving towards OT in general. From outside it feels like OT is generally closer to how I tend to think.

Re: Open source collaborative text editors

#117

Post by mmacfadden »

houshuang wrote: post #64
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).

Our pleasure! If you want to share what you are doing we might be able to incorporate it into the utility for you! Happy to support a pull request, or to work collaboratively on it.

Re: Open source collaborative text editors

#118

Post by mmacfadden »

tjungblut wrote: post #48
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…

Do you guys rely on a central authority approach like Prosemirror does? I'm desperately looking for something that's somewhat stateless or at least replicable (even better if shardable) on a document basis.

We do have a server in the architecture, and there is a small amount of state maintained by the server, per document as it is being edited. However the system is clusterable and documents shard across the cluster.

Re: Open source collaborative text editors

#119

Post by baddox »

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…

I work with a tool that provides diffing and merging for rich text (effectively a limited subset of HTML). It doesn’t have or need real-time collaborative functionality at all. I have read all the papers that I can find and understand, but I’m still not happy with our merging algorithm for rich text.

The issue is less about which fancy algorithm/data structure to use and more about even defining in human terms what would be expected in certain merge conflicts. Currently, we err on the side of raising a merge conflict rather than deciding to use one version for a certain change, but in practice most conflicts have a pretty obvious resolution when a human looks at the two conflicting versions.

Re: Open source collaborative text editors

#120

Post by mmacfadden »

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…

I think the argument is more about the historical data structures that were used in rich text. A lot of editors either used the DOM, or a very flattened data structure like Google Wave, Quill.js, DraftJS etc. With these flattened data structures it becomes harder to represent complex rich text with things like tables, nested blocks, etc. If you have a nice JSON data structure that is collaborative you can do a lot, and in many / most use cases it is sufficient. However, you can run into use cases where the collaborative data structure will ensure consistency across clients, but violate some semantic constraint on the data.

For example, imagine you have an application that has a list that must contain at least one element. Assume there are two elements in the list. A Shared JSON data structure on its own (that allows for immediate local edits) would to allow two clients to simultaneously delete one element each. The end result is that the client app on both sides will become aware that the constraint was violated only when the remote operation comes in. Resolving this becomes difficult. What is the resolution strategy? Which of the two clients should initiate it? This is a contrived example for sure. But you run into things like this in various use cases, and occasionally you need either new data structures that encode these semantics, or you need an extendable system that allows you to customize constraints, and resolutions.

That said, you can get pretty far with just JSON!

Post reply on HN