Decrypted Payload Caching

NDK can cache decrypted plaintext separately from the original encrypted event.

Behavior

When a supported usecase needs encrypted content:

• NDK first checks for a cached plaintext sidecar
• if plaintext is already cached, the signer does not need to decrypt again
• if plaintext is missing, NDK decrypts and stores it in the cache backend

The original event remains unchanged and stays encrypted in the canonical event store.

Cache key

Decrypted plaintext is cached per:

• event id
• viewer pubkey

This means the same event can have different cached plaintext entries for different viewers.

What this helps with

This is especially useful when:

• the app re-renders the same encrypted content repeatedly
• decryption depends on a remote signer
• the signer is slow compared to local cache reads

Current use

Current NDK usecases that can reuse cached decrypted payloads include:

• GiftWrap
• private Nip51List content through Lists
• NIP-17 direct message flows that unwrap gift-wrapped messages

What apps should assume

• cached plaintext is an optimization and a persisted sidecar
• encrypted event content is still the authoritative wire format
• deleting the original event from cache should also remove the associated decrypted sidecar
• using a persistent cache backend allows decrypted sidecars to survive restart