Hacker News new | threads | past | comments | ask | show | jobs | submit DanielBMarkham (43827) | logout
Show HN: Yboard is a multiplayer desktop-like workspace based on CRDT (github.com/felipeleivav)
162 points by selknam 1 day ago | flag | hide | past | favorite | 28 comments
I've always been curious about real-time multiplayer user interfaces.

When I found out about CRDTs and Yjs[1] I thought they could serve as a solid base for a project like that.

So I built this pretty simple desktop-like UI (heavily inspired by lifeat.io) and used Yjs to replicate the whole UI state among multiple peers, creating the experience of a unique interface.

Try online: https://yboard.lol

[1]: https://github.com/yjs/yjs






In case anyone else was wondering, like me, CRDT = conflict-free replicated data type: https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

Why is the talk around CRDTs all about collaborative editing, and less about the more mundane but much more common scenario of multi-master CRUD apps?

Completely agree. Where CRDTs really shine is when you have a larger deviation of changes over time. They are brilliant for offline first type apps, and in fact are what Apple Notes use.

Last year I experimented with combining Yjs with PouchDB/CouchDB to achieve automatic conflict handling with a multi master type architecture and eventual consistency. It worked brilliantly!

I think it’s because there is just generally so much hype around “real-time” collaborative apps at the moment. But the reality is people spend much more time working async and merging changes later. I suppose what’s particularly brilliant with CRDTs is that they handle both use cases very well, you don’t have to have two different systems.


>I suppose what’s particularly brilliant with CRDTs is that they handle both use cases very well, you don’t have to have two different systems.

.. and can equally be used to make CRUD if you wanna.


When CRUD is done with a shared spreadsheet (Google Docs, Office 365, etc.) it's a solved problem because a spreadsheet is a total information UI. C = insert row, R = just read the screen, U = type in and other people know where your pointer is, D = delete row.

The problem is when it's done with a database and people cannot see all the information at once. So they cannot see which records other people are working on and coordination is problematic.

A traditional CRUD web app in a shared desktop is a poor man solution that works with parallelism one.

Multimaster CRUD would be the same thing accessed by different people on different computers? 3270 terminals, Windows 95 client/server applications, traditional web and SPAs. I might be wrong but the problem is always who's working on what and how to solve that. Plenty of money thrown to that: management is there also to solve that problem. Talking with colleagues is another part of the solution.


Never heard of those before, what's a use case for multi-master CRUD apps?

Basically anything were you want to update data locally on different devices then sync. Or any multi-database system where you want all nodes to accept writes. In these scenarios there will be conflicts.

> Why is the talk around CRDTs all about collaborative editing, and less about the more mundane...

I'm unclear how much of this is just a function of the 'talk' that we hear. For cultural reasons building frontend web-apps has bigger communication share than e.g. embedded software. Something similar might apply.

Alternatively, CRUD apps are more the domain of enterprise SW which has not traditionally been where innovative software engineering has been done.


Good point. I think this is because it's interesting how CRDT being a solution for conflict merging it's inherently capable of allowing real time applications, even when it's not exactly about that.

Because CRUD is the opposite of collaborative editing, and people are sick of it - CRDT represents a solution to getting humans working together through computers that isn't based on decades of cruft (disclaimer: imho)

Could WebRTC be used instead of websockets? Then you wouldn’t need a server (apart from a public STUN/TURN endpoint)

Haven't tried with this specific project, but Yjs has a WebrtcProvider [0] which could be used where the project now uses WebsocketProvider [1].

Yjs is built to allow you to switch easily between providers so it shouldn't be too much trouble to make the change.

[0] https://github.com/yjs/y-webrtc [1] https://github.com/felipeleivav/yboard/blob/main/src/service...


This looks really fun, modern incarnation of Google Wave. Made a test room here: https://yboard.lol/lobby?join=hackernews

error joining room.

"Couldn't connect to the room server. Error joining room"

Show something cool on HN and get hugged to death :)


Exactly this.

Websocket server went down but already fixed that.

Thanks for testing.


Looks really cool, just a friendly reminder to specify a license (or no license)

Thanks, I've just added MIT licence :)

Very cool, though not sure why there's a Spotify button and whether you wanted to share your playlist with the whole world in the demo?

Kinda feels like the modern version of Zawinksi's law: http://www.catb.org/jargon/html/Z/Zawinskis-Law.html


since this is based on CRDTs, does that mean one of the collaborators can go offline, continue working, and re-synchronize with the rest of the collaborators when they come back online?

synchronizing after offline editing is the main reason to use CRDTs, but i don't see offline mentioned at all in the readme. (demo is currently hugged to death, so i can't test.)


This comment makes me realize we really need standard phrasings for where a CRDT stores its data, and what behaviors are allowed/expected by each common scheme.

neat use of SVG as a drawing canvas, would be cool if it supported touch too

Thanks!

Touch support is definitely something I want to add for the canvas and the window positioning/resizing too.


Hmm, something seems to have broken. Login does not work for me.

Same here.

Great stuff!

Thanks, glad you like it :)

inspiring



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: