I do think this is a bit different though. E.g. you can also lose a physical driving license - and there's a pretty well standardised reissuance process for them, involving no permanent data loss.

Not to say that there aren't issues with the proposal. But I'm not sure recoverability is one of them.

Thanks! Definitely understand why you'd build it incrementally rather than going straight to E2EE; and just having Bluesky DMs will already be great!

But yeah - if there were a single architectural choice that has the biggest impact on ease of transition, message history would have to be it!

Of course, by "we" here I mean Meta. I don't know what tradeoffs Bluesky will be making. But as they plan a progression from non-E2EE to E2EE messaging, I hope they're able to design to constraints like this tradeoff, to simplify their transition later on.

However in our case, per the Labyrinth Protocol whitepaper, we ended up choosing to keep 1 & 2. This means you can log in to use Facebook and Messenger as before, and won’t be blocked if you don’t restore your history. Just in that situation, you won’t have earlier messages.

It’s obviously tough moving from a world where you can have all 3 for a product - as is the case for non-E2EE messages - to a world in which one of them is not guaranteed. None of them are ideal to give up.

Third, it might be particularly important to people to always have their historical E2EE data to hand when using the E2EE component. In our case, this would mean that you can only even use messaging at all in situations where all message history is available.

Second, somebody in that state may still be actively using the E2EE component. In our case, that’s sending and receiving new messages. For some use cases, this will be all somebody needs; and others it will be good enough.

In our case, Facebook is a platform with many features, of which Messenger is just one. Someone might not recover their E2EE history when logging in for various reasons, and if they don’t need message history for what they’re doing, we don’t need to block them from other things.

First up, you don’t want somebody who has temporarily lost access to some key material to have to completely reset their account to log in. It’d be drastic and painful! Maybe they were logging in to use a different function of the service; or only care about new data?

Specifically, there are three desirable properties, of which you must pick two:

1. User can log in without cryptographic key material.
2. E2EE component functions whenever the user is logged in.
3. All stored data is available whenever the E2EE component works.

The challenge arises when a larger platform includes a component that is end-to-end encrypted; such as Facebook and now Messenger. As the platform cannot give access to the plaintext E2EE content, there’s a choice to make around authentication, data recovery and functionality.

Hey there, this is exciting to hear! I'm Jon, from Meta's team who built E2EE for Messenger. If it would be at all helpful to talk over any considerations in the initial system design that might make the E2EE transition easier/harder in future, I'd be very happy to chat over some of our learnings!