What about using Nostr relays to also back up your data passwords? I built a library called Tablinum around this idea. Local first but backed up to Nostr relays using NIP-59 gift wrapped events.
This looks like something I've been looking for! Excited to give it a try! I don't even use a password manager because of the things you've seemed to work around here. It's been painful.
Honestly, though, I'm most intrigued by your P2P solution. I've built a couple of web apps as custom html elements that use indexedDB for storage and I've been trying to figure out the sweet spot for syncing the data between apps. I think this nostr relay hits the mark as something people can feel comfortable not self hosting, while power users can host their own solution. Seems like a great solution, to me! Any advice as to some footguns with the approach? I'm very interested in giving it a try myself[0], so any notes you think would prevent some re-work would be really appreciated!
[0] as a public domain/oss-licensed module, if there's a reasonable method of packaging it as a standalone library
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.
Thanks for sharing! And I fully agree with you. The convenience that cloud providers bring is hard to match sometimes, but the tools exist to make it happen.
Thank you! I'm a firm believer of this as well, especially with how things almost always turn out for venture backed companies. I feel like there's a push towards local-first and self-hosted solutions these days, and rightfully so.
> TL;DR: I dislike private-equity and venture funded companies messing with our security, so I created my own Password Manager which is local-first, free, open source and as transparent as it gets.
I do too! And I appreciate your transparency about the vibe coding. But nowhere in the repository that I've found so far do you say who is writing this. For something like a password manager, I kind of need to know who's responsible for it, and who's reviewing the LLM source code, what they've done before, what their business model is, etc.
Fair enough. I like staying pseudonymous on the internet, but I also understand where you're coming from.
My name is Doug, based in Toronto, Canada. I've been a software engineer for over 10 years, working in various startups that handle very sensitive data (fintech, health tech, legal tech.) I've had the opportunity to build security-heavy software and directly handled sensitive info like SIN, bank details, patient histories etc.
Business model: This is essentially a passion project for me that I intend to keep working on - for usage within my family and the OSS community. This version of the app is always going to be free and open source. In the future if this were to ever take off and I now want to earn from it, I would probably do a business version with cloud storage (with self-host option)
The goal is offering an alternative that doesn't enshittify over time, secure, fully sovereign and convenient.
if you mean why I didn't choose a lib like automerge, yjs and instead handrolled it - that's because these libs are geared towards plaintext.
Bramble's sync is built around its own encrypted vault instead. When two devices conflict it just compares timestamps on the encrypted entries and keeps the newer one as-is, without ever unwrapping your per-entry keys to merge. Nothing off the shelf did that against my vault format, so the core is custom. It's a pretty simple implementation tbh
This deserves a bit more explanation (sorry, on the phone, can't look at the code in the next couple of days).
So, if I change the password and update it on the phone, then add a web site on the desktop, when they sync, the desktop entry will overwrite the new password?
Hope it's not that simple.
Last writer wins may be sufficient for some folks but for me, any potential data loss in an app like this is a deal breaker. I hope you'll consider some kind of merge conflict detection and surfacing that to the user. Even keeping a list of deleted items and showing that can be a good start.
Most sync engines are targeted towards being fast. I suppose for a PM you'd want one that's very resource efficienct. I'm just spitballing here, I'm not OP
It's a hard feature to get right, it is complex and networking across the internet is unreliable. I am an advocate for local-first and P2P, but I would like to see contributions to existing libraries rather then weaker implementations
What about using Nostr relays to also back up your data passwords? I built a library called Tablinum around this idea. Local first but backed up to Nostr relays using NIP-59 gift wrapped events.
https://tablinum.dev
Honestly, though, I'm most intrigued by your P2P solution. I've built a couple of web apps as custom html elements that use indexedDB for storage and I've been trying to figure out the sweet spot for syncing the data between apps. I think this nostr relay hits the mark as something people can feel comfortable not self hosting, while power users can host their own solution. Seems like a great solution, to me! Any advice as to some footguns with the approach? I'm very interested in giving it a try myself[0], so any notes you think would prevent some re-work would be really appreciated!
[0] as a public domain/oss-licensed module, if there's a reasonable method of packaging it as a standalone library
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:
https://saveoursecrets.com/
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'll check out your website and see what's up!
I do too! And I appreciate your transparency about the vibe coding. But nowhere in the repository that I've found so far do you say who is writing this. For something like a password manager, I kind of need to know who's responsible for it, and who's reviewing the LLM source code, what they've done before, what their business model is, etc.
Can you share?
My name is Doug, based in Toronto, Canada. I've been a software engineer for over 10 years, working in various startups that handle very sensitive data (fintech, health tech, legal tech.) I've had the opportunity to build security-heavy software and directly handled sensitive info like SIN, bank details, patient histories etc.
Business model: This is essentially a passion project for me that I intend to keep working on - for usage within my family and the OSS community. This version of the app is always going to be free and open source. In the future if this were to ever take off and I now want to earn from it, I would probably do a business version with cloud storage (with self-host option)
The goal is offering an alternative that doesn't enshittify over time, secure, fully sovereign and convenient.
Give it a try and if you find anything, I'll prioritize fixing it. I'm really keen on getting a top-notch autofill engine.
Bramble's sync is built around its own encrypted vault instead. When two devices conflict it just compares timestamps on the encrypted entries and keeps the newer one as-is, without ever unwrapping your per-entry keys to merge. Nothing off the shelf did that against my vault format, so the core is custom. It's a pretty simple implementation tbh