Show HN: Yboard is a multiplayer desktop-like workspace based on CRDT (github.com)

Thanks!

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

error joining room.

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...

Thanks, glad you like it :)

Same here.

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)

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.

> 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.

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

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.

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.

Exactly this.

Websocket server went down but already fixed that.

Thanks for testing.

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.

Thanks, I've just added MIT licence :)