Where your OpenFeed keypair comes from.

Under the Recommended client profile a single RSA key does two jobs: it authenticates the client (private_key_jwt) and it signs every DPoP proof. OpenFeed holds the public half, which you register as a JWKS.

Keys are never generated implicitly

This is the important part, and it is a deliberate departure from the obvious design. A store that lazily generates a key when it finds none is convenient on one machine and broken on two: each node mints a different key, signs proofs with it, and OpenFeed rejects them because that key is not in the registered JWKS. The failure is intermittent and load-balancer-dependent, which makes it about as unpleasant as bugs get.

So private_jwk/1 returns {:error, {:no_key, ...}} when no key exists. Generating one is an explicit, operator-driven act:

mix openfeed.gen.key            # generate and persist
mix openfeed.jwks               # print the public JWKS to register

Choosing a store

Caching

Every API call signs a DPoP proof, and every proof needs the private key, so the key is cached in :persistent_term after first read. Pass cache: false in the store options to disable, and call invalidate/1 after rotating a key in a running VM. The key material lives in memory either way.

Implementing your own

defmodule MyApp.VaultKeyStore do
  @behaviour OpenFeed.KeyStore

  @impl true
  def private_jwk(opts) do
    case MyApp.Vault.read(opts[:path]) do
      {:ok, json} -> {:ok, OpenFeed.KeyStore.from_json!(json)}
      :error -> {:error, {:no_key, opts[:path]}}
    end
  end
end