Evernote is a good example of software that I think had a lot of promise but has decayed in quality and performance over time.
No self-hosted sync service at the moment. At the moment we've got our hands full with making it work well in a production setting. But I'd like to see a world where generic sync services (either as hosted services or self-hosted) is commonplace.
I think decay is an excellent word to describe Evernote’s journey, or at least the bits where I was involved. The UIs became progressively less usable, and somehow felt more fragile. My own use of it was experiment-> embrace -> decay. I can’t just blame the tool, that pattern of changing productivity tools is more of a me problem it turns out.
I’ve done a lot of thinking about an ideal tool for capturing and organizing thought and Muse appears to have addressed my own ambitions and those of experts in the field. Congrats on the great work. With this release I won’t need to get an iPad to try it, but after reading this post I sure want one.
To that end, I’m curious about user stories from desktop-first, and/or desktop-only Muse users.
Yes, we're curious to see how pure desktop usage evolves. A big part of the whole "thinking workspace" concept is the more relaxed posture of tablet use, the ability to scribble on things, etc.
That said, I've used Muse for Mac heavily for the past six months and find it's strongest when I am doing more text-oriented work. I'll also be curious to see how people use in practice and whether the value prop is really all your devices used in tandem (desktop, tablet, phone) or whether there are strong uses cases for just one at a time.
I've recently read the local-first article and thought this could a good solution for many apps to avoid database servers. This in turn would enable more business models using licenses (e.g. Sublime Text) instead of subscriptions.
I also believe that in the future we'll have these generic sync services you're talking about, just like today we have file syncing services. I actually believe we could start having them today and get most of the benefits of having a local-first sync service. I think we could have a relational database server (something which most devs are used to) running somewhere, paid/hosted directly by a user/company, together with a protocol implemented by a local daemon that allows apps to find that database server. This local daemon could be provided by a service (e.g. Apple Business, Syncthing) that provides group membership, so a set of users and devices could access the same database server (and corresponding database). This solution would always require internet access to be able to use the app, but that's already the normal today, and looking at how the technology is advancing (thinking Starlink, 5G), I can only see that becoming less of a problem.
For completeness, I also don't think a local-first sync service can be implemented with file syncing services + SQLite today, even if you only allow changes when online. First there are still chances of multiple people changing the database at the same time, which is not ok because file syncing services only see conflicts at the file-level and they would not be able to recover from them automatically. Finally, it'd probably also be weird to see a SQLite file in a folder somewhere in the file syncing service which could be accessed by any app that used this protocol. I would love to see SQLite being part of a local-first sync solution though.
Yeah, I get that you guys got your hands full. I'm curious enough to give this a spin.
Not necessarily a self-hosted sync service so much as an always-on device running this app in the background that accepts changes and stores it locally. That way, if I lose my phone, I have the data backed up on that device, and I should be able to just connect to the sync service and restore from backup. The sync service could still be hosted elsewhere.
I get your metaphor, but I think it falls down because "write once, deploy anywhere" was a slogan for Java and it never really fulfilled that promise.
And yes, like anything in life there are top-quality options which tend to be more expensive and lower-quality options which fit a smaller budget. MindNode is a lovely app and worth paying for IMO.
I'm a big fan of text files--my "thinking workspace" for over a decade was a folder full of .txt and .md files and vim. But as more of my reference material and creative inputs are images, PDFs, websites, etc that became limiting.
We evaluated all the major tablet platforms including Android and Chromebook a few years back[1], and found all of them lacking on hardware or OS capabilities in a way that would prevent build software like Muse.
Hoping things have changed since then or will change in the future. I feel like touch as a platform is too important to be so dominated by one vendor.
I skimmed the article, but what makes Android not sufficient to interact with Muse? I haven’t tried Muse, but I’ve thought plenty about building a local-first notebook app for thinking. Something about pen input or UI jank? Muse seems less general than I was thinking of it as being if only Apple hardware can run its core feature set…
In a word, latency. Everything feeling responsive and tactile is a part of the (tablet part) of the Muse experience. You can see the latency tests for various tablets in a table partway through the essay, and compare those to the human factors research and see that they are off by an order of magnitude for what's necessary to feel responsive. But those tests were a few years ago, would not be surprised if things have improved since then.
TBH I'm not really thrilled about being locked into iPad+Pencil either. But so far, Apple is the only one that has been able to cross the latency threshold with their hardware and OS. Hoping that will not be the case forever.
Obsidian is great, and they are similarly priced to us ($10/mo for sync).
We felt that local-first sync is a core feature of the product, and to exclude free users from that would be leaving out a huge amount of the value. So we opted to include it for everyone, but limit the amount you can store.
That's a little disingenuous to compare yourselves to obsidian price structure. With Obsidian I can connect it and sync via github/Dropbox/etc, and there are no feature limitations with the free product at all, whereas yours prevents the creation of new notes if you exceed the free note limit.
> if I stop paying for sync, I still have my notes and a fully functional product
The same is true for Muse. When your membership expires (or you cancel it) the app reverts to free mode, which allows you to read, copy, and export all your data. But if you're over the free card limit then you can't create new content.
That said I have total respect for the Obsidian model. They're really successful for very good reason.
Is it really though? Obsidian notes are plain text. I can open them in any plain text editor I want without needing to export anything, edit them and have the changes reflected in Obsidian later. The files are located in a folder on my machine - no conversion necessary.
OCR is one we've investigated but it's tricky to find the right API that is compatible with our local-first values. One customer tipped us off that the creators of Nebo have an interesting one. So we'll look into that.
Thanks! Yes, CRDTs are risky in the sense that they are computer science that is only just at the edge of what's possible in software today. A few folks have put them into practice in small ways (Figma comes to mind) but I wouldn't recommend it for most software projects.
That said I hope we (meaning everyone working on CRDTs and local-first) can help make it suitable for production use and perhaps it will be a common, maybe even standard, way to build software five or ten years from now. That's my hope/dream, at least.
Do you have any plans to handle schema changes for the content stored within the CRDTs as the clients evolve?
(I've been puzzling over that question during some local-first dabbling; I have a feeling that lenses[1] -- or something like them -- may provide a route towards schema version upgrades without any peer synchronization guarantees)
Yep, we already have basic support for versioning.
The foundation of our approach is to have a versioned, documented schema shared among clients. Every write down to the individual attribute level is persisted with a schema version. We're already several versions in, and indeed think it's healthy to get experience with version updates frequently so that it's not an unusual occurrence.
Currently we use this schema to interpret / coerce values as needed at read-time. For example we see an attribute has schema version 1, and know that it should be interpreted in the sense that we meant as of version 1. In the future, we may also choose to write out updates for "migrations" where that'd be helpful. So that e.g. instead of having to re-interpret values for older version 1, we'd right out an update to he attribute that overwrites the old value and updates the version tag to e.g. 3.
We do think lenses are interesting and the lab from which we spun out has done some good work with them: https://www.inkandswitch.com/cambria/. They're just a bit complex for our modest needs re: schema versioning at this time.
Yes, that's planned for somewhere in the 2.x series. Now that we have the foundational sync technology in place, we'll expand to other platforms include publishing to the web.
You'll be happy to know that Muse is designed to only gate creation of new documents on the membership, not access to anything you've already created. Lapsed memberships go into alumni mode where you can navigate, move, copy, and export everything.
