New top story on Hacker News: Show HN: Muse 2.0 with local-first sync
Show HN: Muse 2.0 with local-first sync
16 by adamwiggins | 79 comments on Hacker News.
Hey HN, I want to share with you something I and my four colleagues have been working on for the last several years. It’s a whiteboarding and notes tool called Muse[1]. We just released a 2.0 version which includes local-first sync. A little backstory: I’m one of the authors of the 2019 essay Local-first software[2]. (Past HN discussions[3][4].) The thesis is to reclaim some of the ownership over our data that we’ve lost in the transition from filesystems to cloud/SaaS. So I’m excited to bring CRDT technology “out of the lab” and into a commercial product as a chance to prove the value of local-first in real-world usage. As a developer and computing enthusiast, I care about abstract ideas like data ownership. But for most users I think the benefits of local-first will surface in how it feels to use the software day-to-day. One example is ability to work offline or in unstable network conditions: any changes between devices will be automatically merged when you reconnect to the network, no matter how long you’ve been disconnected. Another area is performance. The sync backend was written by my colleague Mark McGranaghan who has written extensively about software performance[5][6] and why we think the cloud will never be fast enough to make truly responsive software. A few technical details: – Client-side CRDT written in Swift, streaming sync server written in Go – Sync server is generic, doesn’t have any knowledge of the Muse app domain (cards, boards, ink, etc). Just shuffles data between devices – Transactional, blob, and ephemeral data are all managed by this one single state system. For example ephemeral data (someone wiggling a card around) for example, isn’t even transmitted if there are no other clients listening in realtime. More in this Metamuse podcast episode.[7] We draw heavily on research from people like Martin Kleppmann, Peter van Hardenberg[8], and many others. A huge thank you to this wonderful research community. Even if you have no interest in the Muse concept of a digital thinking workspace, I’d encourage you to try the free version just to see how local-first sync feels in practice. My opinion is that is fundamentally different from web/cloud software is well as from classic file-based software—and an improvement on both. Would love to hear what you think. [1]: https://museapp.com/ [2]: https://ift.tt/ZcLIsHu [3]: https://ift.tt/M2k1qDe [4]: https://ift.tt/EeUFbKk [5]: https://ift.tt/IvApoku [6]: https://ift.tt/0bQfM7y [7]: https://ift.tt/H6RLivy [8]: https://ift.tt/ypYibCr
16 by adamwiggins | 79 comments on Hacker News.
Hey HN, I want to share with you something I and my four colleagues have been working on for the last several years. It’s a whiteboarding and notes tool called Muse[1]. We just released a 2.0 version which includes local-first sync. A little backstory: I’m one of the authors of the 2019 essay Local-first software[2]. (Past HN discussions[3][4].) The thesis is to reclaim some of the ownership over our data that we’ve lost in the transition from filesystems to cloud/SaaS. So I’m excited to bring CRDT technology “out of the lab” and into a commercial product as a chance to prove the value of local-first in real-world usage. As a developer and computing enthusiast, I care about abstract ideas like data ownership. But for most users I think the benefits of local-first will surface in how it feels to use the software day-to-day. One example is ability to work offline or in unstable network conditions: any changes between devices will be automatically merged when you reconnect to the network, no matter how long you’ve been disconnected. Another area is performance. The sync backend was written by my colleague Mark McGranaghan who has written extensively about software performance[5][6] and why we think the cloud will never be fast enough to make truly responsive software. A few technical details: – Client-side CRDT written in Swift, streaming sync server written in Go – Sync server is generic, doesn’t have any knowledge of the Muse app domain (cards, boards, ink, etc). Just shuffles data between devices – Transactional, blob, and ephemeral data are all managed by this one single state system. For example ephemeral data (someone wiggling a card around) for example, isn’t even transmitted if there are no other clients listening in realtime. More in this Metamuse podcast episode.[7] We draw heavily on research from people like Martin Kleppmann, Peter van Hardenberg[8], and many others. A huge thank you to this wonderful research community. Even if you have no interest in the Muse concept of a digital thinking workspace, I’d encourage you to try the free version just to see how local-first sync feels in practice. My opinion is that is fundamentally different from web/cloud software is well as from classic file-based software—and an improvement on both. Would love to hear what you think. [1]: https://museapp.com/ [2]: https://ift.tt/ZcLIsHu [3]: https://ift.tt/M2k1qDe [4]: https://ift.tt/EeUFbKk [5]: https://ift.tt/IvApoku [6]: https://ift.tt/0bQfM7y [7]: https://ift.tt/H6RLivy [8]: https://ift.tt/ypYibCr
Comments
Post a Comment