5 ms·

Wonderful work, but this doesn’t look like local first software to me. It looks like server first software with live updates and caching. Don’t get me wrong, t

Wonderful work, but this doesn’t look like local first software to me. It looks like server first software with live updates and caching. Don’t get me wrong, that’s super cool - but if you’re going to claim it’s local first software, I want to see the principles of local first software at play. And I don’t think Zero delivers that - at least as I understand it from its website. Like, “the network is optional” and “the long now” and “you (the user) retains ultimate control”. It just looks like an excellent server sync system with client side caching. What if the data I need isn’t in the cache? What happens when I edit things offline then come online later? What happens if the company shuts down and the server gets turned off permanently? Will the app still work? Local first software can handle these cases too. [1] https://www.inkandswitch.com/local-first/ https://www.inkandswitch.com/local-first/

nwienert 2y ago
I think this is fair, as they haven't committed to offline - though they've said they want to do it, they just want to wait to do it right. That said, they do work fully client-side, so I wouldn't say it's server-first, it's more of a hybrid. I will try and clear this up in our wording. Final note on the user-stuff: that's always up to the person writing the app anyway. You could make a "download the IndexedDB" button with a couple lines of code, but it's more than that, it's really a whole bunch of decisions you have to make as an app-developer to commit to it. And tbh I think the general understanding of local-first has settled on client-side + optimistic + offline - for the better.
- josephg 2y ago
  > I wouldn't say it's server-first because the mutations are happening locally first and every feature works fully client-side. That's not even close to what "local first software" means. Can apps work without the server? Like, if the server goes down, will the app still work? Can I collaboratively edit my data without the origin server? (Or at all?) Normally replication built on raw postgres queries relies on atomic row level locks on the server, while processing transactions. What happens if two people edit the same data at the same time? Does it support end-to-end encryption, so my data isn't readable by the server at all? Can I back up the app & my data together, and open it back up in 5 years and have the app still work? All this stuff is talked about in the local first paper. Putting a sync engine in front of postgres (as described by the zerosync website) doesn't do any of this stuff. (Or maybe some of it? Its hard to tell without more information, and I can't find a link to the source code.) It reminds me when Zoom advertised E2E encryption on zoom's website because the CTO clearly didn't know what "end to end encryption" actually means. It looks like an excellent product - so why exaggerate its capabilities? "Local first" doesn't mean "edits are applied speculatively in the client before they hit the server". It also doesn't mean "caching part of the centralized postgres database in the client". Go read the paper. The details matter. https://www.inkandswitch.com/local-first/ https://www.inkandswitch.com/local-first/
  - aboodman 2y ago
    [Moved up thread]
  - aboodman 2y ago
    To answer your specific questions: > What if the data I need isn’t in the cache? The developer can arrange for all the data to be in the cache if the want that part of the app to be fully offline capable. > What happens when I edit things offline then come online later? Zero won't support offline mutation at launch, but there's nothing preventing it from working. It is built on [Replicache](https://replicache.dev https://replicache.dev) which does support offline mutation. I think almost no software that claims to be local-first actually supports robust offline editing and merging. The only people I've seen really go for this is the I&S folks with their branching stuff and that was just an experiment. I'm excited to do this right, but most of our users care more about the ux and dx improvements while online, so we'll do it later. > What happens if the company shuts down and the server gets turned off permanently? Will the app still work? Developers can self-host Zero. In advance of any standards for sync, this is about the best you're going to get with any local-first software today, except maybe stuff that syncs to Dropbox (which is cool!). > Can apps work without the server? Like, if the server goes down, will the app still work? Yes. Read-only at alpha, and later read-write. > Can I collaboratively edit my data without the origin server? (Or at all?) Normally replication built on raw postgres queries relies on atomic row level locks on the server, while processing transactions. What happens if two people edit the same data at the same time? Yes. Zero uses server reconciliation, like our previous products Replicache and Reflect. You can read more here: https://rocicorp.dev/blog/ready-player-two https://rocicorp.dev/blog/ready-player-two (how could you even do realtime collaboration with postgres locks? that doesn't really make sense) > Does it support end-to-end encryption, so my data isn't readable by the server at all? Sure. That's up to the developer in how they design their database schema, but of course it's possible. > Can I back up the app & my data together, and open it back up in 5 years and have the app still work? I mean I guess so? If you had it in an electron app you just snapshot the data directory? An app developer could arrange for this to happen if it was important to them. Does this all count as local-first? I think it's about as local-first as most other software claiming the title. But again, I kind of prefer to focus on what our product does and for that reason I try to avoid claiming we're local-first.
- hosh 2y ago
  That is a disappointing interpretation of “local-first”, and would not suit the kind of applications I want to write. On the other hand, this is still tethered to the server, so likely more commercially viable than a true local-first design.
  - josephg 2y ago
    > That is a disappointing interpretation of “local-first”, and would not suit the kind of applications I want to write. I don’t think anyone wants or expects all software to be local first. What would it even mean to "locally first" turn the lights in my house on and off, check the weather, or play a multiplayer-only video game? Local first makes a lot of sense for some use cases - like personal / creative work (eg Apple Notes). But not for others.
    - hosh 2y ago
      - turn on lights — there are smart light bulbs that phone home to the cloud. Along with smart assistance, home automation, etc. those are exactly the things that should be local-first, or at least, the server software should be onsite (such as Home Assistant — edge computing). We already have examples of what happens when companies shut down the servers those automations depend upon. To go even fuether, each device that is truly local-first enables the kind of cooperative automation conceived of in Promise Theory. - checking the weather — although predictions are easier to come by from NOAA’s weather models, areas can have microclimates both natural and man-made that are not so easily predicted through atmospheric modelling. Permaculture design includes scaling microclimates in very small areas (on the order of specific plants) to tweak what can grow there. Local-first makes sense if you want to instrument those microclimates. Better yet, there are ways to read the clouds and conditions to get decent predictions for weather conditions for your immediate area. - local-first multiplayer video game - what an intriguing idea! The closest I can think of is that multi-user virtual reality spaces that was built on a modern version of Smalltalk. It isn’t local first, but it supports multiple, independent servers that mesh together. There are probably also ways to do this with turn based games, such as chess or go. Do you have any other examples? The ones you brought up were a good exercise to see how far one can take local-first design.
aboodman 2y ago
Hi Joseph, There is a lot of debate about this in the community. People like pvh, adam wiggins, and johannes have all said they consider Replicache and Zero part of the local-first movement [1] and that they would be sad if we and other things like us weren't in it. I was even invited to speak at local-first conf, where we announced Zero last May. [2] I think in practice delivering on the local-first ideals is ultimately up to the app developer not the library. Like in practice every yjs app talks to its server over some bespoke protocol and is loaded over a URL. If that server goes away your yjs app is a brick. No less a brick than if your zero server goes away. Similarly although everyone likes to claim Linear as a local-first app, if the Linear server goes away your Linear app is a brick. Yeah you can export the data from IDB or whatever but you could do the same for Zero or any of these systems. That all said, for our part, we have recently tried to avoid claiming Zero and Replicache as local-first on our own sites to avoid this controversy [3]. I think we're building something really valuable that a lot of people are excited about. And I think we're making the right tradeoffs for the majority of software that most people use every day. So I don't really care too much if it qualifies as local-first (except insofar as I like hanging out with the local-first folks and would be sad to not get invited to the parties). I forgot to mention this to Nate when he showed me these mocks for One because honestly almost everyone else (not us) refers to Replicache and Zero as local-first and it's easy to forget. I'll leave it to him to decide what to do with his own product, but it seems easy enough to me to soften the language. [1] https://youtu.be/cgTIsTWoNkM?si=6bYAAunqd5kdl-UL&t=2692 https://youtu.be/cgTIsTWoNkM?si=6bYAAunqd5kdl-UL&t=2692 [2] https://www.youtube.com/watch?v=rqOUgqsWvbw https://www.youtube.com/watch?v=rqOUgqsWvbw [3] https://zerosync.dev/ https://zerosync.dev/, https://replicache.dev/ https://replicache.dev/
- josephg 2y ago
  > I think we're building something really valuable that a lot of people are excited about. And I think we're making the right tradeoffs for the majority of software that most people use every day. I agree! I wanted live server sync like this for years. And I built ShareDB years ago along those lines, many years before the term “local first” came into being. But I see a pretty big difference between “server based app with sync” and “local first software”, party invitations aside. I wish we made a term for server based sync - I think it’s marvellous, and it’s important for all sorts of use cases. I think it’s ridiculous modern databases don’t have live queries built in as a standard part of sql. You’re doing great work here. But all that said, I personally actively avoid calling sharedb local first because I don’t think it is. One big difference is authentication - who has permission to edit the database? And when? With sharedb (and I assume zero), it’s possible to add logic on the server to reject edits. It’s not possible to do this in the same way when clients can write to Yjs or automerge, connect to one another directly and broadcast their changes without the server in the loop. That’s a pretty big difference - at least to me. I can’t speak for pvh, since I don’t get invited to those parties. But I want language to differentiate those two kinds of software. I’ve been writing software that straddles that line for over a decade, and that difference of how authoritative the root server is really important. It really changes a lot of things about how we build software. I think the situation is like if we didn’t have a good term for client-server encryption so everyone just calls their software E2E encrypted even when it’s just using tls and encrypting data in transit. I don’t think you should stop going to local first events. But I don’t think being invited to super cool parties tells us anything about your code. That makes you, personally, a member of a community. But the local first software question is, as I see it, a technical distinction. Not a social one. The zerosync website says this: > But where Zero really shines is “local-first” style applications like Linear and Superhuman. Personally, I find that a pretty confusing claim. “Seamless online / offline support”? Sure. Rad as f? Absolutely. Local first? Eeehhh. It looks like a modern sharedb with a Postgres backend, better caching, maybe cleaner client side api and no collaborative editing. Definitely cool, but very, very different how local first software is described in the paper. That or I should start claiming sharedb is local first too, and muddy the waters forever. Gmail offline mode? Local first everyone. You're welcome! As for websites that support offline data but can’t be loaded without a server, why not? App manifests can solve a lot of that. (Though nobody ever tries actually opening websites when they’re offline, so maybe there’s no point setting it up). Personally, I’ve never heard of Linear. And I’ve never heard “everyone say” it’s local first. But if it’s a brick without the server, sorry, but I think everyone is wrong.

nwienert 2y ago

I think this is fair, as they haven't committed to offline - though they've said they want to do it, they just want to wait to do it right. That said, they do work fully client-side, so I wouldn't say it's server-first, it's more of a hybrid. I will try and clear this up in our wording. Final note on the user-stuff: that's always up to the person writing the app anyway. You could make a "download the IndexedDB" button with a couple lines of code, but it's more than that, it's really a whole bunch of decisions you have to make as an app-developer to commit to it. And tbh I think the general understanding of local-first has settled on client-side + optimistic + offline - for the better.

josephg 2y ago
> I wouldn't say it's server-first because the mutations are happening locally first and every feature works fully client-side. That's not even close to what "local first software" means. Can apps work without the server? Like, if the server goes down, will the app still work? Can I collaboratively edit my data without the origin server? (Or at all?) Normally replication built on raw postgres queries relies on atomic row level locks on the server, while processing transactions. What happens if two people edit the same data at the same time? Does it support end-to-end encryption, so my data isn't readable by the server at all? Can I back up the app & my data together, and open it back up in 5 years and have the app still work? All this stuff is talked about in the local first paper. Putting a sync engine in front of postgres (as described by the zerosync website) doesn't do any of this stuff. (Or maybe some of it? Its hard to tell without more information, and I can't find a link to the source code.) It reminds me when Zoom advertised E2E encryption on zoom's website because the CTO clearly didn't know what "end to end encryption" actually means. It looks like an excellent product - so why exaggerate its capabilities? "Local first" doesn't mean "edits are applied speculatively in the client before they hit the server". It also doesn't mean "caching part of the centralized postgres database in the client". Go read the paper. The details matter. https://www.inkandswitch.com/local-first/ https://www.inkandswitch.com/local-first/
- aboodman 2y ago
  [Moved up thread]
