You have completely misused and re-purposed this term. The common interpretation is that the software will continue to function without an internet connection which is not the case for your product.
I think local-first password managers are the way forward. Big tech companies already have way too much power and having them mediate our most important data is a bad precedent to set.
I like that you made this P2P, I designed one that sits on top of sqlite and is 100% local first but is not P2P, take a look if you are interested in some prior art in this space:
I decided to go with native apps all the way, Rust backend and Flutter front-end but kind of regret it now with how the Play/App stores are such a hassle to work with.
This is a very cool experiment, even if the board doesn't end up being that practical (the antenna hack is going to be an ongoing issue I think) your documentation looks great at a glance!
I am totally sold on local first apps. I think the recent enshitification of many services (which is also inevitable for the new wave of AI services) plus the inherent privacy risks with allowing third parties access to our personal data is no longer a trade-off I am willing to make.
I set up a little Pi NAS and have moved all my git repositories there thanks to gitea (I still mirror to github for community interaction) and am gradually migrating everything to be stored locally with encrypted cloud backups.
I've also been working on a local-first, open-source, eventually consistent password manager[0] (using last write wins) for the last 3 years as I can't think of anything more important that we should have control over.
It will be hard for local-first to become more commonplace as SaaS and cloud has become so entrenched but I will keep forging towards a future where we take back ownership of our personal data.
I disagree, I think most of these opinions I see about CSS are from people that haven't taken the time to learn it and particularly to understand the cascade.
Many years ago I did a very deep dive into the CSS specs as I was researching for a new implementation and it struck me as well designed for its purpose of separating style from the semantics of markup.
I have used this as well as many of the other lower-level db drivers (which don't check your SQL at compile time) and I can say I much prefer the latter.
My issues with SQLx when I first tried it were that it was really awkward (nigh impossible) to abstract away the underlying DB backend, I expect those issues are fixed now but for some simple apps it's nice to be able to start with SQLite and then switch out with postgres.
Then I wanted to dockerize an SQLx app at one point and it all becomes a hassle as you need postgres running at compile time and trying to integrate with docker compose was a real chore.
Now I don't use SQLx at all. I recommend other libraries like sqlite[1] or postgres[2] instead.
SQLx is a nice idea but too cumbersome in my experience.
Interesting as I was researching this recently and certainly not impressed with the quality of the Readability implementations in various languages. Although Readability.js was clearly the best, it being Javascript didn't suit my project.
In the end I found the python trifatura library to extract the best quality content with accurate meta data.
You might want to compare your implementation to trifatura to see if there is room for improvement.
This is very interesting, are there any examples of interacting with LLMs? If the queries are compiled and loaded into the database ahead of time the pattern of asking an LLM to generate a query from a natural language request seems difficult because current LLMs aren't going to know your query language yet and compiling each query for each prompt would add unnecessary overhead.
As somebody with a wooden house and the feeling to learn carpentry and spend less time programming I think this is brilliant. Combining minimal design with a hacker and DIY ethos is brilliant. Kudos, bookmarked; hope I can find the time to tinker with the designs.
Good article but a minor nitpick is that port zero is not strictly an invalid port as it's often used to allow the OS to pick an available port at random.
The problem is that the requirements can be vastly different. A collaborative editor is very different to say syncing encrypted blobs. Perhaps there is a one size fits all but I doubt it.
I've been working on sync for the latter use case for a while and CRDTs would definitely be overkill.
Really hope this project succeeds as somebody heavily invested in a Flutter app with a Rust backend Dioxus could be great for us so we will continue to follow closely.
Flutters hot reloading is awesome but some days I feel like it is death by a thousand cuts working with Flutter (so many unresolved bugs) so to have a cross-platform framework that wouldn't require Flutter and Dart would be great.
That's the exact reason it's open source, so it would still be possible to access your data in such an event.
We clearly see things differently but I think using computers to make our lives easier is worthwhile and storing/managing our secrets securely, effectively and conveniently is better managed by software than some ad-hoc setup.
Nitpick, passkeys are not text, they are binary blobs.
I don't have the time to look deeper into it right now as I am quite happy with my current setup but if you do want to make an ascinema recording here is a little tool I wrote to help testing and recording CLIs