Live data from Hacker News

Local-first software: you own your data, in spite of the cloud

blog.acolyer.org

101–110 of 243 posts

Re: Local-first software: you own your data, in spite of the cloud

#101
post #70
post #63

Earlier quoted context omitted.

Agreed. But if a user agrees to be left "out in the cold", you should allow him to. Given that it is not very costly for you to prepare your software for on-prem, it maybe a win-win for all the parties involved.

> Given that it is not very costly for you to prepare your software for on-prem I have been asserting exactly the opposite in this thread.

Assuming you are not providing any updates (not even security critical ones for argument's sake), you only need to package and add documentation for an on-prem installation. Why is it so costly?

Re: Local-first software: you own your data, in spite of the cloud

#102
I've been working on SPA's that launch from keybase.io public folders and can talk to my local KBFS storage, which is encrypted locally and then and distributed to the cloud. This way I can access my own data anywhere I have keybase installed, using apps I don't need a server to host. It's still all just prototype work for myself, but im excited about owning my own data while still having the safety of cloud distribution combined with the security of local encryption.

Re: Local-first software: you own your data, in spite of the cloud

#103
Our software Construct 3 (https://editor.construct.net/) I think meets most of these points. It runs offline, and we never have access to the users project files. You can save/load locally, and it runs in the browser. Game project files are zips with JSON + raw asset files. No syncing with the server needed so it is fast, and a design mistake that is severely hampering some of our competitors!

I'm not entirely sure how supporting collaboration in real time belongs on this list. Seems like a nice to have that isn't really related to the rest of the list.

Re: Local-first software: you own your data, in spite of the cloud

#104
post #93
post #56

As far as possible, I'm following a local-first methodology for a recipe search, meal planner, and shopping list application: https://www.reciperadar.com There's a 'collaboration' mode which allows peer-to-peer sharing of a session via CRDTs over IPFS. My partner and I select our meals for the week, and then when one of us is doing the shopping, we can mark ingredients as found -- the other person's view reflects tho…

Cool project! Some suggestions: * Allow "patchcables" with different hooks, so for example a different recipe database, or a different language. * Allow groups of ingredients, ie. tag ingredients. For example, if I say I don't want meat, I still get shrimp suggested which might be what I want but it might also not be what I want. * In line with that, allow to specify allergens or blacklist ingredients (in line with d…

Thanks for using it and providing feedback; it's great to hear you've considered similar applications :)

I really like the idea of being able to patch in an alternative recipe dataset. It strikes me that a default-offline, peer-to-peer search engine (i.e. 'distributed lunr.js') is technically feasible (even if no such codebase exists at the moment, afaik). That would, in my opinion, be the ideal pluggable data source in terms of achieving local-first behaviour, resilience, and privacy, with the option of fully offline & single-device operation.

Shorter-term, once the application's backend code is open source, at least it'll be easier for anyone to run their own instance (it's a containerized set of Kubernetes microservices, FWIW).

You're completely correct about ingredient searching and handling. There's a lot to do here. One of the upcoming 'large' work items on the roadmap is to build a true knowledge graph over recipes and ingredients, with relationships (like nutritional information, substitutions and pairings) between entities. I've started exploring this space, but it's going to take a while, and I want to do it carefully and thoughtfully.

Allergies in particular are a sensitive topic and I don't want to give users any false sense of safety -- that said, it's also a very valid use case which the app should cater for.

Almost every time we do our shopping here we discuss the pricing and stock-keeping problem you mention. In many ways the application would work best if it already knew what you have in the kitchen (and how fresh your ingredients are).

There may be some use for image recognition and OCR of receipts -- or, perhaps better, at point-of-sale in stores. Keeping the application client-first is a goal, and feasible I believe - tesseract.js exists today, for example.

The project roadmap (and changelogs) will be published on the site in the not-too-distant future, and I'd like to use an issue tracker to track bugs and rank feature requests. I'll keep a note to include items from your feedback and you'll get a credit against them once implemented. Cheers!

Re: Local-first software: you own your data, in spite of the cloud

#105
post #89

https://github.com/syncthing/syncthing Syncthing solves a large part of syncing data between devices using your own VPS, server(s), etc. If your VPS provider goes out of business, you can then just fire up a new VPS and hook it back up to your local machine(s).

Cryptomator [1]. Cross-platform, allows you to encrypt your data in the cloud, and access it transparently. Thing is, like Syncthing, it lacks a collaborative feature. Nextcloud has it, but only if you have the Nextcloud accessible (I want to host only on LAN). Something like IPFS (or Tor) is a solution to such problem. [1] https://cryptomator.org/

> it lacks a collaborative feature

It does not, you can share folders with anyone you want without them even needing an account.

Re: Local-first software: you own your data, in spite of the cloud

#106
So I got fed up with current image hosting solutions the other day, because I realized free image hosting is unsustainable and Imgur has turned into a social network, which is the opposite of what I want.

So, I figured I'd create my own paid one, and am working on https://imgz.org. However, I want to add a free tier for people who are willing to host their own images, and was thinking of writing a daemon that would run on the user's computer and store all their images on a directory there. It would have to be mostly-on, but not always-on, since I'm going to be using a caching CDN.

Is this a good idea? I don't know how many people would know how/want to run this, but it feels empowering from a data ownership perspective. What does everyone here think?

Re: Local-first software: you own your data, in spite of the cloud

#107
post #42

Earlier quoted context omitted.

That's not a fair comparison since most of the memory usage is just loading the app in to memory and then everyone is sharing the same app already loaded. Web apps don't have to be nearly as slow as they are. It's just that it's easier to make a slow app than a fast one. Also desktop apps are becoming super slow and bloated now thanks to electron.

> Also desktop apps are becoming super slow and bloated now thanks to electron. I can't quite get this point. From my perspective software engineers love/adore electron applications. Look at VScode as the example: - electron based javascript application - telemetry included - proprietary build with "open core" It is literally the most popular code editor right now (p.s. I don't use it). Why as a tech savvy user you w…

VSCode is proof that an Electron app can be performant, but that's not the rule, and most people writing Electron apps aren't as talented as the VSCode team.

Also, there's an expectation that an IDE will be somewhat heavyweight. I don't mind if VSCode or IntelliJ grabs a few gigs or RAM, because I live inside those applications and depend on the features they provide.

What I don't want or need is Yet Another Electron Based Markdown Editor that gobbles up half my laptop's memory so that I can edit a hundred line text document.

Re: Local-first software: you own your data, in spite of the cloud

#108

So I got fed up with current image hosting solutions the other day, because I realized free image hosting is unsustainable and Imgur has turned into a social network, which is the opposite of what I want. So, I figured I'd create my own paid one, and am working on https://imgz.org . However, I want to add a free tier for people who are willing to host their own images, and was thinking of writing a daemon that would…

Sounds like IPFS and pinning.

Re: Local-first software: you own your data, in spite of the cloud

#109

So I got fed up with current image hosting solutions the other day, because I realized free image hosting is unsustainable and Imgur has turned into a social network, which is the opposite of what I want. So, I figured I'd create my own paid one, and am working on https://imgz.org . However, I want to add a free tier for people who are willing to host their own images, and was thinking of writing a daemon that would…

Sounds like IPFS and pinning.

Kind of, except it will work.

Re: Local-first software: you own your data, in spite of the cloud

#110
post #56

As far as possible, I'm following a local-first methodology for a recipe search, meal planner, and shopping list application: https://www.reciperadar.com There's a 'collaboration' mode which allows peer-to-peer sharing of a session via CRDTs over IPFS. My partner and I select our meals for the week, and then when one of us is doing the shopping, we can mark ingredients as found -- the other person's view reflects tho…

That is a very cool web app. I really like being able to type in several ingredients and get relevant recipes. I have a nutrient tracking oriented cooking web site (cookingspace.com) that I basically haven’t modified in ten years - seeing your site maybe will motivate me to give my own some attention.
Post reply on HN