[grishka]

So it's just pushing the problem a bit further away by hiding your real key. See, you have to be able to recover your account even if you've lost every single of your electronic devices. Every one of them. Including flash drives. No data. No backups. None. Zero bytes.

The fundamental problem with keys is that they are files. You can't exactly memorize one, not without torturing yourself. You have to store them somewhere extremely reliably but at the same time completely secretly.

[omeze]

The point here is that self-hosting is _possible_. Most users are almost certainly going to just let a third party host their keys. But if keys are identity primitive at the protocol level, then the protocol prevents full centralized platform capture, similar to email interop.

[grishka]

The key being the identity still has the problem of not being changeable, no matter how you spin it.

Self-hosting is possible with ActivityPub as well, but without sacrificing the user-friendliness. I can already see someone saying "what do you mean I have to start a new account after my private key leaked".

[nl]

> See, you have to be able to recover your account even if you've lost every single of your electronic devices. Every one of them. Including flash drives. No data. No backups. None. Zero bytes.

Well 12-word mnemonics help here right? It's imperfect, but certainly is as good as most 2FA implementations use for account recovery.

There are alternative approaches people are trying too. For example Coinbase[1] is trying a MPC approach where you delegate two (or more?) people known to you and if they agree it can recover your account.

But this is done using secure multi-party computation so the unencrypted key is never stored - it is only decrypted by the person doing the recovery when all the other parties agree to provide their tokens.

[1] https://blog.coinbase.com/threshold-digital-signatures-1d467...

[varunsrin]

here's an example that might help -- you can allow key A to own your identity and key B to move your identity to another key. But key B can only move the identity after a time delay if key A does not cancel it. So key B is not your "real key" -- as long as key A is around it is an inferiorly permissioned key. But if Key A is missing then key B becomes the real key.

the key insight is that smart contracts can be used to transmute keys from single points of ownership into a distributed set of permissions.

you can compose a whole set of recovery systems with this primitive - key B could be your ledger or it could be a friend or it could be a third party service that offers "recovery as a service" where you have to call them and prove your identity before they will recover it back to you.

[nl]

This doesn't really solve the issue though - it just moves it to trying to recover another key.