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) 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:
(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.
Oh I hadn't seen that before, and I love that. It looks like an extension of database transactions / MVCC into the client.
Its interesting thinking about what situations this will & won't work in. I imagine it'd work for most of the mutations made in most applications, like editing rows in a database. And in your example, inserting at the end of a list would work.
But what about inserting in the middle of a list (or, typing in a text document)? Naively, it wouldn't work because "insert at position X" changes its meaning wrt. concurrent edits. But you could make OT work if you provided a way to change the arguments themselves if concurrent changes were detected. (Thats essentially all OT is. When concurrent changes happen, run the transform function. op = transform(op, other_op)).
Interestingly, I think you could use a text CRDT (like yjs) with your architecture. You would need to run the crdt's prepare function in the client first, to convert the edit into the CRDT's format (eg for Yjs, that looks like Insert('a', left_id: XX, right_id: YY). Then if you passed that object into the transaction closure, you could run the CRDT on the server and it'd all work out.
Its not quite as obvious and straightforward as your examples. But still, very cool that its extensible like that.
> 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) 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
(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.