[grishka]

So how do you do it? Who would override the authentication mechanism and reset your key? How would that person authenticate? How would you keep your identity when your public key is your identity? How would you stop someone using your leaked private key to impersonate you?

[varunsrin]

a simple mechanism is using a smart contract to map your key (0x123) to an identity (@alice). the contract can allow you to transfer that identity to a different key (important for key rotation) and also to set up a recovery key that is also authorized to transfer the key if the primary key is lost.

our recovery system for Farcaster has a few more bells and whistles, and you can read about it here: https://github.com/farcasterxyz/protocol#33-recovery

[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.

[karpierz]

> Ownership remains decentralized because the recovery address cannot make a transfer that the custody address does not approve.

This isn't true though?

If I go out camping for a week and the recovery address transfers my identity, I won't be asked to approve; it'll simply go through after waiting 3 days.