InMemoryServerStorage

Non-persistent ServerStorage for tests and examples.

The prekey repository keeps immutable state behind a Mutex: publication and bundle consumption each run under the lock and replace the state only after all checks passed, so they are atomic and serialized. The mailboxes are one queue per recipient behind another Mutex, so enqueue and drain are serialized too and each recipient's queue is in enqueue order. That is stronger than the per (sender, recipient) order MailboxRepository promises. Device registrations and authentication nonces share one more Mutex, so registration, nonce claims, device recovery and routine rotation (key replacement together with its nonce claim) are atomic. The last-device recovery keys and challenges live under that mutex too, so a last-device recovery consumes its challenge in the same step as it replaces the key, and a recovery key rotation or revocation claims its nonce, checks the authorizing registration and removes the user's challenges in the same step as it changes the recovery key. The pending recovery key resets live there as well: every recovery key transition removes the user's reset in the same step, and a reset completion replaces the key, removes the reset and the challenges at once.

Constructors

Link copied to clipboard
constructor()

Properties

Link copied to clipboard
Link copied to clipboard
Link copied to clipboard
Link copied to clipboard
open override val mailboxes: MailboxRepository
Link copied to clipboard
open override val preKeys: PreKeyRepository