Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Local-first software (2019)

inkandswitch.com

Post reply on HN
Print view View original

271–280 of 308 posts

Re: Local-first software (2019)

#271

Post by GregorStocks »

I've always thought that this article overstates the promise of CRDTs with regard to conflict resolution. For toy cases like a TODO list, yes, you can define your operations such that a computer can automatically reconcile conflicts - e.g. you only support "add" and "mark as complete", and if something gets marked as complete twice, that's fine.

But once you get past toy examples, you start wanting to support operations like "edit", and there generally isn't a way to infer the user's intent there. Like, if my cookie recipe starts with 100g of sugar, and I modify it on my phone to use 200g of sugar, and I modify it on my desktop to use 150g of honey instead of 100g of sugar, there are a bunch of ways to reconcile that:

1. Stick with 200g of sugar, drop the 1.5x honey substitution.

2. Stick with 150g of honey, drop the 2x.

3. Merge them - 300g of honey.

4. Merge them - 150g of honey and 50g of sugar.

There's no way for any automated system to infer my intent there. So you've got to either:

1. Ask the user to resolve the conflict. This means you have to build out the whole "resolve this merge conflict for me" UI and the promise of "conflict-free" has not been fulfilled.

2. Arbitrarily choose an option and silently merge. This risks badly surprising the user and losing changes.

3. Arbitrarily choose an option, but expose the fact that you've auto-resolved a conflict and allow the user to manually re-resolve. This requires even more UI work than option 1.

4. Constrain your data model to only allow representing intents that can be deterministically resolved. In practice I think this is too severe of a constraint to allow building anything other than toy apps.

IMO #1 and #3 are the least-bad options, but I don't think they're consistent with the expectations you'd have for CRDTs after reading this article.

