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

211–220 of 308 posts

Re: Local-first software (2019)

#211

Post by replwoacause »

mazzystar wrote: post #208

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 mod…

Couldn’t you have just restricted the app to being installable on only certain iPhone models?

Re: Local-first software (2019)

#213

Post by dtkav »

trinsic2 wrote: post #135
dtkav wrote: post #61

We need a term for a viable business model to pair with local-first tech. I've been working on Relay [0] (realtime multiplayer for Obsidian) and we're trying to follow tailscale's approach by separating out the compute/document sync from our auth control plane. This means thats users still subscribe to our service (and help fund development) and do authn/authz through our service, but we can keep their data entirely…

Are you requiring a google account for file/folder based auth on a per user bases for a vault? Not to keen on using a 3rd party for this kind of thing.

For our free/individual plan we do use OAuth2 providers (currently only Google is enabled, but considering others), and can support other methods for larger teams (like oidc).

Originally the idea was to keep everything within the Obsidian UI so things like username/password didn't make sense (no password managers in Obsidian).

We initiate the OAuth2 login flow from within Obsidian. I guess we could add an extra click that takes you to our website first and then add support more auth methods from there. I don't really want it to feel like a web app though.

I'd love to hear your take. Which login method do you think is both simple and could be coherently used within Obsidian on all platforms?

Re: Local-first software (2019)

#214

Post by satvikpendem »

bigfatkitten wrote: post #171
satvikpendem wrote: post #140

Earlier quoted context omitted.

But who said anything about AI? Lots of local-first apps have nor need any AI whatsoever. And by the way, Topaz Labs has good offerings for editing photos and videos with AI that run locally, works great for many use cases (although it's not fully generative like Veo etc, more like upscaling and denoising, which does use generative AI but not like the former).

Most cloud apps have no need for AI either, but companies are pushing it anyway for bullshit marketing reasons, similar to what they did with blockchain a decade ago.

Sure, that's unrelated to my point however, it's a non sequitur.

Re: Local-first software (2019)

#215

Post by satvikpendem »

echelon wrote: post #192
satvikpendem wrote: post #153

Earlier quoted context omitted.

Yes, that is true, but again for apps like a fitness tracker, it is not "content" based. Sure, it might have some AI in the form of chatbots to ask what your diet plan should be based on your current progress, but that's not what you're talking about. In my experience, most local-first apps are like this fitness tracker, utility tools, rather than a means to view content, like TikTok.

The vast majority of apps, or at least data consumption, will not fit the shape of "fitness tracker". Budgeting, emails [1], workout routines - those will fall into a non-generative bucket of applications. I still purport that in the future, most applications and screen time will fall into a generative AI bucket: creating media, writing code, watching videos, playing games, searching for information, etc. I wouldn't…

> or at least data consumption

Good thing I'm not talking about data consumption apps then, as I mentioned in my comment above. Local-first apps specifically are not amenable to data consumption purposes so while you are right on the generative AI part, it's unrelated to the topic of this post.

Re: Local-first software (2019)

#216

Post by fud101 »

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…

Bro who wants your pointless fitness data? Not even you care that much for that. Just use a notepad ffs.

Re: Local-first software (2019)

#218

Post by wim »

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…

A backend can be part of the functionality though, such as for real-time collaboration and syncing. But you can have ownership and longevity guarantees for both the data and the service as long as you can eject [1] from the cloud and switch to self-host or back at any time, which is what we do for our notes/tasks IDE

[1] https://thymer.com/local-first-ejectable

Re: Local-first software (2019)

#219

Post by trinsic2 »

samwillis wrote: post #40

There is now a great annual Local-first Software conference in Berlin ( https://www.localfirstconf.com/ ) organised by Ink and Switch, and it's spawned a spin out Sync Conf this November in SF ( https://syncconf.dev/ ) There was a great panel discussion this year from a number of the co-authors of the the paper linked, discussing what is Local-first software in the context of dev tools and what they have learnt since…

Thanks for the info. Didn't know there were sync conferences.

Re: Local-first software (2019)

#220

Post by necovek »

monkeyelite wrote: post #169
swsieber wrote: post #165

Earlier quoted context omitted.

I agree that not every app needs it's own sync engine, but I disagree with your framing that the file system is the universal way to embrace local first. I have two reasons. First is that yeah, local first, but I also want concurrency. If it's just local first, you're right, any old sync will do. But I want more than that. I want to not have to think (a la dropbox, being slick). I want my wife and I to be able to mak…

But this problem isn't going to be solved by every app making its own sync system. Even if there is a magic library you can adopt that does pretty good, then everyone having their own completely independent hosting solution and sync schedule. If files are insufficient, what data-structure would make modular sync possible for multiple applications in an OS? And I’m not suggesting one doesn’t exist, I’m challenging to…

I agree that files solve some rudimentary cases, but they do not even allow simple conflict resolution. Eg. compressed files, including container formats like OpenOffice (text files in a ZIP archive IIRC), might be simple to apply changes from two sides if they are in distant parts, but syncing full files simply barfs.

Note that this does not even need two users: I hit this problem with a desktop and laptop and self-hosted NextCloud myself.

In general, a filesystem that actually stored both raw data (to fail-over to), but also a per-format event log, and maybe even app specific events (imagine a PNG changes, we could have any change recorded as raw bytes, generic bitmap image operation like "modify pixels at x,y to ..." and app-specific log like "gimp: apply sharpen filter on polygon area ...").

This would allow the other side to attempt to do the smartest sync it has (if it has a compatible version of gimp, it could decide to apply the filter, otherwise fall back to raw pixel changes if no conflicts, and then fall back to full file contents reconciliation).

Just like MIME handlers get registered, if file systems provided such change logs, some could have very advanced sync systems with this support from "filesystems".

Post reply on HN