Ask HN: Decentralized Auth for Information Exchange?
3 コメント
As an entrepreneur, this feels like a classic case of over-engineering for a problem you haven't earned yet.
Decentralized auth is a fascinating technical rabbit hole, but it introduces a massive friction point for your first 1,000 users. For a new, unproven project, credibility is your biggest bottleneck, not decentralized storage.
By building your own complex auth/privacy stack, you are asking users to trust you to get the crypto right—which is a huge leap of faith.
A more pragmatic approach: Outsource the trust. > Use 'Sign in with Google/Apple/GitHub.' You leverage their multi-billion dollar security infrastructure and their existing trust relationship with the user. It provides immediate convenience (one-click onboarding) and shifts the perceived privacy liability to a known entity.
Don't spend your innovation tokens on auth. Spend them on the core value of your information exchange. You can always 'decentralize' the back-end later once you have enough users to actually make it matter.
Decentralized auth is a fascinating technical rabbit hole, but it introduces a massive friction point for your first 1,000 users. For a new, unproven project, credibility is your biggest bottleneck, not decentralized storage.
By building your own complex auth/privacy stack, you are asking users to trust you to get the crypto right—which is a huge leap of faith.
A more pragmatic approach: Outsource the trust. > Use 'Sign in with Google/Apple/GitHub.' You leverage their multi-billion dollar security infrastructure and their existing trust relationship with the user. It provides immediate convenience (one-click onboarding) and shifts the perceived privacy liability to a known entity.
Don't spend your innovation tokens on auth. Spend them on the core value of your information exchange. You can always 'decentralize' the back-end later once you have enough users to actually make it matter.
Yeah I think decentralization will be a stretch, especially at the beginning.
About the login, SSO is nice and it will probably be an option, but I heavily prefer good old email+password. It might be trickier, haven't explored SSO before.
The auth/central server will be open source of course, and I'm hoping I could get feedback/auditing that way if anything's wrong (even tho I feel like the process is simple with encryption libs and knowledge). At first it will be heavily experimental and will hold just dummy data and then gradually go from there if it works out.
About the login, SSO is nice and it will probably be an option, but I heavily prefer good old email+password. It might be trickier, haven't explored SSO before.
The auth/central server will be open source of course, and I'm hoping I could get feedback/auditing that way if anything's wrong (even tho I feel like the process is simple with encryption libs and knowledge). At first it will be heavily experimental and will hold just dummy data and then gradually go from there if it works out.
Single Sign-On (SSO) is not complicated, and platforms that provide services all have detailed tutorials.
I don't think obtaining authentication data is useful; it's better to use it for collecting data on functional experiences.
I don't think obtaining authentication data is useful; it's better to use it for collecting data on functional experiences.
As the project is about spinning your own server (media server), I want to have a smoother way to have a simple account system where the user just enters an email and a password, and get the server/ip list (everything from there is done on the actual server). For example, a user could be invited to 2 servers, and would see them in the same page, which makes things more straight-forward and a lot easier.
Now, I thought a lot about it, and mostly came down to the conclusion that centralizing it is the most sane option. The data itself comes down to: email, encrypted password, encrypted IP(s) list (via key exchanges).Is there any-way to do it decentralized? I searched, even asked LLMs, but nothing felt solid (best was a Nostr suggestion) but such method would make emails, password resets painful or almost impossible. I don't know a lot regarding this topic so its quite the challenge.
What's the point/why not just use URL? convenience. I know, but it SUCKS having to give a parent a URL, even with some techy friends it takes a bit communicating it. I want to eliminate as much friction as possible. Also, if centralized, this has the ability that users don't need to buy a domain, setup lets encrypt and all that which costs money and time (especially for simple/new selfhosters); its a lot nicer and smoother and in a way provide better privacy out-of-the-box.
Note, This project doesn't even exist yet. But I'm pursuing quite soon. I also only took 1 encryption course back in college days, while I understood and was good at it, I still need to audit/verify my method. It basically is: 1. hash the password+salt in a different algorithm, save the private key from it and send the public key to the central server 2. (media server owner wants to invite) the media server checks for a public key, encrypts the message containing all the details (IP, status, ports etc), and sends the encrypted message to the central server. 3. The client later checks, if there's a new message, it decrypts the ip/info from the server and connect.
Every device can login in this way and grab server list info securely. There's gonna be some sort of way to "quick connect" on TVs and such, and change passwords, but I don't want to get ahead of myself for now. I don't think the IP/server-info encryption suffers from any major things, but that's the general core principle. I maybe (probably?) have missed something.
The only issues I can maybe think of, is a "centralized" URL/domain would be showing up all the time instead of the owner. Note, it would be designed in a way that would allow you to instead send them to your own URL/domain and such.
Anyways, let me know what would be best. btw I'm not rich but such simple "auth" server would probably cost like $5/m + 2x5/m for redundancies, shouldn't be too bad.