So happy to see this! We created ZeroTier for the world this is talking about. :)
/shameless but on-topic plug
Local-first software: you own your data, in spite of the cloud
81–90 of 243 posts
Re: Local-first software: you own your data, in spite of the cloud
#82Earlier 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…
Electron makes it easy to build badly-performing apps. VSCode has put a lot of effort into avoiding this.
Re: Local-first software: you own your data, in spite of the cloud
#83Earlier 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.
Sad about the Electron route. I don't consider it to be "desktop" software. Native toolkits are miles faster than the extremely lazy approach of running an entire new browser instance because someone wanted to write javascript for their "app". It's terrible.
In my opinion it's not all about lazyness.
You have to consider the costs of building an app native for each platform vs a cross platform framework built with javascript. Single javascript code base for all platforms is a lot cheaper.
Re: Local-first software: you own your data, in spite of the cloud
#84>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.
The people who build slow electron apps would have built slow native apps, if they could build one.
Re: Local-first software: you own your data, in spite of the cloud
#85Hi everyone, I've been working on this subject for a few months already ;
Thank you OP, your work is wonderful to read and even though I've spent a few months on the idea already I haven't thought of reusing Dropbox or similar. I think exciting things are about to come :)
I'd like to submit Working Group proposal to the IETF.
Why would we need an RPC for Independent Apps?
Independent Apps are surfacing as being a solution to the lack of control of our own data. oAuth Framework has allowed a more secure web, but even if it makes a difference between an identity provider and a resource host, it does confuse the resource and the service hosts.
Independent Apps should NOT be claimed by a lone company, let's make it something that the web owns.
How would it be structured?
I personally believe there should be multiple subjects treated by the IWA Framework, as one being the qualities of independent apps, and second being how data is accessed. Both of these are currently Topics of Interest for the IETF : https://ietf.org/topics/ - However the way this Working Group would proceed should be discussed and decided by it's members.
Why not submit a single person draft?
I could propose a draft but it wouldn't have the same meaning as if it would be drafted by a Working Group. As individuals, we are motivated by our own agenda and the quality of said draft wouldn't be the same. I'm volunteering, but I'd like to allow other persons to join in as well.
You can join your mails here https://forms.gle/igNdd6rH4MnPK8rb8 , at December 6 I will send the Working Group proposal to the IETF with gathered persons, if accepted I believe it should remain open to anybody to join.
Re: Local-first software: you own your data, in spite of the cloud
#86As 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…
(peer-base maintainer here)
This is really cool!
I found the share link, and just tried it between two Chrome browsers, and it worked great!
Thanks for using peer-base! There's a lot of great work happening with js-libp2p recently that would be awesome to incorporate ... I'm hoping to get active developing on it again in the new year. I've got so many ideas for improvements.
Re: Local-first software: you own your data, in spite of the cloud
#87Just wanted to point out that iTunes has had a local focused set up since inception, using xml format for a library’s database.
That seems to still exist with the introduction of Apple Music. So all library data (play counts, skips, file locations etc) are stored locally, but streaming files are hosted remotely.
Although whether this was by accident or design I have no idea.
Re: Local-first software: you own your data, in spite of the cloud
#88https://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).
there's also resilio sync that gives you the option have the node/folder on your vps be encrypted. hopefully syncthing will add that feature at some point in the future
I have been considering spending more money than I should finding someone on a freelancer site to add the untrusted node / encrypted file transfer but don't give a certain node the key to decrypt the file support, that is the number one missing feature for syncthing for me.
It would unlock scenarios like share your files with me and I'll share files with you and neither of us will know the others files unless your house burns down in which case you can get your files back just by hookin the sync back up with the encryption key pulled from your password manager.
Re: Local-first software: you own your data, in spite of the cloud
#89https://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.
Re: Local-first software: you own your data, in spite of the cloud
#90Earlier quoted context omitted.
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.
I think we as engineers owe our users bug fixes, because we messed up at some point. However new functionality or email/phone support? Well, this is what people are not entitled for.
Well, this is what people are not entitled for.
But they will expect it.