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

201–210 of 308 posts

Re: Local-first software (2019)

#201

Post by solidsnack9000 »

GMoromisato wrote: post #24

Personally, I disagree with this approach. This is trying to solve a business problem (I can't trust cloud-providers) with a technical trade-off (avoid centralized architecture). The problems with closed-source software (lack of control, lack of reliability) were solved with a new business model: open source development, which came with new licenses and new ways of getting revenue (maintenance contracts instead of li…

This would make cloud vendors kind of like banks. The cloud vendor is holding a kind of property for the user in the user's account. The user would have clearly defined rights to that property, and the legal ability to call this property back to themselves from the account.

This calling back might amount to taking delivery. In a banking context, that is where the user takes delivery of whatever money and other property is in the account. In the cloud vendor case, this would be the user receiving a big Zip file with all the contents of the account.

Taking delivery is not always practical and is also not always desirable. Another option in a financial context is transferring accounts from one vendor to another: this can take the form of wiring money or sometimes involves a specialized transfer process. Transferring the account is probably way more useful for many cloud services.

This leads us to a hard thing about these services, though: portability. Say we delineate a clear property interest for user's in their cloud accounts and we delineate all of their rights. We have some good interests and some good rights; but what does it mean to take delivery of your Facebook friends? What does it mean to transfer your Facebook account from one place to another?

Re: Local-first software (2019)

#203

Post by jkestner »

rzzzt wrote: post #16
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…

CouchDB on the server and PouchDB on the client was an attempt at making such an environment: - https://couchdb.apache.org/ - https://pouchdb.com/ Also some more pondering on local-first application development from a "few" (~10) years back can be found here: https://unhosted.org/

Using Couch/Pouch on our current app for this reason. Great to work with. Though we’re not supporting offline-first right away (depends on external services), it’s going to help with resilience and a future escape valve.

Re: Local-first software (2019)

#204

Post by owebmaster »

sirjaz wrote: post #178
2color wrote: post #80

It's a very exciting moment for this movement. A lot of the research and tech for local-first is nearing the point that it's mature, efficient, and packaged into well designed APIs. Moreover, local-first —at least in theory— enables less infrastructure, which could reignite new indie open source software with less vendor lock-in. However, despite all my excitement about embracing these ideas in the pursuit of better…

We need to get back to apps rather than webapps. The hardware compatibility issues of the past are basically no longer here, and there are three major OS types two of which can use each other's apps.

Pretty much the opposite. Local-first makes web apps feel just like apps, without the native-apps security risks.

Re: Local-first software (2019)

#205

Post by owebmaster »

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.

As a local-first developer, I'd say the biggest challenge is p2p. Or more specifically, NAT traversal and the need of a TURN server.

Re: Local-first software (2019)

#207

Post by FallCheeta7373 »

dsp_person wrote: post #159
piperswe wrote: post #104

Earlier quoted context omitted.

Something like Syncthing, perhaps?

Anyone know of any mobile apps that have done this and bundled their own fork of syncthing under the hood for syncing?

Practically not really needed for a person going out of their way to setup syncthing, you can just sync the underlying folder, I do this with logseq, their syncing subscription is paid, I just sync the underlying logseq graph and markdown syntax. It's seamless and rarely disturbs me, works well in background, although android seemingly doesn't respect my background preferences, and clears it out of my ram when I inevitably hit the clear button, but that's soluble by simply rebooting once in a while.

Re: Local-first software (2019)

#208

Post by mazzystar »

This reminds me of my own painful story: I once made a local photo search app called Queryable that ported OpenAI's CLIP model to iPhone, letting you search your photos with queries like "a black cat sitting on a sofa."

Since it needed to access users' local photo libraries, I didn't want the app to connect to the internet under any circumstances. So I made it a paid app instead of the usual free+in-app purchases model, since the latter requires calling StoreKit which goes online. But because the app had to run the CLIP model, it would crash on lower-performance phones like the iPhone X. Users who paid for it couldn't use it and felt scammed, leading to tons of one-star reviews and angry complaints about their photos being stolen. Eventually I decided to open-source the app, though it never brought me much revenue anyway.

Two years later, Apple started announcing they'd be integrating this exact feature into Apple Intelligence : )

Re: Local-first software (2019)

#209

Post by nerdyadventurer »

DataDaoDe wrote: post #29

Yes a thousand percent! I'm working on this too. I'm sick of everyone trying to come up with a use case to get all my data in everyone's cloud so I have to pay a subscription fee to just make things work. I'm working on a fitness tracking app right now that will use the sublime model - just buy it, get updates for X years, sync with all your devices and use it forever. If you want updates after X years buy the newest…

> get updates for X years, sync with all your devices and use it forever. If you want updates after X years buy the newest version again. If its good enough as is - and that's the goal - just keep using it forever.

While this sounds good deal, with this approach

- You have to charge total cost of subscription at once (1y or 2y),

- Still have to keep servers running for syncing, also you have think about cases where user syncing 1y of data in a single day.

- Have to keep people on the payroll for future developments.

(You are here thinking only in developer perspective.)

Re: Local-first software (2019)

#210

Post by pvh »

maxhille wrote: post #92
DataDaoDe wrote: post #29

Yes a thousand percent! I'm working on this too. I'm sick of everyone trying to come up with a use case to get all my data in everyone's cloud so I have to pay a subscription fee to just make things work. I'm working on a fitness tracking app right now that will use the sublime model - just buy it, get updates for X years, sync with all your devices and use it forever. If you want updates after X years buy the newest…

How do you plan to do the syncing without some sort of cloud infrastructure?

Ideally, you would use existing commodity infrastructure but we have found none of it is really super fit for our purposes. Failing that, we have been developing an approach to low-maintenance reusable infrastructure. For now, I would advise running your own but positioning yourself to take advantage of commodity systems as they emerge.
Post reply on HN