Sim, o Discourse poderia fazer algo semelhante com seu widget de incorporação de comentários. Entre outras coisas, isso poderia ajudar a reduzir o constrangimento que algumas pessoas experimentam ao iniciar um fórum que tem apenas alguns usuários ativos: AI sockpuppet accounts to jumpstart my community?. Novos sites do Discourse poderiam usar postagens de blog para promover e popularizar seu fórum. Isso é meio que possível agora, mas permitir que os usuários comentem diretamente do widget de incorporação tornaria o processo mais integrado.
3 curtidas
Um formulário de comentários simples conectado ao Discourse no lado do WordPress, para que os visitantes não precisem ir primeiro ao Discourse e criar uma conta lá, antes de postar um comentário, ajudaria a reduzir o atrito e a aumentar o engajamento, pelo menos para editores como eu.
Para o meu caso de uso, seria ideal se um comentarista pudesse deixar seu comentário simplesmente com um nome e endereço de e-mail. Isso poderia ser usado para criar um usuário em estágio no Discourse e convidá-lo a participar totalmente para continuar a conversa, sem impedi-lo de deixar seu comentário.
Estamos descobrindo que o atrito extra de criar uma conta para deixar um comentário em um artigo publicado está dificultando o aumento do engajamento e, finalmente, o crescimento da comunidade em nosso fórum. Por exemplo, ao ser perguntado sobre nossa seção de comentários (usando a integração atual do Discourse-WordPress), um autor nos deu o seguinte feedback:
Sobre a área de conversação: agora que você mencionou… Lembro-me de ter visto isso. E na época, pensei que esqueceria por enquanto, já que parecia demorado para se inscrever. Essa é uma forte evidência de como a maioria das pessoas se sentiria em ter que passar por esse processo. Normalmente sou quase obcecado em ver comentários sobre minha escrita. Lembro-me de rir para mim mesmo e dizer: “Acho que não sou obcecado o suficiente para lidar com isso agora”. Idealmente, você deixaria os comentários abertos a todos, sem processo de inscrição. Mas qualquer nível de simplificação/facilidade melhoraria o engajamento lá. Comentários como esse geralmente são um movimento impulsivo. Se as pessoas forem impedidas de alguma forma, elas tenderão a seguir em frente e não levarão tempo.
3 curtidas
Estava pensando nisso outro dia. Estranhamente, senti falta dos comentários do WordPress nas minhas postagens de blog porque parecia tão rápido para as pessoas começarem, com uma barreira de entrada muito baixa.
Apesar de ter um processo de inscrição realmente simples, no momento, se alguém quiser comentar na postagem, ele precisa visitar uma nova página. Acho que cruzar esse limiar pode parecer muito oneroso. Quase como se eu quisesse comentar em A, mas tivesse que visitar B para comentar em A e depois voltar para A para ver o comentário. Seria mais natural comentar em A logo abaixo de A.
Gosto da ideia de “staging users” (preparar usuários). Posso pensar em talvez hackear isso fazendo com que o formulário de comentários do WordPress envie um e-mail para o fórum Discourse e, em seguida, prepare um usuário dessa forma, embora eu imagine que possa ficar mais complexo integrar totalmente dessa maneira.
3 curtidas
Eu acho que isso costumava ser possível, mas tenho certeza de que o Discourse agora compara o "Cabeçalho de Remetente" do e-mail com seu Caminho de Retorno. Se esses não corresponderem, o e-mail é rejeitado. (Se o Discourse não estiver verificando o Caminho de Retorno, o sistema de comentários poderia ser facilmente abusado - qualquer endereço de e-mail poderia ser inserido no formulário.)
Existem algumas maneiras de abordar o problema do Discourse como um sistema de comentários. Acho que a melhor abordagem seria o Discourse melhorar seu iframe de incorporação de comentários para que os usuários pudessem interagir com ele como usuários autenticados do Discourse. Se isso não for possível, um aplicativo web de comentários incorporados do Discourse poderia ser desenvolvido. Esse seria um projeto interessante, mas eu gostaria de ter certeza de que o Discourse não forneceria funcionalidade semelhante por meio de seu iframe de comentários incorporados antes de prosseguir muito.
Existem também algumas soluções específicas para o WordPress. A mais simples é habilitar os comentários do WordPress e o plugin WP Discourse. O risco é que isso reduza a atividade no fórum do Discourse. Acho que haveria maneiras de ajudar com isso na interface do usuário do WordPress, no entanto - por exemplo, vincular a conversas relacionadas que estavam acontecendo no Discourse.
Também seria possível desenvolver algo específico para sites WordPress que estivessem funcionando como o provedor de SSO do Discourse. Escrevi sobre isso em posts anteriores neste tópico. Fazer um bom trabalho nisso pode exigir mudanças significativas no plugin WP Discourse. A menos que (estou pensando em voz alta aqui):
O que estou tentando indicar com a captura de tela acima é que, no caso de um site WordPress que é o provedor de SSO do Discourse, os comentários poderiam ser exibidos com o iframe de comentários do Discourse. Os comentários poderiam ser criados por meio de um formulário que posta na API do Discourse. Isso pode exigir algumas alterações no iframe de comentários do Discourse para garantir que ele seja atualizado quando um novo comentário for adicionado, mas não exigiria que os usuários pudessem interagir com ele como usuários autenticados do Discourse.
4 curtidas
Então, se entendi corretamente, a ideia seria que o comentarista se registrasse no lado do WordPress, depois deixasse um comentário através do iframe incorporado do Discourse, que postaria no tópico no Discourse, depois atualizaria a exibição de volta no WordPress, para que aparecesse imediatamente.
O processo de registro do WordPress validaria o e-mail, presumo. Mas isso também exigiria a mudança para o WordPress como provedor do Discourse SSO — factível, mas de certa forma infeliz, porque move o atrito para o outro lado para pessoas que talvez queiram apenas se inscrever no fórum.
Tendo a concordar com o que você disse aqui:
Se fosse até possível registrar ali mesmo no iframe, ou pelo menos ser preparado, para que se pudesse prosseguir com o comentário (que só seria postado depois que o e-mail fosse validado), isso me pareceria uma solução que equilibra facilidade de uso com segurança.
2 curtidas
Sim, você entendeu. Se o WordPress for o provedor de SSO, o problema de permitir que os usuários comentem nos tópicos do Discourse não é tão difícil de resolver. A parte complicada, em termos de trabalhar com o estado atual do plugin WP Discourse, é descobrir como exibir os comentários no WordPress - atualmente, a seção de comentários do WP Discourse não espelha as respostas do tópico do Discourse. Em vez disso, uma seleção dos “melhores” comentários é exibida.
Seria possível atualizar o plugin WP Discourse para lidar com este caso de uso, mas para fazer isso corretamente, seria necessário reescrever completamente a forma como ele lida com os comentários do Discourse. Não é uma decisão minha, mas acho que investir esforço em melhorar o iframe de comentários do Discourse seria um melhor uso do tempo.
5 curtidas
Eu só queria adicionar minha voz para querer este recurso.
Seria muito bom se os usuários do WP pudessem simplesmente se registrar/entrar e comentar diretamente em uma postagem no WP sem ter que navegar para o fórum, para que tudo parecesse mais um sistema de comentários. O comentário deles apareceria tanto abaixo da postagem quanto no tópico do discourse que foi criado. E eles sempre teriam a opção de postar no discourse, no wordpress ou em ambos - de forma integrada. Não tenho ideia de como isso seria alcançado, mas seria uma maneira realmente integrada de integrar os comentários do WP com o Discourse que parece menos desajeitada e, sem dúvida, melhoraria vastamente o número de comentários do que obtemos atualmente com o plugin existente.
3 curtidas
Talvez isto:
Mas isso sequestra totalmente o login do Discourse, tanto quanto sei.
Isso permitiria que os usuários postassem comentários diretamente em um post do WordPress e preenchessem automaticamente esse post na thread correspondente do Discourse?
Estou trabalhando nisso agora. A primeira versão é para um site WordPress headless que usa o framework Remix para seu front-end. Assim que isso for feito, farei uma versão para sites WordPress regulares. Provavelmente será um plugin que estende o plugin WP Discourse. Espero que a maior parte do que estou fazendo no site WordPress headless possa ser transferida para sites WordPress regulares, mas pode exigir alguns compromissos.
Permitir que os usuários comentem diretamente de um site externo é trivial de implementar. O principal requisito é que o site externo tenha acesso às credenciais do usuário do Discourse. Isso pode ser feito usando o site externo como provedor do DiscourseConnect para o Discourse ou configurando o Discourse como um provedor do DiscourseConnect para o site externo.
No segundo cenário - onde o site externo não é o provedor do DiscourseConnect para o Discourse - na primeira vez que um usuário quiser comentar do site externo, ele precisará clicar em um link para conectar sua conta no site externo à sua conta do Discourse (ou para se registrar no Discourse se ainda não o fez). Pode ser bastante transparente do ponto de vista do usuário.
A mudança acima, no entanto, não faz com que tudo pareça um sistema de comentários regular. Uma expectativa normal para um sistema de comentários é que você possa ler e interagir com todos os comentários. O plugin WP Discourse exibe apenas uma seleção de comentários que são extraídos de uma rota especial fornecida pelo Discourse. Ele não fornece nenhuma funcionalidade para interagir com os comentários.
As partes difíceis do problema são:
- paginar todos os comentários de um tópico no WordPress, tendo em mente que pode haver milhares deles
- fornecer uma interface de usuário que dê ao usuário algum feedback sobre onde ele está em uma longa lista de comentários
- descobrir como exibir comentários que são respostas diretas a outros comentários. (A convenção do Discourse para isso está desalinhada com a forma como a maioria dos sistemas de comentários lida com respostas.)
- permitir que os usuários respondam diretamente a um comentário, gostem de um comentário, editem seus próprios comentários, etc.
- lidar com comentários que foram criados no Discourse e que podem conter conteúdo ou marcação que não podem ser facilmente renderizados ou interagidos no site externo. Por exemplo, oneboxes, enquetes…
- fornecer uma maneira de filtrar comentários por recentes, mais antigos, melhores, etc…
Tudo isso precisa ser realizado sem colocar uma carga excessiva no servidor do site externo, fazer muitas solicitações de API para o Discourse ou consumir muita memória no dispositivo do usuário (o objetivo é criar um sistema de comentários leve). É alcançável, mas não é algo que possa ser simplesmente inserido no código existente do WP Discourse sem fazer mudanças significativas nele.
4 curtidas
Que bom saber que você deu início a isso!
Só uma ideia: como parte da proposta é reduzir o atrito para que as pessoas comentem em primeiro lugar, pode ser uma boa ideia focar na fluidez desse primeiro comentário. Como mencionado acima, parece que muitas pessoas simplesmente querem poder comentar com seu endereço de e-mail; a questão, então, é a validação e o login, ou a criação de conta (dependendo, suponho, de como o DiscourseConnect está configurado).
Uma vez que o usuário esteja “dentro”, eu esperaria que ele tivesse mais probabilidade de visitar o tópico correspondente do fórum para obter toda a funcionalidade de discussão baseada no Discourse. Eu só espero que todas essas partes difíceis do problema não impeçam a solução para o problema do “primeiro comentário”. Ter milhares de comentários para os quais teremos que descobrir a paginação seria então um “bom problema para se ter”. 
4 curtidas
Isso é o suficiente para mim, pois usuários novos e antigos participarão e se envolverão uns com os outros. Não é um grande problema para mim, um externo
Sim, essa é uma preocupação genuína. O primeiro passo é colocar um site de demonstração online. Ter um site ativo para testar as coisas deve deixar óbvios quais são os pontos de atrito.
Pode ser tecnicamente possível permitir que usuários anônimos comentem em posts. A única maneira não improvisada que consigo pensar seria ter os comentários postados em nome do usuário anônimo por um usuário real. Isso parece um pouco estranho, no entanto.
Sei que o WordPress tem uma configuração para permitir que usuários “convidados” criem comentários. Isso vem com a limitação de que um comentário de “convidado” não será associado a um usuário real se o usuário que criou o comentário de convidado se registrar no site após criá-lo. Postar “em nome de” um usuário teria que funcionar de maneira semelhante - não haveria como saber que o usuário que criou o comentário anônimo era o proprietário do endereço de e-mail que ele forneceu com o comentário.
Idealmente, os usuários serão autenticados no site externo ou no Discourse antes de criar um comentário.
Do ponto de vista do usuário, o menor atrito possível seria no caso em que o site externo é o provedor SSO para o Discourse. Isso permitiria que eles comentassem em tópicos do Discourse sem nunca ter que visitar o site do Discourse.
Do ponto de vista do proprietário do site, a maneira tecnicamente mais fácil de autenticar usuários seria ter o Discourse funcionando como um provedor de autenticação para o site externo. Essa é a configuração que estou usando atualmente no meu site de teste local. O site externo (Remix) nem sequer tem uma tabela de usuários. Ele apenas cria uma sessão de usuário com base na resposta da rota /session/sso_provider do Discourse.
A desvantagem de usar o Discourse como provedor de autenticação para o site externo é que ele força os usuários a passar pelo processo de registro/login do Discourse. Não há nada de errado com esse processo, exceto que ele parece forçar os usuários a baixar todos os ativos do Discourse quando eles podem querer apenas deixar um comentário no site externo. Então, é meio lento. Vou investigar mais…
Seria Talvez reduza isso para centenas para um cenário mais realista. O ponto que estou tentando fazer é que o problema fica complexo quando você vai além de 1 página de posts (20 posts).
Editar: pode ser possível usar convites do Discourse para simplificar o processo - se um usuário anônimo quisesse comentar em um post, haveria um campo de e-mail exibido junto com o formulário de comentários. Enviar o comentário acionaria o Discourse para enviar um convite para o endereço de e-mail. O comentário ficaria em uma fila até que o convite fosse aceito. Isso permitiria que os usuários criassem o comentário quando sentissem a inspiração e lhes daria feedback imediato sobre o status do comentário.
4 curtidas
Estou animado para ver qual será a solução do @simon aqui.
Eu só queria observar que uma solução que está se desenvolvendo em uma trilha diferente nessa frente é usar o ActivityPub. Em sua última versão, o plugin oficial do Wordpress ActivityPub adicionou suporte ao plugin Discourse ActivityPub.
Isso significa que, se você tiver o plugin Wordpress ActivityPub instalado e o plugin Discourse ActivityPub instalado, tudo o que você precisa fazer é configurar uma categoria para “Seguir” um ator do Wordpress fazendo uma postagem (ou todo o site do Wordpress) e suas postagens do Wordpress aparecerão como novos tópicos nessa categoria do Discourse.
(observe que o plugin do Wordpress tem um atraso na publicação, é por isso que leva um minuto para aparecer no Discourse no vídeo; pule para 1:40 para vê-lo aparecer).
O plugin Wordpress ActivityPub também suporta ingestão de atividades e já está configurado para processar atividades recebidas em resposta a uma postagem como um “Comentário” nessa postagem, no entanto, essa parte em particular ainda não está funcionando com as Atividades que estão sendo enviadas pelo plugin Discourse (acho que o plugin do Wordpress ainda não suporta notas anunciadas). Mas isso também deve funcionar em breve.
Veja mais
6 curtidas
Observe que Matthias, o mantenedor do plugin Wordpress, conseguiu fazer isso funcionar, então em breve haverá suporte para compartilhamento de publicações e comentários bidirecionais nativos entre Discourse e Wordpress (via ActivityPub).
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 curtidas
Este tópico começou com a ideia de que um sistema de comentários com o Discourse poderia fornecer funcionalidade semelhante ao Coral, com o benefício adicional de permitir que os comentários do site se ramifiquem em tópicos regulares do Discourse. O Discourse está fornecendo a capacidade de moderar os comentários de um site e permitir que discussões relacionadas aos comentários ocorram no fórum.
Não acho que a necessidade de moderação precise ser argumentada.
A necessidade de permitir que os comentários se ramifiquem em tópicos reais do Discourse pode ser menos óbvia. Estou partindo da premissa de que ter qualquer tipo de conversa online é difícil - a conversa presencial fornece todos os tipos de sinais sutis que não existem online. Ter conversas online significativas com mais do que um punhado de pessoas é quase impossível. É aí que entra o Discourse. A funcionalidade de grupo do Discourse fornece a capacidade de limitar quem pode participar de um tópico. Grupos de comentaristas podem ter permissão para participar de tópicos do Discourse isolados. Isso é meio que o oposto de como o fediverso funciona.
Dito isso, estou curioso sobre como a integração do fediverso Discourse/WordPress poderia funcionar. Por exemplo, se Sally comentar na postagem do WordPress de Bob, o que se esperaria que acontecesse com o comentário de Sally se ela tivesse uma conta no Discourse? O que se esperaria que acontecesse com o comentário de Sally se ela não tivesse uma conta no Discourse? Existe alguma maneira de Sally optar por não ter seu comentário publicado no fediverso?
Saindo do tópico, mas com os vários tipos de contas de danos online que estão sendo implementados ou propostos em países ocidentais, se o comentário de Sally for considerado ofensivo, quem é o responsável por publicá-lo? Estou assumindo que essa é uma pergunta sem resposta neste momento.
3 curtidas
Interessante!
A forma como eu sugeriria pensar sobre como o ActivityPub funciona com moderação e agrupamento (e outras rubricas de comunicação online) é que ele é primariamente um padrão de comunicação. Ele fornece alguns mecanismos para lidar com essas questões, mas em grande parte as deixa para os vários clientes do sistema.
O e-mail como um padrão de comunicação é uma analogia imperfeita, mas talvez útil. “E-mail” é uma coleção de padrões de comunicação que permite trocar mensagens com qualquer pessoa na internet. Ele tem vários problemas de “controle de qualidade”, por exemplo, spam. Existem alguns aspectos da coleção de padrões que chamamos de “e-mail” que ajudam a lidar com esses problemas (por exemplo, DMARC, DKIM, SPF etc.), no entanto, talvez a principal forma como o controle de qualidade é tratado seja nos próprios clientes de e-mail. O Gmail se tornou um cliente de e-mail popular em parte porque, argumentavelmente, lidou muito bem com spam (e problemas semelhantes de controle de qualidade).
Seguindo a analogia, o Discourse seria o “Gmail” do ActivityPub. Todas as ferramentas de moderação, agrupamento de usuários e outros recursos que tornam o Discourse uma ótima plataforma de discussão ainda estão (praticamente) disponíveis no contexto do ActivityPub. Vou detalhar isso começando a responder às suas perguntas.
Começarei descrevendo o que acontece, então talvez possamos passar para as perguntas mais sutis. Vou pular muitas coisas aqui, com o objetivo de responder o básico:
- O comentário de Sally é publicado como um objeto ActivityPub do WordPress.
- O objeto é ingerido no Discourse e convertido em um post.
- Se o “Ator” de Sally estiver associado a uma conta de usuário no Discourse, o post será associado a essa conta de usuário. Se o Ator dela ainda não estiver associado a uma conta de usuário, um usuário “staged” (preparado) será criado a partir do ator de Sally e eles serão os proprietários do post.
Você pode ver o acima em funcionamento neste tópico:
- A categoria do Discourse WordPress - SocialHub está seguindo o WordPress de Matthias.
- Matthias postou um novo artigo em seu blog usando sua conta regular do WordPress.
- Isso apareceu no Discourse como um novo tópico, com o post sendo associado a um usuário “staged” associado ao Ator de Matthias.
- A forma como os comentários funcionam é exatamente a mesma.
Apenas para cobrir talvez a pergunta mais óbvia: Matthias pode reconciliar o usuário “staged” criado a partir de seu ator do WordPress e sua conta normal do Discourse nesse servidor?
A resposta de curto prazo é que o plugin do Discourse tem um conjunto de recursos de “Autorização” que atualmente permite reivindicar a propriedade de atores de outros servidores Discourse ou Mastodon, o que mescla quaisquer usuários “staged” em sua conta (significando que você agora possui os posts em sua conta principal do Discourse). Esse conjunto de recursos poderia ser estendido para o WordPress. Reconheço que isso é um pouco prolixo e pode ser mais fácil entender o que quero dizer com esta demonstração:
A resposta de longo prazo é que as provas de identidade podem ser incorporadas às atividades do ActivityPub em algum momento, talvez removendo a necessidade de autorização impulsionada pelo usuário, o que significa que a “reconciliação” pode ser (mais) automática.
Talvez outra questão seja se a “reconciliação” é necessária, dado que Matthias ainda controla os atributos de identidade de seu usuário “staged” através de seu Ator ActivityPub (que é editável no WordPress, cujas edições são repassadas ao usuário “staged” no Discourse).
Digo a maior parte disso como uma forma de aquecimento, para que possamos passar para suas perguntas mais sutis e importantes. Espero que esteja fazendo sentido até agora.
2 curtidas
Está fazendo sentido.
Em relação à questão da moderação, estou falando sobre usar o Discourse para moderar comentários do WordPress. Essa é a funcionalidade que permitiria ao Discourse ser usado de forma semelhante ao Coral. Isso é fácil de alcançar se os comentários do WordPress forem, na verdade, comentários do Discourse publicados do WordPress para o Discourse via API. Funciona nativamente. Isso permite coisas como usar quaisquer ferramentas de moderação baseadas em IA fornecidas pelo Discourse. Estou me perguntando se algo semelhante poderia ser alcançado com a integração ActivityPub do WordPress/Discourse.
Qual é a prova de identidade para o usuário encenado? O endereço de e-mail deles é passado do servidor de origem?
Para minha preocupação (pessoal) de não querer publicar conteúdo para todo o fediverso, parece que é tecnicamente possível configurar um relacionamento ActivityPub um para um entre um site Discourse e um site WordPress, mas me pergunto se esse tipo de coisa não vai contra o propósito do protocolo ActivityPub.
Editar: pode valer a pena adicionar que o objetivo é criar um relacionamento ganha-ganha entre um site e um fórum Discourse associado. As ferramentas de moderação do Discourse destinam-se a fornecer segurança de que o sistema de comentários do site é bem moderado. A seção de comentários do site destina-se a ser usada para popular o site Discourse com tópicos e usuários.
2 curtidas
A postagem convertida do objeto ActivityPub tem, na maioria*, as mesmas funções de pré-processamento e pós-processamento aplicadas a uma postagem criada via API. O ponto de entrada é diferente (ou seja, um controlador ActivityPub em vez do controlador de postagens), mas a forma como as postagens são criadas é, em sua maioria, a mesma.
*Em termos mais técnicos, se você criar uma postagem via API, o processamento real é feito pelo NewPostManager, que então repassa a maior parte do trabalho para o PostCreator. A principal coisa que o NewPostManager lida (para nossos propósitos aqui) é a fila de revisão. Tudo o mais é tratado no PostCreator.
Atualmente, o plugin ActivityPub pula o NewPostManager e o repassa para o PostCreator em seu próprio PostHandler (ou seja, do plugin). Fiz isso principalmente para reduzir a complexidade na implementação inicial. Não há uma razão inerente pela qual o PostHandler do plugin não possa repassar a postagem para o NewPostManager e obter o benefício das verificações da fila de revisão.
Em resumo, não há uma diferença substancial entre postagens criadas via plugin ActivityPub e via API normal.
Existem algumas camadas para isso.
-
Em primeiro lugar, o POST do servidor de origem para o seu servidor é assinado usando assinaturas HTTP para garantir que a solicitação realmente se origina do servidor de origem.
-
Em segundo lugar, cada Ator (ou seja, usuário) nesse servidor de origem tem um UUID, ou seja, um ID vinculado ao seu domínio, único no fediverso. Parece algo assim:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619dE-mails não são usados no ActivityPub.
-
Cada Atividade (por exemplo, uma Criação de um objeto semelhante a uma postagem) que você recebe está associada a um ID de Ator. E cada ID de ator pode ser resolvido para atributos de Ator.
-
Portanto, quando você recebe uma “Atividade”, por exemplo, a criação de um novo objeto semelhante a uma postagem, em seu servidor, você sabe, de acordo com o domínio de onde recebeu a atividade, os atributos do Ator que está realizando a Atividade. Você está confiando no domínio remetente aqui, mas isso sempre acontece na medida em que, por exemplo, o Discourse confia nas instâncias do WordPress com o plugin WP Discourse para enviar os atributos corretos do usuário associados.
Portanto, o usuário em estágio em si não precisa de uma prova de identidade per se, da mesma forma que um usuário em estágio por e-mail não precisa de uma prova de identidade.
A necessidade de uma prova de identidade surge quando a pessoa real associada ao ator ActivityPub, e outra conta do Discourse, como o exemplo com Matthias acima, quer consolidar (ou “reconciliar”) sua identidade. Eles podem não gostar que tenham efetivamente dois “usuários” em um único Discourse. Observo que, sem tal reconciliação, eles podem controlar
-
Os atributos de identidade do Ator ActivityPub / usuário em estágio via domínio de origem, por exemplo, atualizando seu perfil do WordPress, essas atualizações sendo federadas e o Discourse aplicando o mesmo); e
-
O conteúdo associado ao Ator ActivityPub / usuário em estágio via domínio de origem, por exemplo, editando seu comentário do WordPress, uma atividade de Atualização sendo enviada e, em seguida, processada pelo Discourse.
Mas, no entanto, eles podem sentir que é “bagunçado” ter efetivamente dois usuários no Discourse. É por isso que o plugin tem seu conjunto de recursos de “Autorização”, para permitir que você mostre que seu usuário normal do Discourse está associado ao ator ActivityPub com seu usuário em estágio. Isso é atualmente feito por meio de mecanismos de autorização específicos da plataforma:
-
Para Mastodon, é feito através da API OAuth do Mastodon. Requer que você autentique sua conta no Mastodon para provar que você controla o ator relevante.
-
Para Discourse, é feito através da API de Usuário. Isso é o que é mostrado no vídeo em minha postagem anterior.
-
Existem algumas maneiras de fazer o mesmo para o WordPress, por exemplo, DiscourseConnect via plugin WP Discourse. Isso ainda não foi implementado.
Depois de provar que você possui o ator associado ao usuário em estágio, o usuário em estágio é mesclado com seu usuário normal, suas postagens se tornam suas e quaisquer Atividades novas associadas a esse Ator se tornam automaticamente suas. Mas este conjunto de recursos é realmente mais para melhorar a experiência do usuário e, estritamente falando, não é necessário. A pessoa real por trás desses vários usuários controla os atributos do usuário e seu conteúdo desde o início.
Sim, é possível canalizar o destino das publicações de saída e restringir a origem das publicações de entrada. Se isso frustra ou não o propósito do ActivityPub é discutível. Estritamente falando, ActivityPub é apenas um padrão. Eu argumentaria que não há razão para você não poder usar o padrão dessa forma. Historicamente, o ActivityPub tem sido associado a redes sociais descentralizadas, particularmente o Mastodon, o que pode ser o motivo pelo qual você sente que esse tipo de abordagem frustra o propósito do ActivityPub. Mas eu faria uma distinção entre o próprio padrão ActivityPub e suas implementações existentes aqui.
Além disso, neste contexto, observo que, como o e-mail, o que chamamos de “ActivityPub” é na verdade uma coleção de padrões. O documento de padrões intitulado “ActivityPub” deve ser lido em conjunto com outro documento de padrões chamado “ActivityStreams”, que descreve os principais objetos em jogo aqui. O padrão ActivityStreams é mais firmemente “neutro em relação ao serviço” do que o próprio ActivityPub (ou seja, menos vinculado a redes sociais descentralizadas).
Para usar (outra) analogia, blockchain como tecnologia é simplesmente um ledger descentralizado, a primeira vez que me explicaram me fez pensar no Sistema Torrens de registro de terras, inventado no século 19 (na Austrália) pelas mesmas razões pelas quais o blockchain foi inventado (ou seja, para prevenir fraudes em transações imobiliárias). Mas a implementação mais popular do blockchain é o Bitcoin, que tem um uso específico (diferente) e certas valências culturais. A analogia não é a melhor, mas uma maneira de pensar sobre isso é que Mastodon e redes sociais descentralizadas são para ActivityPub o que Bitcoin é para blockchain.
De fato, uma das razões pelas quais ajudei a estabelecer um novo grupo de trabalho W3C ActivityPub para Fóruns com NodeBB, Flarum e outros é tentar mudar o foco da integração ActivityPub das implementações existentes (por exemplo, Mastodon) para as preocupações de fóruns, como as relacionadas à moderação que você está levantando. Na verdade, temos nossa próxima reunião hoje. Se você tiver tempo, adoraria ter um colega “Discourser” (esse é um termo?) lá
4 curtidas
Estou falando sobre usar as ferramentas de moderação do Discourse para moderar comentários que aparecem no WordPress. Tecnicamente, isso poderia ser feito com uma solicitação de API do Discourse ou Webhook - após uma ação de moderação ocorrer no Discourse, uma solicitação poderia ser feita para alterar o status do comentário no WordPress.
Assumindo que as coisas sejam alteradas para que os posts do ActivityPub sejam tratados pela fila de revisão, ainda haveria um problema com o atraso entre o momento em que o comentário é inicialmente publicado no WordPress e quando ele aparece no Discourse. Acredito que isso seja alguns minutos?
Para este caso específico, um dos principais argumentos de venda é “use o Discourse para moderar os comentários do seu site”. Ele continua listando os recursos de moderação do Discourse, o sistema de nível de confiança, a fila de revisão, as ferramentas de moderação com IA, etc. Essas são ferramentas que seriam boas de ter para blogs menores, mas um requisito para sites de notícias convencionais. Estou pensando que a melhor maneira de conseguir isso é usar o Discourse como a única fonte da verdade para comentários, em vez de ter comentários existindo em dois (ou mais) bancos de dados.
Isso é ótimo! Sem ter tempo para pensar mais sobre isso, não acho que seria um bom representante do Discourse.
Tenho algumas preocupações gerais sobre a ideia de tratar tópicos, posts e usuários apenas como dados. Precisa haver uma maneira de garantir que o contexto de onde uma discussão está ocorrendo não seja perdido.
Em um nível mais prático, o protocolo ActivityPub decolou antes da introdução das leis de danos online que estão sendo introduzidas em vários países. Precisa haver alguma garantia de que os servidores que consomem dados de uma origem respeitarão as solicitações de exclusão. Caso contrário, os usuários que geram conteúdo em um servidor de origem correm o risco de sofrer repercussões legais se seu conteúdo for posteriormente considerado prejudicial em seu país.
3 curtidas