Arquitetura bem interessante, principalmente o endereço derivado da chave pública. Como você pediu feedback, deixo alguns pontos mais do lado de privacidade e modelo de ameaça:
- "Zero retenção" e "zero conhecimento" são coisas diferentes, e vale deixar isso explícito na documentação. O SMTP chega ao relay e o relay, nem que seja por milissegundos em memória, vê o conteúdo em claro. Isso é perfeitamente ok pra caso de teste E2E, mas quem ler "zero retenção" pode entender que ninguém no caminho vê o e-mail. Uma seção curta de "o que o relay vê / o que não vê" evita mal-entendido.
- Cloudflare no caminho do WebSocket. Se o hostname do túnel for HTTP(S), o TLS termina na borda da Cloudflare, ou seja, o tráfego fica legível ali. Se a ideia for reduzir quem pode ver o conteúdo, dá pra o relay cifrar a mensagem com uma chave pública do cliente antes de mandar pelo WebSocket. Como Ed25519 é chave de assinatura, o caminho comum é usar uma chave X25519 separada, ou converter (a libsodium tem função pra isso), e cifrar com uma construção tipo sealed box. Aí nem o túnel nem um log acidental expõem o conteúdo.
- Perda da chave = perda do endereço. Como o endereço é derivado da chave, vale deixar claro (e fácil) como exportar e fazer backup dela, principalmente pra quem usar o mesmo endereço em CI de vários ambientes. Talvez valha também documentar como guardar essa chave como secret no CI sem ela aparecer em log.
- Rejeição com 550 quando ninguém está conectado faz sentido pra teste. Só lembraria que alguns remetentes tratam 5xx repetidos como sinal de endereço inválido e podem parar de enviar pra aquele destino por um tempo. Pode valer mencionar isso no troubleshooting.
Parabéns pelo trabalho no port do cloudflared. Sair de ~1,5 GB pra ~450 MB com 200k conexões ajustando buffer é um ótimo exemplo de que o ganho veio de entender o problema, não da linguagem.