Tutorial: Building a collaborative text editor over IPFS with Yjs in 10 minutes | Hacker News Reader

Tutorial: Building a collaborative text editor over IPFS with Yjs in 10 minutes

youtube.com

62 pointsKirinDave14 comments

Oops, the URL in the video is outdated, the repo now lives at https://github.com/ipfs-shipyard/shared-editing-demo

This is also the tech that PeerPad is built on: https://peerpad.net && https://news.ycombinator.com/item?id=15624158

Just an aside: Someone could make this a neovim, emacs/spacemacs, or sublime plugin in a heartbeat. It's easy to encrypt the traffic (although key-sharing is harder).

Collaborative editing is "solved" enough now that it's essentially a library to include, not an open engineering task.

It is my hope that one day, we'll use IPFS and other similar tools to enable our apps to work effectively in mixed-connectivity environments.

Imagine a future version of IPFS that can recognize partitions and form sub-networks within an isolated network. Then, there's no difference between offline, isolated network, and public mode except for connectivity, and the way to import data is to have your inner nodes pin it!

I really like this idea. Would improve the user-visible quality of wireless mesh networks where latency can be high.

I think the challenge to it is that DHT structures right now are not themselves commutative. We need a CRDT foundation for DHTs, themselves!

And one that has an asymptotic algorithmic complexity bounded near O(N^2) or less to handle the massive workloads these things can see.

Where's the code for implementing support for textarea, ace, codemirror etc ?

Why did the browsers drop connection to each other when he turned off wifi? Shouldn't they still be able to see each other? Do they need to talk to a 3rd party?

If it is decentralized, then why do I need node-js? Why do I need a webserver?

Actually, you absolutely could host the website inside IPFS and if you don't mind going to an incomprehensible ipfs.io/ipfs/___ address, it'll fetch.

The webserver is there in this case to make life easier during dev, and to make it easy to call your local ipfs API service to do things like monitor the messages on the pubsub.

PeerPad, which evolved from the data structure in this tutorial, can totally fine be run from any location:

- https://peerpad.net

- https://ipfs.io/ipns/peerpad.net

- https://ipfs.io/ipfs/QmXhnaUzhiZ6EGvr2SwPgSZzVhfsTnzTW5EsXH6...

- http://localhost:8080/ipfs/QmXhnaUzhiZ6EGvr2SwPgSZzVhfsTnzTW...

And with the ipfs-companion browser extension:

- dweb:/ipns/peerpad.net

- dweb:/ipfs/QmXhnaUzhiZ6EGvr2SwPgSZzVhfsTnzTW5EsXH6TNnQcYD

- ipns://peerpad.net

- ipfs://QmXhnaUzhiZ6EGvr2SwPgSZzVhfsTnzTW5EsXH6TNnQcYD

Or by grabbing it using `ipfs get /ipns/peerpad.net` and clicking the html file in the resulting directory.

Because the datastructure being manipulated is the "decentralized" feature here.

And to manipulate a datastructure you need software.

I am intrigued by your comment and your expectation about"decentralized", though.

And now I am curious: What were you expecting ?

I was expecting a standalone html file that could be run by clicking on it, or, due to that "same origin" b_llsh*t [1], at least served using any generic http server, not one which has to be specially configured and installed.

[1] I know the security reasons behind this, I just find the hassle to be a counter-logical irksome, and insecure in most cases, hack.

I suspect you didn't read my reply, because if you did you'd recognize that [1] is simply not true.

The only considerations here are simplifying the programming model. AFAICT, nothing in this demo needs a dedicated node server, it just simplifies the explanation.

Odds are though that if you're going to need your own personal centralization of some sort if there is any concept of user privilege in your system.

Reply on news.ycombinator.com