Tudo bem. Isso é um pouco chato, já que acabei de impor threads nos canais de suporte do nosso Discord para ter uma visão melhor dos casos de suporte. E não tenho certeza se isso realmente acontece - mas, felizmente, há outras vantagens.
Você tem uma previsão para a API e uma ideia de quanto custaria para implementar o recurso?
Obrigado!
/k
Eu cobrei recentemente e está em desenvolvimento há algum tempo. Cobrei novamente e retornarei, mas atenção, da última vez eles me disseram “estará pronto quando estiver pronto”… o problema com código aberto é muitas vezes a falta de uma boa maneira de direcionar níveis apropriados de financiamento da comunidade (ou a falta dele) para auxiliar no foco e na priorização… veremos…
Da minha parte, eu teria que ver a implementação final para estimar o esforço.
O desafio pode ser que, embora seja simples copiar mensagens, manter os Threads sincronizados com os Tópicos pode exigir algum tipo de mapeamento mantido no Discourse, por exemplo, um campo personalizado ou uma tabela que mapeie Threads do Discord a Tópicos do Discourse, para que, quando uma nova mensagem for adicionada a um Thread, você saiba onde colocá-la no Discourse.
Você pode elaborar sobre exatamente a funcionalidade/comportamento que você está buscando?
É, isso é ruim depender de algo que você não pode influenciar.
Minha ideia é muito inspirada no artigo e na discussão no blog do Discourse sobre como Discord e Discourse se complementam bem. Quando começamos nosso servidor Discord há quase dois meses, não sabíamos realmente como ele evoluiria e como afetaria nosso fórum Discourse existente (mas mal configurado), mas parece que as pessoas ainda o usam, assim como nosso Discord, para fazer perguntas de suporte técnico (eu sou do projeto FOSS CrowdSec). Então, basicamente, eu concordo totalmente com a ideia de usar o Discourse como uma memória de longo prazo e sincronizar threads do Discord com o Discourse sob tópicos que correspondam aos canais do Discord (e vice-versa). Do jeito que vejo, isso pode ser feito de forma muito mais eficaz (por exemplo, automatizada) usando threads.
Como eu disse, recentemente impus threads no Discord, o que significa que nem sempre é muito fácil ter uma visão geral das threads para aqueles de nossos desenvolvedores que são designados para o suporte ao usuário. Portanto, quero usar a sincronização com o Discourse também como uma boa maneira para eles se manterem atualizados sobre as perguntas a serem respondidas, sem serem muito sugados pela conversa fiada do Discord.
Isso faz sentido? E existe alguma outra maneira de conseguir isso em um prazo mais curto, talvez?
Olá @merefield!
Estou entrando em contato com você aqui porque acho que meu Issue do GitHub não foi visto, e este me parece o próximo melhor lugar.
Temos recebido um erro que rastreamos até o plugin do bot do Discord. A imagem acima mostra o erro do elemento de inspeção, mas qualquer usuário que envia uma PM também recebe um erro visual de “500 Error” quando sua PM é enviada. A PM ainda é enviada com sucesso, mas este erro faz parecer o contrário. Após desabilitar o plugin, o problema não existe mais.
Tenho quase certeza de que o problema vem de /lib/discourse_event_handlers.rb. Assumo que uma PM está acionando o DiscourseEvent post_created, o que faz com que ele tente acessar a categoria da postagem via posted_category = post.topic.category.id, o que causa o erro.
Espero que isso ajude e que isso possa ser resolvido em breve. Obrigado.
Obrigado pelo relatório. Parece razoável. Talvez eu tenha a chance de analisar isso esta semana…
Fantástico, obrigado! Faremos o acompanhamento da atualização. 
Aviso que estou atolado de trabalho para clientes no momento, então isso pode não ser revisado por um tempo.
Enquanto isso, PR aceito.
Em geral, eu agradeceria mais contribuições da comunidade para os plugins gratuitos.
As coisas estão bem corridas para mim no momento, mas apliquei o que acredito ser uma correção:
Parece funcionar agora e o temido erro 500 em mensagens privadas desapareceu…
Ah, isso é maravilhoso e substitui o Discord Chat!
Ele deveria ler os nomes de slug no Discourse ou apenas os títulos?
O Discord não é gerenciado por slugs da mesma forma, então, se não me engano, são títulos.
Olá, não sei se isso já foi questionado antes, mas as credenciais OAuth devem ser as mesmas do aplicativo? Pois no momento estamos usando outra integração de sincronização do Discord e os campos OAuth já estão preenchidos. Obrigado.
Este plugin é compatível com a solução oficial de login social no core. O bot precisa de um token de um aplicativo Discord autorizado. O login social permite que o plugin identifique o mesmo usuário nas duas plataformas.
Obrigado pela resposta! Vou depurar um pouco mais para ver o que estou perdendo na configuração.
Eu não acho que precise ser o mesmo aplicativo Discord, mas experimente!
Olá!
Pesquisando no fórum por uma maneira de dar aos usuários do Discourse um Nível de Confiança diferente com base em uma conta Discord me trouxe até aqui.
Já temos uma comunidade bastante ativa no Discord e adicionamos o Discourse recentemente para discussões mais organizadas.
Estou procurando uma solução que funcione da seguinte maneira: um membro que faz login com sua conta Discord e tem uma função específica no Discord recebe automaticamente um Nível de Confiança 1 no Discourse.
Este Bot Kit seria o ponto de partida certo para tal implementação?
Obrigado
Este bot, até onde sei, é “unidirecional” do Discourse para o Discord. Não há funções que façam o oposto que sejam integradas.
Pessoalmente, acho que seria um pouco mais fácil realizar isso com código externo que monitora o webhook de eventos do usuário da sua instalação do Discourse.
Evento de webhook saindo → Pegar o ID do usuário do Discord do banco de dados do Discourse (requer o uso de autenticação do Discord) → Pegar os cargos usando discord.js, .py, etc. → Atribuir cargo com solicitação da API do Discourse
Para obter o ID do Discord, você precisa usar o plugin Data Explorer e criar a seguinte consulta:
-- [params]
-- string :user
SELECT u.username, u.id, a.user_id, a.provider_name, a.provider_uid
FROM users u
JOIN user_associated_accounts a on a.user_id = u.id
WHERE u.username = :user
Você pode então consultar a documentação do plugin Data Explorer e acessar essa consulta com uma solicitação de API para obter o ID.
Espero que isso ajude um pouco.
Embora isso seja verdade para a sincronização de funções, o restante não está correto.
Do OP:
Portanto, há bastante comportamento do Discord para o Discourse e está longe de ser apenas um bot de “sincronização de funções”.
Como sempre, PRs são bem-vindos para qualquer funcionalidade adicional geralmente útil. Seria bom ter algumas adições da comunidade. 
Obrigado por esta postagem @merefield
Posso ter seu Discord? Gostaria de fazer algumas perguntas, se tudo bem.
Para manter o conhecimento aberto e indexado para todos, provavelmente é melhor fazer as perguntas aqui. O Discord é um buraco negro para informações. As coisas entram e depois nunca mais são encontradas 
E, caso contrário, também temos o chat aqui no Discourse.
Oi Kene, se não for de natureza comercial, agradeceria se pudesse fazer suas perguntas aqui para que a comunidade possa se beneficiar delas (ou até mesmo respondê-las)