| ▲ | PretzelPirate 4 hours ago |
| They use the email example, but if Google bans me, my identity is also banned and that may be how people contact me. We also need decentralized identity so my identity can exist independently of service providers, but still be owned by me and not an impersonator. |
|
| ▲ | Seattle3503 4 hours ago | parent | next [-] |
| Identity is "infrastructure" government should provide via something like mDLS. A lot of work needs to go into make sure it is secure and it can be used in a way that protects privacy. Eg selective disclosure of attributes for verifying age. Pairwise pseudonyms for identity when your online identity doesn't need to be tied to you real identity, which is most of the time. Something like that would go far in dealing with sybil issues in decentralized systems, which is often the source of a lot of headaches for system designers. |
| |
| ▲ | drdaeman 3 hours ago | parent [-] | | Only as a last resort. If possible, governments, just like any other organizations, should have absolutely no say about anyone’s identity. They (like any other entity) can attest, but such attestation should hold as few of any special value as possible. | | |
| ▲ | davidgay 2 hours ago | parent | next [-] | | > Only as a last resort. If possible, governments, just like any other organizations, should have absolutely no say about anyone’s identity. An unusual position, as historically governments have provided birth and death registries [0], passports, identity cards, etc, etc [0]: or, earlier, in the West at least, the church | |
| ▲ | Seattle3503 2 hours ago | parent | prev [-] | | We've seen ~20 years of people trying to solve identity without the government. We've seen plenty of solutions that can provide stable identities over time, but we haven't really seen anything that provides meaningful sybil resistance. As computer systems become more and more "autonomous", sybil resistance is increasingly the most important feature of any identity system. Any identity system that doesn't solve that problem pushes to the application layer, where it usually has UX impacts that have serious tradeoffs with adoption. |
|
|
|
| ▲ | jrm4 4 hours ago | parent | prev | next [-] |
| So, (especially after watching Bluesky / ATProto) I'm increasingly convinced that this is not a problem that needs solving. Email is still a protocol, and the thing that ATProto is doing causes as many problems as it purports to solve. Mostly because "decentralized identity" is still "identity." And the safest way to do identity is to have it be destructable and remakable on the fly. |
| |
| ▲ | cortesoft 4 hours ago | parent [-] | | > And the safest way to do identity is to have it be destructable and remakable on the fly. It might be the safest, but it defeats lot of the purpose of identity. There is a reason it is a hassle to change your email address... so many services are tied to that identity. You can change it, but you have to change every service that is relying on it as your identity, and you still have to own your old email so you can prove to the service that you are the same person. I am not sure how you could ever avoid this problem? The purpose of an identity is to be able to tell that one request is made by the same person who made a previous request... persistence is a requirement. | | |
| ▲ | jrm4 2 hours ago | parent [-] | | Yes. And as much as I hate "well, users should just be smarter and deal with inconvenience," I think it may fit here. Identity is always hard, and I strongly doubt there is any great way that makes it "easier" and still safe. Aka, yes please kill passkeys, or at least be super upfront and informative. "When you use passkeys, you are giving your keys to Apple or Google, and they cannot guarantee safety." | | |
| ▲ | iamnothere 34 minutes ago | parent [-] | | It may be that different types of identity are preferable for different use cases, rather than converging on a single system. > "When you use passkeys, you are giving your keys to Apple or Google, and they cannot guarantee safety." Not true with hardware passkeys, which also add a true second factor. Central passkeys are a problem, though. |
|
|
|
|
| ▲ | voxic11 4 hours ago | parent | prev | next [-] |
| You can use a custom domain that you own with gmail. But of course domains aren't that great either as they are only somewhat decentralized and it's still pretty easy to lose your domain. |
|
| ▲ | vvpan 4 hours ago | parent | prev | next [-] |
| The underlying problem to both protocols and non-protocols is identity. Gmail works because Google owns the identity and acts effectively as a proof of humanity. To go on a tangent - I think that more people having personal public key pairs (via crypto) than ever is actually a positive direction. Atprotocol is another big player in identity at the moment, just as long as "can't be evil" mechanisms are kept alive and have good UX. |
|
| ▲ | paulddraper 4 hours ago | parent | prev | next [-] |
| That exists in the form of domain names. Which for reputable TLDs is permanent, outside illegal activities. |
| |
| ▲ | watermelon0 3 hours ago | parent [-] | | Country code TLDs are also reputable, but you might lose access if you move or if something happens to the country. |
|
|
| ▲ | wilg 4 hours ago | parent | prev [-] |
| atproto has a very elegant decentralized identity solution imho https://atproto.com/guides/identity |
| |
| ▲ | vvpan 4 hours ago | parent [-] | | Atproto identity is going in the right direction but I hope they go in that direction harder. For example plc.directory (maps DID to public keys I think?) is heavily centralizing force. |
|