Live data from Hacker News

Local-first software (2019)

inkandswitch.com

71–80 of 308 posts

Re: Local-first software (2019)

#71

Earlier quoted context omitted.

>you're not monetizing via ads Yes, you are. You can find tons of purely local apps that monetize themselves with ads.

Sure you could. I'm not, I don't think its in the spirit of local first. And I wouldn't pay money for that, but if you or someone else wants to build that kind of software - its a free world :)

It’s easy to say you wouldn’t do that, but if it gets to the point where you have an employee helping you out and in a downturn you have to choose between laying them off or pushing an ad to keep paying them one more quarter, you might reconsider.

Re: Local-first software (2019)

#72
Lately, I have been following this approach and going towards local-first software. I like simple softwares with barebone features.

- Password manager: KeyPassXC

- Notes: Logseq

- Analytics: Plausible

- Media: Jeyllyfin

- Uptime kuma

- Finance tracker: Actual Budget etc is too heavy so I built this. https://github.com/neberej/freemycash/

- Search: Whoogle? is kinda dead. Need alternative.

Re: Local-first software (2019)

#73

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 is trying to solve a business problem (I can't trust cloud-providers) with a technical trade-off (avoid centralized architecture).

Whenever it's possible to solve a business problem or political problem with a technical solution, that's usually a strong approach, because those problems are caused by an adversarial entity and the technical solution is to eliminate the adversarial entity's ability to defect.

Encryption is a great example of this if you are going to use a cloud service. Trying to protect your data with privacy policies and bureaucratic rules is a fool's errand because there are too many perverse incentives. The data is valuable, neither the customer nor the government can easily tell if the company is selling it behind their backs, it's also hard to tell if he provider has cheaped out on security until it's too late, etc.

But if it's encrypted on the client device and you can prove with math that the server has no access to the plaintext, you don't have to worry about any of that.

The trouble is sometimes you want the server to process the data and not just store it, and then the technical solution becomes, use your own servers.

Re: Local-first software (2019)

#74

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…

>you're not monetizing via ads Yes, you are. You can find tons of purely local apps that monetize themselves with ads.

> You can find tons of purely local apps tha[t] monetize themselves with a[d]s.

How do they do that without hitting the internet?

Re: Local-first software (2019)

#75
I've been building exactly this with SoundLeaf [0] - an iOS client for the excellent open-source Audiobookshelf server. No data collection, no third-party servers, just your audiobooks syncing directly with your own instance.

The user-friendliness challenge is real though. Setting up Audiobookshelf [1] is more work than "just sign up," but once you have it running, the local-first client becomes much cleaner to build. No user accounts, no subscription billing, no scaling concerns. Simple pricing too: buy once, own forever. No monthly fees to access your own audiobooks.

[0] https://soundleafapp.com

[1] https://github.com/advplyr/audiobookshelf

Re: Local-first software (2019)

#76

Earlier quoted context omitted.

>you're not monetizing via ads Yes, you are. You can find tons of purely local apps that monetize themselves with ads.

> You can find tons of purely local apps tha[t] monetize themselves with a[d]s. How do they do that without hitting the internet?

It's "local first", not "local only".

Re: Local-first software (2019)

#77
Tried to adopt this last month at work, it failed. E.g. the mentioned Automerge, it has poor docs https://automerge.org/docs/reference/library_initialization/... and that left out a lot of question, it seems backend agnostic but have to figure out how to store, how to broadcast ourselves.

Re: Local-first software (2019)

#78
In a world of owning nothing and paying subscriptions for everything, owning your data and using software that is either yours or libre is 'rebellion' to many a service provider.

Its not local-first or some sort of cloud diet trend, it should be the norm.

Re: Local-first software (2019)

#79

Cool to see principles behind this, although I think it’s definitely geared towards the consumer space. Shameless self plug, but related: we’re doing this for industrial assets/industrial data currently (www.sentineldevices.com), where the entire training, analysis and decision-making process happens on customer equipment. We don’t even have any servers they can send data to, our model is explicitly geared on everyth…

It doesn't help that all the SCADA vendors are jumping on the cloud wagon and trying to push us all in that direction. "Run your factory from your smartphone!" Great, now I'm one zero-day away from some script kiddie playing around with my pumps.

Re: Local-first software (2019)

#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 software, there's one hurdle that preventing more wide spread adoption amongst developers, and that is the Web platform.

The Web platform lacks building blocks for distributing hashed and/or signed software that isn't tied to origins. In other words, it's hard to decouple web-apps from the same-origin model which requires you set up a domain and serve requests dynamically.

Service Workers and PWAs do help a bit in terms of building offline experiences, but if you want users to download once, and upgrade when they want (and internet is available), you can't use the Web. So you end up breaking out of the browser, and start using Web technologies outside of the browser with better OS functionality, like Electron, React Native, Tauri et al (the https://userandagents.com/ community is doing some cool experiments in this space).

Post reply on HN