Solicitação de recurso: uploads seguros para backends S3 sem ACLs por objeto

Problema

Em backends compatíveis com S3 que não suportam ACLs por objeto, secure_uploads não pode coexistir com conteúdo servido publicamente.

Avatares e ativos de tema/site parecem ser servidos por meio de URLs diretas e não autenticadas do S3, o que exige leitura pública no objeto. Mas o mesmo bucket contém uploads seguros de posts que devem permanecer privados na configuração desejada — e ambos (arquivos públicos e privados) compartilham os mesmos prefixos de caminho (original/..., optimized/...). Sem ACLs por objeto, não há como tornar os arquivos públicos acessíveis publicamente e os outros privados.

Minha situação atual: avatares e ativos estão quebrados (bucket é privado → 403 para esses arquivos), enquanto uploads seguros de posts funcionam normalmente por meio do proxy /secure-uploads/.

O conflito central

Uploads seguros exigem um caminho de leitura autenticado; avatares/ativos exigem um caminho não autenticado. Ambos ficam atrás da mesma fronteira de nível de bucket, que não consegue diferenciá-los sem ACLs por objeto.

Soluções solicitadas

  1. Servir avatares/ativos por meio de URLs presigned quando o bucket é privado e as ACLs estão desativadas — mesmo mecanismo usado para uploads seguros. Da minha perspectiva, isso também poderia funcionar apenas para usuários conectados em cenários com uma instância do Discourse não pública.
  2. Suportar buckets ou prefixos separados para ativos públicos versus uploads seguros, para que a fronteira de acesso esteja alinhada com a fronteira público/privada e ACLs adequadas pudessem ser criadas.

Alguma dessas abordagens é viável, ou existe algum caminho suportado que eu tenha perdido?