Hello, we've published some more work in this space -- no HTML version yet, but here's a more recent paper on our PushPin project.<p><a href="https://martin.kleppmann.com/papers/pushpin-papoc20.pdf" rel="nofollow">https://martin.kleppmann.com/papers/pushpin-papoc20.pdf</a><p>You can also try PushPin for yourself:
<a href="https://github.com/automerge/pushpin/" rel="nofollow">https://github.com/automerge/pushpin/</a><p>likely outdated binaries are available here:
<a href="https://automerge.github.io/pushpin/" rel="nofollow">https://automerge.github.io/pushpin/</a><p>Also, we're currently in the midst of a new project called Cambria, exploring some of the consequences and data demands for a new Cambrian-era of software here: <a href="https://inkandswitch.github.io/cambria/" rel="nofollow">https://inkandswitch.github.io/cambria/</a>
> ... cloud apps depend on the service continuing to be available: if the service is unavailable, you cannot use the software, and you can no longer access your data created with that software. This means you are betting that the creators of the software will continue supporting it for a long time — at least as long as you care about the data. Although there does not seem to be a great danger of Google shutting down Google Docs anytime soon, popular products (e.g. Google Reader) do sometimes get shutdown or lose data, so we know to be careful.<p>Plus, the value of the cloud app is not just your data, but the network effects. Like, if you've emailed links to a GDocs document, and 5 years later you decide to move to another service, those GDocs links will 404, regardless of whether you've transferred all of your data to the new service.<p>With local-first apps, the URL starts with <i>you</i>, not some <i>some-sass-provider.com</i>.
This is the 3rd time in a week a "Local-First software" overview has been submitted and the 2nd time it's made the front page here. I'm pretty surprised about that because I'm about to release a local-first, offline-first, option for an app I make.<p>This article also quickly moves past "local-first" software to conflict resolution which, in my opinion, is a distinctly different issue. It's certainly not reason enough to hold off offering users a local-first option.<p>At this point I believe that since it can be done it should be done. I'll even go so far as to say it's a necessity. At some point users will understand it's a necessity and demand it. All that really needs to happen to convince them is one big incident where they lose access to their data for an extended period of time, or worse yet, lose all their data forever, and it won't matter why or how.<p>Aside from that, as more app makers start offering local-first options and users begin to see the benefits of that they will begin to demand it. That could take some time, but I expect it's inevitable.<p>There are other benefits to a local-first approach for developers. Take a "Contacts" app for example. If we have a standard for saving contacts data on the client side that any app could access this would give users and developers options to create and use new apps and features that all use the same data.<p>CouchDB & PouchDB.js provide a pretty solid and easy way to do this right now. Installed on the user's desktop PC, CouchDB provides the missing link to a robust client side web app runtime environment.<p>There may be other ways of achieving this right now, but I am not aware of them.
I think there's probably a market for a personal cloud, which probably sounds dumber than personal computer did in the 80s. What I mean by that is a computer somewhere in the garage, like a furnace, with enough compute and storage to drive all the devices and appliances in a house. In this model, devices do not have CPUs or memory, only input/output and a network chip.<p>The way this would work is for the computer in the garage to have the ability to divide itself arbitrarily into VMs for each purpose, with an ecosystem of images designed for things like fridges and gaming consoles. It should be possible to add or upgrade compute to the device in a hot swapped fashion, and because it doesn't have to be in a thin tablet, it could be easily cooled.
I skimmed the desired qualities, the review of current tools, and finally the software centric approach to achieving the stated goals.<p>While we can reasonably expect software elements in any proposed solution, the hardware and physical elements of distributed computing may provide a far simpler pathway and likely will permit much greater reuse of existing proven software approaches.<p>For example, all future multi-unit residences could come with 'data center' along with the boiler, or possibly the actual units will host this equipment along with their air conditioning units. All your cloud apps can now point to this cloud. I don't see any fundamental reason why 'data center' can not become a modular utility unit, coming in domicile, commercial, and industry grade flavors.<p>In my view, the pure software solution approach to the 'modern informaton society' has implicit political dimensions. One of these is the concentrated private ownership and control over physical resources which are now a required substrate of modern society. I for one am not ready to accept that as 'acceptable'.
I'll take cloud first thanks. No software to update. Nothing to backup. I just open a computer/phone/tablet and access my stuff.<p>I get the tradeoffs. I'm not going back 10+ years.
The No Spinners thing seems to be my professional niche. Every job I’m tasked at cleaning up a poorly performing native app. And it’s always caused by developers writing views like web apps, posting their server requests as views open and fire up a spinner to wait.<p>It’s not that hard to have a caching strategy. And then your native app feels like a native app.
What's the origin of the "X-first" language pattern? Earliest example I cam remember is when Eric Schmidt was talking about "mobile first" approach.
It's worth noting that a local-only offline-first web app shifts the load of storing and managing user data entirely onto the user themselves.<p>That's a huge load of responsibility taken off the software supplier's shoulders and it eliminates the entire cost and complexity of building and maintaining Cloud based data management infrastructure.<p>And that's a pretty great option to have on the table for both users and software makers.<p>I'll also note that these apps consume almost no network bandwidth. With Service Workers implemented they barely speak to your server. The amount of bandwidth that can be potentially saved has got to be pretty huge.
As partly a philosophical exercise, and partly as hyperlocal "no really, you are here so you have access", I added Apache with DAV and Etherpad to a DNS+DHCP "sled": <a href="https://github.com/m3047/pangolin" rel="nofollow">https://github.com/m3047/pangolin</a><p>The irony that Etherpad is written in Node is not lost on me.
Made the front page a few days ago but didn't get much traffic or many comments:<p><a href="https://news.ycombinator.com/item?id=23985816" rel="nofollow">https://news.ycombinator.com/item?id=23985816</a><p><a href="http://hnrankings.info/23985816/" rel="nofollow">http://hnrankings.info/23985816/</a>
Im doing a "browser-based something" that can mostly be reasoned about as a web-over-rpc-services where the primary pitch to start it, was exactly based on the thinking generously expressed by this article (albeit i had to start it much earlier).<p>The first thing is to expect the app devs to define a api in RPC so that what they app serve it transparent to the whole platform.<p>That way, users and other apps can reuse that api and integrate tools and other services without worrying about if the node is online or not.<p>Given they are RPC (over TCP or IPC), they can be used as a peer node in a distributed computing flock or in the app service process the application can serve the RPC requests not locally if it wants or needs, but going over the network.<p>But even in the case it goes straight to the "cloud" for resources, in the node it will always go through the RPC-api first. (How the application handle the RPC request is defined by the app developers).<p>There are a lot of others important details actually, for instance the UI sdk, window management, its already there, the storage layer (files and key-value db) are distributed over p2p(torrent) and everything is accessible/bootstrapped through a DHT address accessible anywhere.<p>But imagine if you had this architecture before, and Twitter, Facebook or Google search had to install a api-based application, where they need to ask you for permission to index content, or store locally your list of friends.. where later other apps could extract that information from your machine.. For instance you could change your search to DDG or export your Facebook list of friends and post to some other social network(this is actually the primary reason almost no one could compete with a popular social network).<p>In the end, things that should be yours are yours and third-party apps will have to be installed and granted permission by you to manage that digital property.<p>But overall i'm very glad to see that this is starting to become some sort of a trend, that people are finally waking up, because despite of all technological implications of it, it also have a lot of political and social benefits to this approach.
As platforms get more and more locked down (Chromebooks, Android, iOS) hosting the software in the cloud becomes a easier option. For example I'm working on and editor/IDE for programming, but it's next to impossible to compile programs on the platforms people use now a days. So in order to run a program that you made on your Apple phone, Android device or Chromebook, it has to run on a third party server...
Much of this seems to be rediscovering the principles of the IndieWeb movement, who have already thought about many of the issues discussed here.<p><a href="https://indieweb.org/silo" rel="nofollow">https://indieweb.org/silo</a><p><a href="https://indieweb.org/data-portability" rel="nofollow">https://indieweb.org/data-portability</a>
How about a more generalised collaboration system, where you just edit your files lot Cally as standard, but can kind of dial in using o collaboration - a bit like a screen share on a call. So suddenly the people you've dialled can leave comments on your work etc, but when you cut the connection, they can't any more?
Take a look at the PJON protocol that is a perfect example of a local-first networking technology, I am really amazed by the job they did on that! <a href="https://github.com/gioblu/PJON" rel="nofollow">https://github.com/gioblu/PJON</a>
Unfortunately local-first software is incompatible with you being a slave to your preferred technology company of choice (Facebook, Apple, Google, Microsoft).<p>If it wasn't for GDPR, most of these companies wouldn't even offer exports of your data.
if you prefer HTML over PDF it's <a href="https://www.inkandswitch.com/local-first.html" rel="nofollow">https://www.inkandswitch.com/local-first.html</a>