Comparing Yjs and Automerge:
• Both projects provide easy access to manipulating the shared data. Automerge's design philosophy is that state is immutable. In Yjs, state is mutable and observable.
• Automerge has more demo apps where state is shared to build some kind of application. But in theory, you could implement shared text editing with Automerge.
• Yjs is more focused on shared editing (on text, rich text, and structured content). It has lots of demos for different editors (quill, ProseMirror, Ace, CodeMirror, Monaco, ..).
• I spent a lot of time to optimize Yjs to work on large documents. While Automerge works fine on small documents, it has serious performance problems as the document grows in size. https://github.com/dmonad/crdt-benchmarks
• Yes, Automerge has support for hypermerge/DAT. I am also looking into it, as it seems like a really cool idea. I'm currently exploring multifeed[https://github.com/kappa-db/multifeed) for that. On the other hand Yjs has support for IPFS.
Yjs & Electron:
No problem here in general. You'll need to polyfill WebSocket / WebRTC support in electron. There is
ws for WebSocket support and
node-webrtc for WebRTC.
There is nothing like that to my knowledge. But maybe you could have a look at GUN
@calibr I have no experience with document indexing. Thanks for sharing your experience.
@canadaduane Thanks for your appreciation :) I was referring to the frontend of the shared editing framework. Yjs exposes mutable types (e.g. Y.Array). Automerge exposes immutable json-like objects.
In Yjs, the operation log is not immutable. I.e. it may decrease in size when you delete content. I describe some optimizations I do in the v13 log, but let me know if you want to know more.
About P2P electron apps: DAT is a very ambitious project that wants to share many, large files in a distributed network. Compared to WebRTC, UDP connections are initialized much faster and are better suited for their use-case (e.g. walking through peers of the DHT). However, If you only want to share a single document, WebRTC will work just fine and are also supported in the browser.
userOnly: true(see https://github.com/y-js/yjs-demos/blob/master/quill/index.js).
username$ npm i y-websocket npm WARN email@example.com requires a peer of yjs@^11.0.0 || ^12.0.0 but none is installed. You must install peer dependencies yourself. npm WARN firstname.lastname@example.org No description npm WARN email@example.com No repository field. npm ERR! path /Users/username/Desktop/Projects/YJS/react-yjs-test/node_modules/y-websocket/bin/server.js npm ERR! code ENOENT npm ERR! errno -2 npm ERR! syscall chmod npm ERR! enoent ENOENT: no such file or directory, chmod '/Users/username/Desktop/Projects/YJS/react-yjs-test/node_modules/y-websocket/bin/server.js' npm ERR! enoent This is related to npm not being able to find a file. npm ERR! enoent
Abstract Braid is a proposal for a new version of HTTP that transforms it from a state *transfer* protocol into a state *synchronization* protocol. Braid puts the power of Operational Transform and CRDTs onto the web, improving network performance and robustness, and enabling peer-to-peer web applications. At the same time, Braid creates an open standard for the dynamic internal state of websites. Programmers can access state uniformly, whether local or on another website. This creates a separation of UI from State, and allows any user to edit or choose their own UI for any website's state.
@rafeautie If you get issues like this I propose that you have a look at the versions I use in the demos. https://github.com/y-js/yjs-demos Documentation PRs are very welcome.
@kevmegforest_gitlab Yes, the encodeStateAsUpdate is final. Everything in the v13 docs can be seen as final unless there is a good reason to change it before the stable release.
@jylopez The awareness instance gives you the number of clients. Users can even propagate state (like user name, email, user-color, etc). The awareneness feature is supported by y-websocket and will be ported to the other connectors as well (v13 only). Documentation https://github.com/y-js/y-protocols
@canadaduane I think they are proposing a different algorithm. IMO this should be not part of the HTTP specification, rather it should be implemented over websockets.
Many of the other questions have been asked in the GitHub issue tracker already.