DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
100% Positive
Analyzed from 602 words in the discussion.
Trending Topics
#big#sail#small#muddy#browser#multiplayer#user#inside#canvas#users

Discussion (8 Comments)Read Original on HackerNews
The product was social-event focused (classes, festivals, etc.) so we focused on multiplayer audio-video experiences rather than general purpose browsing.
One of my favorite memories was when someone used our collaborative YouTube playback to set up a karaoke room. WebRTC added a little latency, but it was close enough to work.
and now it feels like a bunch of people are building canvas based products again, but for testing different image gen outputs on a canvas, except now you can vibe code them too!
I ask because I feel like Linear, Vercel, Figma, Notion, hell even Airtable... landed 'big' (felt like a big step change) with users when they arrived for most (I was a super super early user of Notion because my friend angel invested).
I used Sail and Muddy back when and... the small vs big distinction feels like my perception of the divergence between those things that get washed out by this effect and those that don't.
(also DM-ed you!)
We had some theories for how it could land big, but none strongly resonated. It wasn’t just “put websites in another app.” We were hoping multiplayer would do something similar to what Notion and Airtable did. In my mind, those products “land big” because they feel like docs and sheets on steroids. Blocks, databases, formulas, all inside surfaces people spend so much time in, so the step change feels obvious.
With Sail/Muddy, the bet was that multiplayer browser surfaces would land big and help with collaboration, alignment, handoff, etc. Someone sends you the exact things to click on inside a message, you pin them to come back to later, no more switching tabs, you can see what other people are doing. Some users did see Sail as a tool for big research projects, accumulating tabs and sources spatially, though mostly single player.
In both products, we were also rendering browser tabs and web content inside their own processes. Sail on an infinite canvas, Muddy inside a shared chat workspace. Architecturally, there’s a big difference between “this is an iframe in a web app” and “this is a real browser tab with full capabilities.” But that distinction doesn’t land unless people feel a step change in what they can do. To most users, it just read as embeds. They weren’t thinking about iframe limitations, process isolation, site compatibility, browser architecture, or the experience that enabled. And they shouldn’t have had to.
So yeah, not small in ambition or product theory, but small in perceived divergence. The system was ambitious, but the delta users felt was often more like “a nicer way to look at web stuff inside another interface,” not “this changes how I work with people or how I use my computer”.
I mostly just hope it’s interesting to people thinking about new ambitious interfaces right now. with AI.
I’m building a way for people to build on top of the browser (https://www.hyper-frame.art). One take away for me from your article was GTM is a bigger moat than technicals (which are brutal in the fork route you went)