Earlier quoted context omitted.
Might have something to do with the fact that McNucle is a freaking terrible name.
no, most end users did not understand (or cared about) the data ownership problem back then. Times have changed.
That name though...
Local-first software: you own your data, in spite of the cloud
51–60 of 243 posts
Re: Local-first software: you own your data, in spite of the cloud
#52Resilio sync is a perfect example of such app. It's basically a P2P based Dropbox with no accounts, full end-to-end encryption and no folder size limits. It's not open source, but it can work without a central server if you need it to. It's also amazingly simple to set up, much simpler than sync thing.
i used resilio for years and thought the same about syncthing until i switched last year and now I actually prefer how syncthing is setup.
if you pay for resilio there is an option to add all your folders in one go but on some computers I don't want to add all of them anyway so that's not much use to me. with the free version you have to manually add folders one by one but to do that you need the key which means you need to copy them to a text file and add them on another computer.
with syncthing, it will detect other syncthing devices on your home network so you just have to add the ones you want then accept the request from another device.
once that is done you select which folders the device has access to and then a notification will show up on said device asking you to connect. so basically no fiddling with keys or having to store them somewhere secure
(this is all presuming i was using resilio correctly, maybe there was an easier way I was not aware of)
Re: Local-first software: you own your data, in spite of the cloud
#53Re: Local-first software: you own your data, in spite of the cloud
#54There is a longer version of this article here: https://www.inkandswitch.com/local-first.html
Re: Local-first software: you own your data, in spite of the cloud
#55When I select software these are among the list of things I am looking for generally: - file formats that won’t lock you in or are even openly hackable (allows you to automate things) - no clouds that will break the software once it is gone - local storage with custom syncing or backup options - strictly no weird data collection or “We own the rights to your data”-Type of terms So if I get the slightest feeling of a…
While I fully agree with your selection criteria, please consider the other side of the equation, because engineering (and the world) is all about compromises. I am the author of a SaaS app ( https://partsbox.io/ ). I export in open formats (JSON), there is no lock-in, it's easy to get all of your data at any time. But the app is online and will remain so. Why? Economics. Maintaining a self-hosted solution is an enor…
> The best part is that many people think that an on-premises version should be less expensive than the online version, and come without a subscription.
Which makes sense IMHO, provided they are not expecting any updates to their on-prem installation. It can just be a fork of your current codebase with no new features or warranty. Maybe you can include some terms for critical security updates but that is about it.
Re: Local-first software: you own your data, in spite of the cloud
#56As far as possible, I'm following a local-first methodology for a recipe search, meal planner, and shopping list application:
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 those updates in near-real-time.
If either of us lose connectivity, we can continue to use the app, and when data access is restored, those changes are synced with the shared session (with automatic conflict resolution). All data in the shared session is encrypted, and the collaboration link contains the keys.
Much of this functionality is thanks to peer-base, which is an experimental but extremely useful library:
https://github.com/peer-base/peer-base
A side-benefit of this approach is that all user data can be stored locally (in browser localStorage) - there are no cookies used in communication between the app and server.
Re: Local-first software: you own your data, in spite of the cloud
#57>It should be fast. We don’t want to make round-trips to a server to interact with the application. The cloud apps are not slow only because of moving data, but there is also a problem that an average server is fast(16cores CPU + 64GB RAM), but If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster. Basically people…
> If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster.
This is overly simplistic. You're pretending that cores/memory are "allocated" to users, but really, a user might only make a few tens of requests, and the server only needs to spend a second or two servicing each request. On a server with only 100 users, it could very well be the case that a user has all 16 cores + 64gb available at the time they make a request. Also, as another commenter pointed out, you could use a large chunk of that memory for shared resources, and then each request might only need a few mb of memory to service a request.
Re: Local-first software: you own your data, in spite of the cloud
#58Earlier quoted context omitted.
While I fully agree with your selection criteria, please consider the other side of the equation, because engineering (and the world) is all about compromises. I am the author of a SaaS app ( https://partsbox.io/ ). I export in open formats (JSON), there is no lock-in, it's easy to get all of your data at any time. But the app is online and will remain so. Why? Economics. Maintaining a self-hosted solution is an enor…
> The best part is that many people think that an on-premises version should be less expensive than the online version, and come without a subscription. Which makes sense IMHO, provided they are not expecting any updates to their on-prem installation. It can just be a fork of your current codebase with no new features or warranty. Maybe you can include some terms for critical security updates but that is about it.
But that, unfortunately, is entirely unrealistic. When I discover critical bugs, I can't leave users out in the cold.
I believe that the whole concept of "software without support" is fundamentally flawed.
Re: Local-first software: you own your data, in spite of the cloud
#59>It should be fast. We don’t want to make round-trips to a server to interact with the application. The cloud apps are not slow only because of moving data, but there is also a problem that an average server is fast(16cores CPU + 64GB RAM), but If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster. Basically people…
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 will use something you don't like for 5-10 hours each day to do your work?
Only answer I can see that electron is not an issue here.
Re: Local-first software: you own your data, in spite of the cloud
#60>It should be fast. We don’t want to make round-trips to a server to interact with the application. The cloud apps are not slow only because of moving data, but there is also a problem that an average server is fast(16cores CPU + 64GB RAM), but If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster. Basically people…
> If it's used by let's say 100users, It means one user has only 0.16core + 0.64GB memory. So an average laptop(4cores/4GB) or phone(4cores/1GB) is way faster. This is overly simplistic. You're pretending that cores/memory are "allocated" to users, but really, a user might only make a few tens of requests, and the server only needs to spend a second or two servicing each request. On a server with only 100 users, it c…
I agree. It highly depends on the use-case.