I think he already made a strong point why CONIKS style transparency isn't all that great for end-users. See this mailing list thread that includes the author of CONIKS talking about it with moxie before CONIKS was published:

https://moderncrypto.org/mail-archive/messaging/2014/000226....

https://moderncrypto.org/mail-archive/messaging/2014/000234....

Basically, users change their identity key in practice so often that a 3rd-party can't be the source of truth on whether a MITM has happened. Only the user can audit that and most users are not equipped to do so. So, towards the goal of universal e2e messaging its not clear that key transparency is a real win over the simplicity of trust-on-first-use.

So I think CONAME solves 90% of this. It's set up in such a way that third party verifiers only have to check that the update counter for each key is monotonic. Users can check just that, for the current epoch, the write counter is correct and their key is there. So only a user themselves should see a warning. (and warning cans be disabled by default ... as long as the attacker doesn't know if the user has them on or not, it's an issue)

In contrast, in CONIKS, a user had to check every single epoch. Which was impractical and meant you relied on third party auditors.

This doesn't deal with the restore from backup issue. I think given the FBI apple phone issue though, maybe it's worth reevaluating the risk vs. reword here. Especially if user visible warnings are opt in.

Oh thats really interesting. I've never read CONAME before so I'll check it out. It sounds like its definitely worth evaluating more.

I've wonder if things like multi-device support or deriving a private key from a passphrase (mini-lock style) will eventually make user identity far less likely to change. Then it might be safer to complain louder when your in the situation that someone's identity has changed.