My co-founder (Guillaume Salles) and I started making an online collaborative video presentation software. But instead of focusing on the core mechanics of the tool, we realized pretty quickly that we were spending a majority of our time figuring out how to handle real‑time collaboration.
A lot of questions had to be answered. What should happen when there are many people concurrently editing the same piece of data? Should all data even be handled the same way? What about people on slow connections? The list goes on.
We tried existing solutions, but none really stacked up for what we were trying to do. That’s when we decided to build our own. Liveblocks was born :)
We'll be around all day to answer any questions you have about Liveblocks — ask us anything!
Hi, thanks for posting! :) It reminds me of https://togetherjs.com/ which I guess you looked at? What were the shortfalls/differences that you found you had to address? Is your product React-only?
Liveblocks does not come with a specific UI. We're providing APIs to create rooms and share states between users. The state can be volatile (like cursors, focused input, selection) or persisted even when the session is over, like a figma file or a google document (this part is still in private beta). We're using custom CRDTs for the persisted state.
We only have a javascript client and react client, but we plan to support more technologies in the future. Even native clients for desktop or mobile if there is an interest.
Like Yjs, our Storage block is CRDTs based, but we're making different trade-offs. For example, our CRDTs are not "pure" so we solve some conflicts on the server. Also, we don't support Text CRDTs yet.
But Liveblocks is not just about conflicts resolution!
Our vision is to shape our API and guides to help companies transform existing products into collaborative ones. For example, by simply adding live cursors and avatars and refreshing the data with existing REST endpoints, an existing app becomes more collaborative even if the conflict resolution is not perfect. At the same time, we provide analytics on how Liveblocks is used to help product teams prioritize their collaborative features and if they still want to integrate Liveblocks further.
We're also hosting the WebSocket infrastructure and make it scale because we know how troublesome it can be to maintain.
I watched the 1 min intro video, but still have no idea what it actually does. Why I should add this to my website. A simple demo video instead of all the marketing might work better?
Our goal is to help companies create collaborative products like Figma or Google Docs with API and guides. Multiplayer infrastructure and conflicts resolutions can be challenging to build in-house and we think it will become a commodity (like logging or analytics systems).
If our marketing video didn't convince you, maybe our examples page and documentation will give you more information.
Congratulations to the founders for the launch, but unfortunately I had the same response.
In situations like these - intrigued but with no real understanding of what the product is - I want the video to show me a real-world example in about ten seconds flat. A more glitzy promo video has its place, but not in a post to Hacker News.
From what I understand from Replicache, it focuses only on conflicts resolution with CRDTs, and it does not come with a web socket infrastructure nor a hosted backend. You need to have your own servers or use external services to have live cursors. (https://doc.replicache.dev/guide/poke)
At Liveblocks, we want to bundle all that together because we believe that being tightly integrated is necessary to provide a great experience.
For example, if you implement an "undo"/"redo" feature on a collaborative design tool (like Figma), the selection of a user (volatile state) should be in sync with the document state (persisted state).
Some people might prefer managing their own backend infrastructure, but we want to provide it because we know how difficult it might be to scale and load balance web sockets rooms. We want to help companies focus on their core product and not spend too much time working on the multiplayer infrastructure and algorithms.
Congrats on launch! Super cool product and I feel like trying it out in the SaaS i'm building. Few initial questions:
`Our multiplayer WebSocket servers live on the edge` -> from your Jobs page I realised that you use AWS. Does that mean that it's AWS cloud that you're using? Have you considered using Cloudflare Durable Objects(DO) for infrastructure - what are the thoughts for DO suitability for your use case (besides it currently being in beta phase)?
Congrats once again on shipping something world needed badly!
Upd: removed the question which was a bit illogical :)
> Does that mean that it's AWS cloud that you're using? Have you considered using Cloudflare Durable Objects(DO) for infrastructure
Would love to hear an answer to this, I've read a bit about Durable Objects but not got a chance to play with them yet. I'd be really interested to hear if they evaluated fly.io as well. It seems like a great fit for their model of running full blown app servers in many regions.
Nice catch! All the examples that you see on our website are using Cloudflare Durable Objects! But because they are limited, we also have
a version of our server that works on AWS some of our customers.
I work in the "realtime" space too (founder of Fanout, low level push infra).
Liveblocks looks like it's somewhere between Firebase and Sendbird, providing live updates and state management, but for specific use-cases and stopping short of the UI. I haven't seen too many products operating at that level of abstraction, so maybe you're on to something. I also like how you solve for more use-cases than chat, the dominant "block" in the market.
There are a lot of live sharing/working/... coming out these days.
FYI: Your cursor examples uses x/y explicit coordinates where as people using different screen sizes and resolutions wouldn't see proper mouse cursor location. Rather it should be x/y relative coordinates.
example x: 35%, y:12% (top left corner to bottom right corner)
From our experience, live cursors positioning depends on the use case and the content behind them.
For a "canvas app" (like Figma), the positioning will be absolute with an offset depending on the panning.
For a responsive website, if it makes sense to add live cursors, it depends on how the content "flows". For example, if your content scrolls vertically and is centered horizontally, you can use percentage on the "x" axis and absolute on the "y" axis. That's what we're doing it in this example: https://liveblocks.io/examples/live-cursors-scrollable-page
Sometimes, cursors are not the best way to show what users are doing on a web page. For a form, displaying an indicator close to the focused input is more valuable.
Because there is no perfect solution, we're not shipping any UI with Liveblocks and only provide guides. In the future, if a common abstraction appears, we will create some package to make the integration easier.
I use YJS webrtc with Svelte for my p2p collaborative IDE and it’s awesome. Do you guys do any p2p stuff like that? Also, maybe reach out to Spline founder, he just launched the web version of his “Figma but 3D” app that wraps ThreeJS in a GUI tool and has been gaining traction fast.
My co-founder (Guillaume Salles) and I started making an online collaborative video presentation software. But instead of focusing on the core mechanics of the tool, we realized pretty quickly that we were spending a majority of our time figuring out how to handle real‑time collaboration.
A lot of questions had to be answered. What should happen when there are many people concurrently editing the same piece of data? Should all data even be handled the same way? What about people on slow connections? The list goes on.
We tried existing solutions, but none really stacked up for what we were trying to do. That’s when we decided to build our own. Liveblocks was born :)
We'll be around all day to answer any questions you have about Liveblocks — ask us anything!
Thanks, Steven