Per-recipient send process. One ConversationSender exists per recipient JID; all sends to that recipient funnel through it and run one at a time, which serializes Signal ratchet advance for that recipient's session (no per-address lock needed). Different recipients run in parallel under the DynamicSupervisor.

A send is a branchless pipe of ctx -> ctx steps that block on IQ round-trips through Connection (the sole websocket owner):

ctx
|> resolve_devices()   # device-list cache, else a USync query
|> ensure_sessions()   # session files, else a prekey-bundle fetch
|> encrypt()           # per device; plain vs DSM; advance ratchet
|> relay()             # frame + send the <participants> stanza

Each step that needs server data calls Connection.query_iq/2, which blocks until the matching websocket reply arrives. A step failure crashes the process (the DynamicSupervisor reaps it); the pipe carries no error branches.

Lifecycle & registry presence

Identity. A sender's identity is its {instance_id, recipient_jid} pair. It is registered in the app-level Amarula.InstanceRegistry under that key (namespaced by instance_id so two connections don't collide on a shared recipient) — so at most one sender per recipient per connection exists at a time, and deliver/2 is a find-or-start on that key.

Birth (lazy). Started on the first deliver/2 to a recipient with no live sender: find-or-start via Registry.lookup → else DynamicSupervisor.start_child. The {:error, {:already_started, pid}} branch makes the start race-safe even though, in practice, only Connection calls deliver (single process, so no concurrent start for the same recipient).

Registration. Automatic, via the :via name in start_link — the Registry registers the pid on start and auto-unregisters it on death (it monitors the pid). So a dead sender's key vanishes; there are never stale registry entries to reap.

Life. Serializes all sends to its recipient (one pipe at a time → ordered ratchet advance, no per-address lock). Different recipients run in parallel. Holds no durable state: sessions/keys live in Storage, the consumer's from is parked in Connection. So a sender is cheap to lose and cheap to respawn.

Death (three ways).

1. Idle. Each :send re-arms an idle timer (idle_ms, default 1s, overridable via config[:sender_idle_ms]); after that long with no further send it {:stop, :normal}s. It carries no durable state, so lingering buys only warm reuse — a quick follow-up to the same recipient skips a respawn + a session re-read from Storage. The short default keeps a fan-out to N one-shot recipients from leaving a long-lived process tail; a disk-backed store may want a larger value to cut re-reads under bursty traffic.
2. Crash. A raise in the pipe (Signal error, USync blowup, bad bundle) kills it. restart: :temporary ⇒ the supervisor does NOT restart it; the next deliver respawns a fresh one. In-flight + queued sends are lost.
3. Shutdown. The connection's supervision tree going down takes it too. All three auto-unregister the Registry key (the Registry's pid monitor).

Rebirth. The next deliver/2 to that recipient starts a fresh sender — no carried state; it re-reads sessions from Storage.

Crash ⇒ parked-send recovery. Because the consumer's from lives in Connection (not in the dying sender), Connection monitors each sender and, on its :DOWN, fails every parked send for that recipient with {:error, {:sender_crashed, reason}} — promptly, instead of letting the caller hang to the ack-timeout. A :normal idle-stop fails nothing (no in-flight sends). See Amarula.Connection (ensure_sender_monitor / the :DOWN handler) and docs/plans/SENDER_CRASH_FIX.plan.md.