Como Jeff Atwood disse, o e-mail é o núcleo do Discourse e não devemos, nem podemos, ignorá-lo ou contorná-lo.
No entanto, o mundo real pode ser mais indisciplinado do que imaginamos: algumas plataformas não fornecem um endereço de e-mail, mas ainda assim queremos integrá-las ao nosso Discourse. A solução discourse-oauth2-basic é
O discourse-oauth2-basic é um plugin OAuth2 de propósito geral, portanto não inclui recursos específicos para plataformas especiais. No entanto, quando desenvolvemos um autenticador específico para uma plataforma e não fornecemos um endereço de e-mail, podemos querer integrar o sistema de notificação dessa plataforma em vez da notificação padrão por e-mail.
Minha solução sugerida é criar um endereço de e-mail fictício para identidades únicas, como prefixo-da-plataforma + id-da-plataforma@seudiscourse.com, um validador de e-mail para decidir qual sistema de notificação deve ser usado ou alguns hooks e filtros para construir o remetente ao enviar uma notificação, seja a notificação padrão por e-mail ou a implementada pelo autenticador. Acredito que essa seja uma implementação não invasiva para a arquitetura existente.
Isso é totalmente viável. Por exemplo, você pode usar o login do Steam (que não fornece e-mail), definir e-mails falsos em uma versão modificada do plugin e usar notificações push nativas (disponíveis no Windows, macOS, Linux e Android) para todas as necessidades de notificação.
Sempre será necessário algum trabalho personalizado para integrar com a plataforma específica, e no Discourse temos alguns clientes que usam uma configuração assim com grande sucesso. Eles estão entre as maiores instâncias existentes!
Sim, mas o Discourse parece enviar a notificação de exportação diretamente via Email::Sender por meio de um código fixo, em vez de invocar um gatilho de evento de notificação, como DiscourseEvent.