> you could actually trivially recover the message for some time after it "explodes" across a variety of devices which each have their own keys. A month or two

> you could actually trivially recover the message for some time after it "explodes" across a variety of devices which each have their own keys. A month or two later the message is gone largely because nobody cares any more, not because it really "exploded" as depicted after just a few minutes. This is worth clarifying because it's complicated. What happens when the "fuse burns down" is that the server and all running devices delete the message immediately. This matches what the user thinks is happening, and it's what really matters in the vast majority of real world use cases. Now, one of the recipient devices could choose not to delete the message, and there's nothing we can do about that. They could be running a modified version of Keybase. Or the user could just photograph the message. The exploding messages in small Keybase groups are in fact cryptographically repudiable, but almost no one in the real world knows what that means or cares about it. More likely, the server itself could be compromised. It might be running evil code, or have a bug, or perhaps all its databases just get vacuumed up by a few different nation states. Who knows. So suppose the server side messages never get deleted. What's next? Like normal messages, exploding messages are end-to-end encrypted, so if the adversary never gets their hands on a recipient device, they can't read anything. Also like normal messages, if the adversary had a compromised recipient device before the message was sent, they can read everything, and there's nothing we can do about that. So the question is, what is their window to compromise a device after the message is sent? This is where the ephemeral key schedule is relevant. An active device issues a new ephemeral key each day. Each ephemeral key is retained for a week after its successor key is issued. (So if a device goes offline for a few days, its current ephemeral key will have its lifetime extended by a similar amount.) So a typical active devices has an array of live ephemeral keys, with remaining lifetimes of 7 days, 6 days, 5 days... If I send an exploding message with a lifetime less than 1 day, I will use an ephemeral key with a day or so remaining. For a longer message lifetime, I will use one of the longer-lived keys. (In fact there is a hierarchy of user ephemeral keys and team ephemeral keys, but the idea is the same.) If a device never generates a new ephemeral key for (currently as far as I know) 1.25 months, its active key expires with no replacement, and it no longer receives exploding messages at all. Thus each mothballed device exposes a limited window of exploding messages, and only if the adversary physically gets their hands on that specific device. If the device is ever legitimately reactivated, it will immediately delete all the expired keys. I'm not sure what to make of your summary that "a month or two later the message is gone largely because nobody cares any more." Do you have any questions about the design I just described above? > You can be confident that this Keybase account is controlled by someone who also controls the oconnor663 account on Hacker News or by someone who controls Hacker News itself or by someone at Keybase Keybase cannot lie about about who controls oconnor663 on Hacker News, because each Keybase client independently fetches the proof from my profile. This is the whole point of the Keybase security model. Now the Hacker News admins could post a proof as me, and maybe create some bogus 0c0nn0r663 account on Keybase to try to impersonate me there. But they can't replicate my GitHub proof, or my proof on jacko.io. Perhaps they register 0c0nn0r663 on GitHub too, and buy the jack0.io domain, and post lookalike proofs there. But at that point, if we're assuming that other users can be tricked by lookalikes, does it even matter that they compromised my real Hacker News account?