Bluvy Messenger is receiving a new reliability update with version 1.0.14.3.
This patch focuses on making end-to-end encrypted conversations more reliable, particularly when starting Bluvy Messenger, restoring a session, adding a new device, or recovering a conversation whose encryption state is not yet available.
Bluvy Messenger uses MLS (Messaging Layer Security) to provide end-to-end encryption. MLS manages the cryptographic state required by each device to securely participate in a conversation, send messages, and decrypt messages intended for it.
With version 1.0.14.3, we have improved several parts of this process to make encryption recovery faster and the overall experience more resilient.
Restore encryption immediately when needed
Sometimes, a device may not yet have the MLS state required to decrypt a conversation.
Bluvy Messenger was already able to detect this situation and provide a “Restore encryption” option. However, there was an issue with when this option appeared.
In some cases, users had to try sending a message and then wait up to 30 seconds before Bluvy Messenger detected that the conversation required recovery.
This is no longer necessary.
Bluvy Messenger now evaluates the encryption state immediately after loading the conversation history.
If messages are present but cannot be decrypted because the MLS group is not yet available — internally represented by a GroupNotReady state — Bluvy Messenger can immediately display the “Restore encryption” option.
Recovery is therefore available as soon as the problem is detected, without requiring the user to send a message first or wait for a timeout.
New devices are provisioned automatically at startup
Before a device can participate in an MLS-encrypted conversation, it needs the cryptographic material required to securely join conversations.
Part of this process is called device provisioning.
We identified a situation where provisioning could depend on a reconnection to Bluvy Messenger's real-time service.
As a result, a newly added device could successfully connect to Bluvy Messenger without immediately completing the provisioning process required for encrypted conversations.
With Bluvy Messenger 1.0.14.3, provisioning checks are now automatically performed during both:
a new login;
the restoration of an existing session.
Device provisioning is therefore part of the normal startup process and no longer depends on a later reconnection.
Better diagnostics for MLS
End-to-end encryption involves several operations that can happen almost simultaneously.
When Bluvy Messenger starts, it may need to connect to the service, restore the session, retrieve conversations, load message history, recover MLS information, and synchronize the local cryptographic state.
Because these operations are asynchronous, temporary states such as GroupNotReady do not necessarily indicate that encryption has failed.
For example, Bluvy Messenger may receive and load an encrypted message a fraction of a second before the corresponding MLS state has finished loading.
To better understand these situations, Bluvy Messenger 1.0.14.3 introduces additional diagnostic logging around MLS initialization, history loading, and decryption operations.
These diagnostic logs do not compromise encryption
The addition of diagnostic logging does not weaken the security or confidentiality of Bluvy Messenger conversations.
These logs are designed to help us understand the application's internal execution flow and encryption state transitions. They do not disable end-to-end encryption and do not provide access to the cryptographic secrets required to decrypt conversations.
The purpose is to determine where and when an operation fails or waits, not to inspect the private content of conversations.
Messages remain protected by end-to-end encryption, and the introduction of these diagnostics does not change the security model of Bluvy Messenger.
Cleaner and more meaningful development logs
We have also improved how MLS events are classified internally.
Temporary states such as GroupNotReady or CommitPending were previously reported as errors in the development console.
However, these states can legitimately occur during normal MLS operations.
For example, GroupNotReady can simply mean that Bluvy Messenger has already loaded an encrypted message while the MLS state required to decrypt it is still being restored.
These events are now reported as warnings rather than critical errors.
This makes diagnostic information easier to understand and helps distinguish temporary synchronization states from genuine encryption failures.
Additional technical fixes
Bluvy Messenger 1.0.14.3 also includes several internal fixes to the MLS coordination layer.
We corrected TypeScript type imports and signature inconsistencies and improved how different parts of the application coordinate the lifecycle of MLS conversations.
These changes are mostly invisible to users, but they help make one of the most critical components of Bluvy Messenger more robust.
Building a more resilient Bluvy Messenger
Bluvy Messenger 1.0.14.3 does not change the fundamental security model of our end-to-end encryption.
Instead, this update improves how Bluvy Messenger initializes, monitors, and recovers its MLS state.
When a new device is added, a session is restored, or a conversation temporarily lacks the cryptographic state required to decrypt its messages, Bluvy Messenger can now detect and handle these situations more effectively.
We are also continuing to improve our diagnostic tools to identify remaining edge cases and strengthen the reliability of MLS across devices.
Our goal with Bluvy Messenger remains simple: provide secure, end-to-end encrypted messaging while keeping the underlying cryptographic complexity as invisible as possible to the people using it.