- aboodman 2y ago
  To answer your specific questions: > What if the data I need isn’t in the cache? The developer can arrange for all the data to be in the cache if the want that part of the app to be fully offline capable. > What happens when I edit things offline then come online later? Zero won't support offline mutation at launch, but there's nothing preventing it from working. It is built on [Replicache](https://replicache.dev https://replicache.dev) which does support offline mutation. I think almost no software that claims to be local-first actually supports robust offline editing and merging. The only people I've seen really go for this is the I&S folks with their branching stuff and that was just an experiment. I'm excited to do this right, but most of our users care more about the ux and dx improvements while online, so we'll do it later. > What happens if the company shuts down and the server gets turned off permanently? Will the app still work? Developers can self-host Zero. In advance of any standards for sync, this is about the best you're going to get with any local-first software today, except maybe stuff that syncs to Dropbox (which is cool!). > Can apps work without the server? Like, if the server goes down, will the app still work? Yes. Read-only at alpha, and later read-write. > Can I collaboratively edit my data without the origin server? (Or at all?) Normally replication built on raw postgres queries relies on atomic row level locks on the server, while processing transactions. What happens if two people edit the same data at the same time? Yes. Zero uses server reconciliation, like our previous products Replicache and Reflect. You can read more here: https://rocicorp.dev/blog/ready-player-two https://rocicorp.dev/blog/ready-player-two (how could you even do realtime collaboration with postgres locks? that doesn't really make sense) > Does it support end-to-end encryption, so my data isn't readable by the server at all? Sure. That's up to the developer in how they design their database schema, but of course it's possible. > Can I back up the app & my data together, and open it back up in 5 years and have the app still work? I mean I guess so? If you had it in an electron app you just snapshot the data directory? An app developer could arrange for this to happen if it was important to them. Does this all count as local-first? I think it's about as local-first as most other software claiming the title. But again, I kind of prefer to focus on what our product does and for that reason I try to avoid claiming we're local-first.
hosh 2y ago
That is a disappointing interpretation of “local-first”, and would not suit the kind of applications I want to write. On the other hand, this is still tethered to the server, so likely more commercially viable than a true local-first design.
- josephg 2y ago
  > That is a disappointing interpretation of “local-first”, and would not suit the kind of applications I want to write. I don’t think anyone wants or expects all software to be local first. What would it even mean to "locally first" turn the lights in my house on and off, check the weather, or play a multiplayer-only video game? Local first makes a lot of sense for some use cases - like personal / creative work (eg Apple Notes). But not for others.
  - hosh 2y ago
    - turn on lights — there are smart light bulbs that phone home to the cloud. Along with smart assistance, home automation, etc. those are exactly the things that should be local-first, or at least, the server software should be onsite (such as Home Assistant — edge computing). We already have examples of what happens when companies shut down the servers those automations depend upon. To go even fuether, each device that is truly local-first enables the kind of cooperative automation conceived of in Promise Theory. - checking the weather — although predictions are easier to come by from NOAA’s weather models, areas can have microclimates both natural and man-made that are not so easily predicted through atmospheric modelling. Permaculture design includes scaling microclimates in very small areas (on the order of specific plants) to tweak what can grow there. Local-first makes sense if you want to instrument those microclimates. Better yet, there are ways to read the clouds and conditions to get decent predictions for weather conditions for your immediate area. - local-first multiplayer video game - what an intriguing idea! The closest I can think of is that multi-user virtual reality spaces that was built on a modern version of Smalltalk. It isn’t local first, but it supports multiple, independent servers that mesh together. There are probably also ways to do this with turn based games, such as chess or go. Do you have any other examples? The ones you brought up were a good exercise to see how far one can take local-first design.

aboodman 2y ago

Hi Joseph, There is a lot of debate about this in the community. People like pvh, adam wiggins, and johannes have all said they consider Replicache and Zero part of the local-first movement [1] and that they would be sad if we and other things like us weren't in it. I was even invited to speak at local-first conf, where we announced Zero last May. [2] I think in practice delivering on the local-first ideals is ultimately up to the app developer not the library. Like in practice every yjs app talks to its server over some bespoke protocol and is loaded over a URL. If that server goes away your yjs app is a brick. No less a brick than if your zero server goes away. Similarly although everyone likes to claim Linear as a local-first app, if the Linear server goes away your Linear app is a brick. Yeah you can export the data from IDB or whatever but you could do the same for Zero or any of these systems. That all said, for our part, we have recently tried to avoid claiming Zero and Replicache as local-first on our own sites to avoid this controversy [3]. I think we're building something really valuable that a lot of people are excited about. And I think we're making the right tradeoffs for the majority of software that most people use every day. So I don't really care too much if it qualifies as local-first (except insofar as I like hanging out with the local-first folks and would be sad to not get invited to the parties). I forgot to mention this to Nate when he showed me these mocks for One because honestly almost everyone else (not us) refers to Replicache and Zero as local-first and it's easy to forget. I'll leave it to him to decide what to do with his own product, but it seems easy enough to me to soften the language. [1] https://youtu.be/cgTIsTWoNkM?si=6bYAAunqd5kdl-UL&t=2692 https://youtu.be/cgTIsTWoNkM?si=6bYAAunqd5kdl-UL&t=2692 [2] https://www.youtube.com/watch?v=rqOUgqsWvbw https://www.youtube.com/watch?v=rqOUgqsWvbw [3] https://zerosync.dev/ https://zerosync.dev/, https://replicache.dev/ https://replicache.dev/

josephg 2y ago
> I think we're building something really valuable that a lot of people are excited about. And I think we're making the right tradeoffs for the majority of software that most people use every day. I agree! I wanted live server sync like this for years. And I built ShareDB years ago along those lines, many years before the term “local first” came into being. But I see a pretty big difference between “server based app with sync” and “local first software”, party invitations aside. I wish we made a term for server based sync - I think it’s marvellous, and it’s important for all sorts of use cases. I think it’s ridiculous modern databases don’t have live queries built in as a standard part of sql. You’re doing great work here. But all that said, I personally actively avoid calling sharedb local first because I don’t think it is. One big difference is authentication - who has permission to edit the database? And when? With sharedb (and I assume zero), it’s possible to add logic on the server to reject edits. It’s not possible to do this in the same way when clients can write to Yjs or automerge, connect to one another directly and broadcast their changes without the server in the loop. That’s a pretty big difference - at least to me. I can’t speak for pvh, since I don’t get invited to those parties. But I want language to differentiate those two kinds of software. I’ve been writing software that straddles that line for over a decade, and that difference of how authoritative the root server is really important. It really changes a lot of things about how we build software. I think the situation is like if we didn’t have a good term for client-server encryption so everyone just calls their software E2E encrypted even when it’s just using tls and encrypting data in transit. I don’t think you should stop going to local first events. But I don’t think being invited to super cool parties tells us anything about your code. That makes you, personally, a member of a community. But the local first software question is, as I see it, a technical distinction. Not a social one. The zerosync website says this: > But where Zero really shines is “local-first” style applications like Linear and Superhuman. Personally, I find that a pretty confusing claim. “Seamless online / offline support”? Sure. Rad as f? Absolutely. Local first? Eeehhh. It looks like a modern sharedb with a Postgres backend, better caching, maybe cleaner client side api and no collaborative editing. Definitely cool, but very, very different how local first software is described in the paper. That or I should start claiming sharedb is local first too, and muddy the waters forever. Gmail offline mode? Local first everyone. You're welcome! As for websites that support offline data but can’t be loaded without a server, why not? App manifests can solve a lot of that. (Though nobody ever tries actually opening websites when they’re offline, so maybe there’s no point setting it up). Personally, I’ve never heard of Linear. And I’ve never heard “everyone say” it’s local first. But if it’s a brick without the server, sorry, but I think everyone is wrong.