Pluggable store of inbound messages' messageContextInfo.messageSecret, keyed by message id — the key material needed to decrypt a later secretEncryptedMessage MESSAGE_EDIT envelope targeting that message (issue #30; see Amarula.Protocol.Messages.EditEnvelope).

Each entry is %{secret: binary(), sender: String.t()}: the message's secret and its original, server-attested sender (used to reject an edit forged by a different group member who also knows the secret).

This is a separate concern from Amarula.Storage: it holds ephemeral, bounded state (secrets for the ~15-minute edit window), not durable account state, so it has its own behaviour, adapters, and config key.

Adapters

• Amarula.MessageSecretStore.ETS — in-memory, per-connection (the default). Lost on restart, which is usually fine: an edit lands within minutes of the original. TTL-bounded so it can't grow without limit.
• Amarula.MessageSecretStore.ReadOnly — backed by your own message store; Amarula keeps no copy and only reads. See "Using your own store".

Select one via the connection config :message_secret_store (a {adapter, opts} spec, a bare adapter module, a bare opts list → the default adapter, or a prebuilt Scope), or set the default for all connections:

config :amarula, message_secret_store_adapter: Amarula.MessageSecretStore.ETS

The behaviour is open: any module implementing it can be passed as the adapter.

Using your own store

If your application already persists received messages (you must, to render an edit at all), the built-in cache is a redundant second copy — and it does not survive a connection restart. Point the store at what you already have with Amarula.MessageSecretStore.ReadOnly (or your own behaviour module): you own writes — Amarula never stores anything — and on an edit it reads the target message's secret back from you by msg_id. Retention (and surviving restarts) is then whatever your store already does.

On receive, persist the secret (Amarula.Msg.message_secret/1) and the server-attested sender (msg.from) alongside the message, then serve them back:

# in your :messages_upsert handler
for m <- messages do
  MyApp.Messages.save(m.id, secret: Amarula.Msg.message_secret(m), sender: m.from)
end

# at connect
Amarula.new(%{
  profile: :primary,
  message_secret_store:
    {Amarula.MessageSecretStore.ReadOnly,
     get: fn _profile, msg_id ->
       case MyApp.Messages.fetch(msg_id) do
         {:ok, %{secret: s, sender: j}} when is_binary(s) -> {:ok, %{secret: s, sender: j}}
         _ -> :error
       end
     end}
})

Scoping

Like Amarula.Storage, every call carries the connection profile, so one adapter instance serves many connections. The dispatch handle is a MessageSecretStore.Scope (adapter + state).