(FWIW, https://automerge.org/docs/reference/documents/conflicts/ is the relevant documentation for their Automerge library. It looks like they've chosen option 3.)

Re: Local-first software (2019)

#272

Post by stopachka »

swsieber wrote: post #181
davepeck wrote: post #10

In theory, I love the local-first mode of building. It aligns well with “small tech” philosophy where privacy and data ownership are fundamental. In practice, it’s hard! You’re effectively responsible for building a sync engine, handling conflict resolution, managing schema migration, etc. This said, tools for local-first software development seem to have improved in the past couple years. I keep my eye on jazz.tools…

I've been using instantdb in anger for the past month or so for a side project of mine. I'm building a personal budget app. I should probably write a blog post, but I will say that I investigated power sync, electricSQL, livestore and powersync before. I briefly looked at jazz tools but wanted something a bit more structured. I'm pretty impressed this far. I've actually been writing it with Vue and a community librar…

[Instant founder]

Brightened reading this. If you have any feedback please let us know! We on the discord, and answer over on founders@instantdb

Re: Local-first software (2019)

#273

Post by nanomonkey »

hodgesrm wrote: post #268

> Local-first apps, on the other hand, have better privacy and security built in at the core. I love this article, but the section on security raised a lot of questions. What's the model for authorizing access to documents for collaboration? How do you managed keys safely for encrypted data? How do users recover "lost" keys? Cloud computing models have a lot of security mechanisms built-in. You might not like the mod…

Shamir's Secret sharing allows one to store secret keys within m of n number of your peer group (where m is less than n), thus you can hand out an encrypted secret with 5 of your friends and reproduce the secret by getting 3 of them to respond back to you with the secret at a later date. None of the peers will be able to reproduce the secret by themselves.

There are other options for key storage, revoking group privileges, etc. It's an extensive topic, but the foundation is there, it just depends on your network and use cases.

Re: Local-first software (2019)

#274

Post by rshemet »

Interesting to think about the concept of local-first in the age of AI.

Wanting to be able to run AI fully privately, and offline is the reason we created Cactus:

https://github.com/cactus-compute/cactus

Fully open-source, cross-platform & blazing-fast; lets you plug in private AI into any app on your phone.

Re: Local-first software (2019)

#275

Post by crossroadsguy »

throw10920 wrote: post #267
crossroadsguy wrote: post #228

Earlier quoted context omitted.

This is the reason I have always refused to use Bear note taking app irrespective of how good and snappy that app is. Because they keep their notes in a SQLite db now and even though that file can be backed up and handled locally my notes are not easily accessible to me. I can't easily edit my notes in other editors (which I often like to do on my mac), I can't version controlled backup and sync those files the way I…

> What is sad is that they used to be local files first note app and then they moved to sqlite citing some sync and performance issues. They're still a local-first note application. It's just slightly harder for you to edit your notes externally, and not even by that much - it's very easy to directly query (read and write) SQLite databases, and if you really cared you could have made a script to grab a note, export i…

Goodness! Are you a bear dev by any chance or a dedicated member of its particularly toxic subreddit? Because the tone fits right in.

> It's just slightly harder for you to edit your notes externally

Yup, just slightly harder! Very slightly. A difference of 3.75 picoseconds. Couldn't agree more.

> it's very easy to directly query

Right!

> and if you really cared..have made a script

And designed a nuclear reactor while I was at it, isn't it?

> The devs made the right choice

Yessss!! Finally.

Ffs!!!

Re: Local-first software (2019)

#276

Post by crossroadsguy »

strken wrote: post #261
crossroadsguy wrote: post #257

Earlier quoted context omitted.

Yes, I feel the same. A rock solid app dismantled by just one developer choice. Still I won't diss the devs because it's their choice but "a text note" is the last thing I would want "locked" in a sqlite db and bear is a "plain text note taking app" really. So just sad.

From memory the sqlite3 API is something like sqlite3 data.db 'select text from notes' I use sqlite3 to load and query random CSVs all the time. It feels a bit weird to hear data described as "locked" within a SQLite DB, because it's one of the simplest non-text formats for me to read data from. It would surprise me of it took more than five minutes to set up a one-way cron job to dump your notes into plain text file…

My god! Really? What is this subthread now - bear app fan version of discussions.apple.com?

This is just unbelievable! Fucking pitchforks are out literally!

I am dealing with plain text notes and you all want me to write sql queries and scripts to access those fucking text files?

Are you all (these few people who just jumped in the subthread) pulling some sort of prank of so?

Re: Local-first software (2019)

#277

Post by throw10920 »

crossroadsguy wrote: post #275
throw10920 wrote: post #267

Earlier quoted context omitted.

> What is sad is that they used to be local files first note app and then they moved to sqlite citing some sync and performance issues. They're still a local-first note application. It's just slightly harder for you to edit your notes externally, and not even by that much - it's very easy to directly query (read and write) SQLite databases, and if you really cared you could have made a script to grab a note, export i…

Goodness! Are you a bear dev by any chance or a dedicated member of its particularly toxic subreddit? Because the tone fits right in. > It's just slightly harder for you to edit your notes externally Yup, just slightly harder! Very slightly. A difference of 3.75 picoseconds. Couldn't agree more. > it's very easy to directly query Right! > and if you really cared..have made a script And designed a nuclear reactor whil…

This comment does not contribute to the discussion and badly breaks the HN guidelines. Please review them: https://news.ycombinator.com/newsguidelines.html

Also interesting to note that you couldn't actually muster a coherent response to any of my points and just had to make ad hominem attacks and emotional outbursts.

Re: Local-first software (2019)

#278

Post by tyre »

crossroadsguy wrote: post #275
throw10920 wrote: post #267

Earlier quoted context omitted.

> What is sad is that they used to be local files first note app and then they moved to sqlite citing some sync and performance issues. They're still a local-first note application. It's just slightly harder for you to edit your notes externally, and not even by that much - it's very easy to directly query (read and write) SQLite databases, and if you really cared you could have made a script to grab a note, export i…

Goodness! Are you a bear dev by any chance or a dedicated member of its particularly toxic subreddit? Because the tone fits right in. > It's just slightly harder for you to edit your notes externally Yup, just slightly harder! Very slightly. A difference of 3.75 picoseconds. Couldn't agree more. > it's very easy to directly query Right! > and if you really cared..have made a script And designed a nuclear reactor whil…

> And designed a nuclear reactor while I was at it, isn't it?

Claude can one shot this.

Re: Local-first software (2019)

#279

Post by _heimdall »

Timwi wrote: post #227
danjl wrote: post #64

Earlier quoted context omitted.

Correct. SaaS is a business model, not a technical concept. But the real problem is that there is no equivalent business model for selling local first software. Traditional desktop apps were single purchase items. Local first is not because you just navigate to a website in your browser and blammo you get the software. What we need is a way to make money off of local first software.

> What we need is a way to make money off of local first software. No, what we need is a way for people to not starve so that they don't have to make money at all and can focus instead on their passion project(s). Cough UBI cough

I've never understood the end goal of a UBI. If the expectation is that everyone should be able to eat (seems like a noble goal), why obfuscate that by giving people money rather than access to free food?

If we really wanted a system where we deem certain items essential and went everyone to have access to them, it makes no sense to pay for them. Money may still make sense for nonessential or luxury items, but it just gets in the way if the government has to give me money so I can go spend it on the food they actually want me to have.

Re: Local-first software (2019)

#280

Post by fauigerzigerk »

throw10920 wrote: post #267
crossroadsguy wrote: post #228

Earlier quoted context omitted.

This is the reason I have always refused to use Bear note taking app irrespective of how good and snappy that app is. Because they keep their notes in a SQLite db now and even though that file can be backed up and handled locally my notes are not easily accessible to me. I can't easily edit my notes in other editors (which I often like to do on my mac), I can't version controlled backup and sync those files the way I…

> What is sad is that they used to be local files first note app and then they moved to sqlite citing some sync and performance issues. They're still a local-first note application. It's just slightly harder for you to edit your notes externally, and not even by that much - it's very easy to directly query (read and write) SQLite databases, and if you really cared you could have made a script to grab a note, export i…

>and if you really cared you could have made a script to grab a note, export it to a temporary text file, allow you to edit it, then update the SQLite database.

Bear devs advise against doing that: "Generally speaking, it is safe to access the database for reading only"

https://bear.app/faq/where-are-bears-notes-located/

Post reply on HN