HN user
[ my public key: https://keybase.io/muji_tmpfs; my proof: https://keybase.io/muji_tmpfs/sigs/_sKVH2K4C9t3e4F2lnSf5ocsdtndQaKupyyXtQxM7Xw ]
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.
You should choose different language.
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.
I had an almost identical experience about 20 years ago too. I imagine they are still just as bad.
I think it is highly likely the wealth of the PayPal mafia founders is partly derived from this theft.
You should look at the native messaging API, it does what you need for bi-ditectional communication between extension and local app.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
We care about this porblem and are actively working on it, like the OP we also settled on shamirs secret sharing with a time lock mechanism.
However, there is still the issue of the service provider going offline or out of business which we don't have a solution for yet.
We have started with a good password manager and will be adding digital inheritance/social recovery soon! [0]
Take a look, thoughts and feedback welcome.
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.
Agreed, more than time to revisit. I have stopped using npm entirely because of their cavalier attitude to security.
Code signing could and should have been implemented years ago. It's not a panacea but just part of defense in depth.
I can't trust npm whatsoever to do the right thing at this point.
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.
Hey, I went to take a look at Obscura and I like the ideas but I can't find the source code.
You are making some bold claims but without the source I can't verify those claims.
Any plans to open-source it?
This is nonsense. By your logic me and the majority of people using Signal are criminals.
As the other commenter mentioned please provide proof for these hyperbolic claims.
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.
[1] https://docs.rs/sqlite/latest/sqlite/ [2]: https://docs.rs/postgres/latest/postgres/
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.
Wish the Dioxus team a lot of success!
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
Please try our solution[1]
It's truly local first and will work fine in an airgapped situation.
It's also designed to be self-hostable[2], is open source [3] and the API is well documented[4].
[1] https://saveoursecrets.com/ [2] https://saveoursecrets.com/docs/cli/self-hosting/ [3] https://github.com/saveoursecrets/sdk [4] https://docs.rs/sos-sdk/latest/sos_sdk/
Yes, a screenshot would be good to get a visual on this.
I have done a simple shell using Rustyline and Clap and this could be something I might be interested in but it's hard to say without a visual idea, asccinema would be perfect!
I suspect that it's perfectly valid to name a column "from" or any other SQL keyword so allowing a trailing comma would make the grammar ambiguous.
Personally I agree with the sentiment, I find it annoying to have to juggle the commas on the last column name but I think there is likely a valid reason to do with making lexing easier to reason about.
I decided to try this recently on my first browser extension and so far the experience has been good.
Sometimes the websocket connection for the hot reload dies but apart from that I've been quite impressed.
Just abstracting away the different manifest files and using the webextension polyfill is all I need and it works.
The only shame is how abysmal the experience is in Firefox I find myself preferring to debug the extension in Chrome as getting to the debugger in Firefox is such a pain. And I use Firefox as my primary browser so it's not because of a Chrome bias I say this. The Firefox folks could really improve the UX here.
We have been working on a open-source, cross-platform alternative called SOS[1]. The source code is on github[2] and includes a self-hostable server for syncing. It is well documented[3] for those that want go build on top of it.
Would love your feedback if you can take it for a spin!
[1] https://saveoursecrets.com/ [2] https://github.com/saveoursecrets/sdk [3] https://docs.rs/sos-sdk/latest/sos_sdk/
I welcome this and look forward to seeing the improvements. At the moment I am running some TSS code compiled down to WASM. The last time I executed DKG and signing Webkit took ~25s, Chrome took about ~39s and Firefox took nearly 4 minutes so there is clearly lots of room for WASM optimization in Firefox!
At a basic level Flutter renders the entire widget tree and caches components that don't need to re-render rather than applying a diff of changes to the DOM.
But it's really the Flutter/Dart API and widgets that make it much easier to work with, if I need to load some data asynchronously I use a `FutureBuilder`, if I need a stream of events I can use `StreamBuilder` etc. Compared to Reacts state, hooks, memo, effects etc. you end up with code that is far easier to reason about what is rendering when and why.
Oh and the real killer feature is Flutters hot reload experience, it's easily the best DX I've seen for GUI work.
As another comment mentioned it really is like night and day. I recommend giving it a try.
I have been using this to build an app[0] for the last couple of years and I want to say that it has been a pleasure to use, there are some wrinkles but overall I have been very happy with the experience.
Upgrading from v1 to v2 was not too difficult and v2 is a significant upgrade with lots of useful features, massively improved codegen experience and support for tokio async were the big gamechangers for me.
Writing all the app business logic in Rust and using Dart as the front-end works out really well. I know Flutter/Dart doesn't get much love here on HN but in my opinion I think it's much easier to reason about than a system like React which I think is the wrong level of abstraction compared to Flutter's render the entire widget tree approach.
Massive thanks to @fzyzcjy for all the work on FRB, great job!
As an Indonesian resident and a long time DDG user this is immensely frustrating.
It seems to me that internet censorship is becoming more and more pervasive globally and whilst there can be legitimate reasons (eg: CSAM) blocking a search engine like DDG is a massive over-reach. Unfortunately, most Indonesians won't notice as they happily let Google, Meta et al track everything and everyone and are unlikely to be using DDG.
Think about trying to get customer service from any company now, we all end up talking to AI bots that don't actually help at all. No wonder the public perception is bad, our experience of AI is often based on these automated services which actually make our lives more frustrating.