|
|
|
|
|
by mrsssnake
2 days ago
|
|
Here is another, not so new, idea: Username is your public key, password is your private key. So we get end to end encryption and account ownership out of the box. Something similar to how .onion addresses work.
Needing easy to remember addresses? Build aliases on top of that. Needing server-side automation? Handle trusted server your private key. Also, almost everyone carry a 24/7 powered and Internet connected device in their pockets. The Internet - network that allows globally sending any data between devices. Maybe with full redesign third-party email servers should be made optional. I believe we should focus less on how to redesign whole service and build more universal layers instead.
First, vsending any data to any machine. Second, optionally remotely accessing our data. Third, mail-like format of data. |
|
First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system.
Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not.
Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity.
In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).