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

291–300 of 308 posts

Re: Local-first software (2019)

#291

Post by fauigerzigerk »

throw10920 wrote: post #286
fauigerzigerk wrote: post #280

Earlier quoted context omitted.

>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/

Thank you for the correction! I was not aware of this. It's still worth pointing out that this design decision is orthogonal to the decision to use SQLite, though. The Bear devs could have designed it such that you could write to the database directly, or they could have kept the text-file-based design, but still told the user that they can't modify the files directly (as one of my personal projects does). The assign…

You are right that storing notes as individual text files in the file system doesn't guarantee safe read-write access. But I don't agree that these design decisions are orthogonal.

How would you design a system that uses SQLite as primary storage for notes (rather than just as a search index or metadata store) while still letting people edit those notes in any text editor, sync via any cloud and make them accessible to any AI or other third party software that knows how to use a file system?

Exporting and re-importing every single time you want to edit a note is impractical for tech folks and impossible for regular users.

I can imagine a partial solution using FUSE, FileProvider and whatever the respective file system abstractions are on other platforms. But that would be a huge amount of work.

Re: Local-first software (2019)

#292

Post by Timwi »

_heimdall wrote: post #279
Timwi wrote: post #227

Earlier quoted context omitted.

> 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 jus…

I can't speak for every UBI supporter, but singling out food, and talking about “the food they want me to have”, suggests an authoritarian top-down structure that nobody wants. The whole point of UBI is to enable autonomy. People should be free to explore and understand what their own needs are and not have it be dictated.

I'll admit that I was unclear because I used the word “starve” in my message. Obviously this choice of word was borne out of the principle that food is among the most vital basic needs, and that depriving people of it is one prominent way in which our current society is cruel. Nevertheless, UBI is not about just food, but more generally about basic needs.

Re: Local-first software (2019)

#293

Post by _heimdall »

Timwi wrote: post #292
_heimdall wrote: post #279

Earlier quoted context omitted.

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 jus…

I can't speak for every UBI supporter, but singling out food, and talking about “the food they want me to have”, suggests an authoritarian top-down structure that nobody wants. The whole point of UBI is to enable autonomy. People should be free to explore and understand what their own needs are and not have it be dictated. I'll admit that I was unclear because I used the word “starve” in my message. Obviously this ch…

The amount if UBI paid to people must be based on some determination of the estimated cost of a list of basic goods though, right?

Surely it wouldn't just be food, but regardless the government would be coming up with a list of items and basing the UBI on that. If those items are deemed necessary enough that everyone should have access, why not make them freely available rather than abstracting through money first?

Re: Local-first software (2019)

#295

Post by GregorStocks »

strus wrote: post #289
GregorStocks wrote: post #271

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 operati…

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. This is what every "cloud file sharing" provider like Dropbox is doing. If there is a conflict, the version on the server is "the right one", and your locally conflicted file is copied on the side with some annotation in the file name.

Yeah, but Dropbox is sort of playing on easy mode, because the data is "just files" and you can manually resolve the conflict with regular old text editors, etc. If you don't expose your app's data model in the file system (and on a phone you generally wouldn't), that means you need to write something custom to resolve the conflicts.

Re: Local-first software (2019)

#296

Post by biozal »

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…

You might also want to check out Ditto:

https://www.ditto.com

It’s a local-first platform that supports real-time sync with CRDTs at its core, making conflict resolution much easier to manage. Ditto is designed to handle offline-first use cases and peer-to-peer sync out of the box, so you don’t have to build a custom sync engine from scratch.

It supports a wide range of platforms including Swift, Kotlin (Android), Flutter/Dart, React Native, JavaScript (Web/Node), .NET (C#), C++, Java, and Rust. You can dive deeper into what it offers from the docs site: https://docs.ditto.live/home/about-ditto

Re: Local-first software (2019)

#297

Post by biozal »

cheema33 wrote: post #22

The primary challenge with building local first software is the sync layer. The current 3rd party offerings are not mature. And people have been working on these for a few years. Electric SQL comes to mind.

I'm curious on what you experienced that caused you to come to the conclusion that 3rd party sync solutions are not mature. There are several 3rd party vendors like Ditto that have been building local first sync solutions that are used by very large companies with success.

Re: Local-first software (2019)

#298

Post by MerrimanInd »

samwillis wrote: post #40

There is now a great annual Local-first Software conference in Berlin ( https://www.localfirstconf.com/ ) organised by Ink and Switch, and it's spawned a spin out Sync Conf this November in SF ( https://syncconf.dev/ ) There was a great panel discussion this year from a number of the co-authors of the the paper linked, discussing what is Local-first software in the context of dev tools and what they have learnt since…

There's also an excellent Local First podcast that interviews the engineers building local-first apps and infra!

https://www.localfirst.fm/

Re: Local-first software (2019)

#299

Post by DrillShopper »

the_snooze wrote: post #6

Anything with online dependencies will necessarily require ongoing upkeep and ongoing costs. If a system is not local-first (or ideally local-only), it’s not designed for long-term dependability. Connected appliances and cars have got to be the stupidest bit of engineering from a practical standpoint.

Anybody opposing the "Stop Killing Games" initiative should read this comment.

Nobody is forcing anybody to make their games rely solely on online services. It's not a legal requirement, regulatory requirement, or anything else. It is a choice, like most things in software. To make the choice to rely on online services and then say "we'll have to spend money later to unfuck this!" is honestly short sided, pathetic, and nobody should accept it.

Re: Local-first software (2019)

#300

Post by lurking_swe »

gerdesj wrote: post #166
lurking_swe wrote: post #131

Earlier quoted context omitted.

your comment is insane imo. some people talk that way in real life. it’s not their fault LLM’s were invented.

Not so insane as it turns out - P is using the language of LLMs because english is a second language for them. Perhaps you will not take umbrage when I point out that you use full stops (periods) but not bother with twitching a finger towards your shift key. I will guess you are using a phone/tablet and have to switch keyboard layouts to get something as exotic as a capital letter on the screen.

indeed, i often browse hacker news on mobile instead of my laptop.
Post reply on HN