Tópico é criado com um link na primeira postagem - para começar, detecte um único link na primeira postagem ou URL colado no título.
Opcional: Para evitar spam trivial, aguarde a primeira resposta ou ative uma configuração do site.
Sondar a página para ver se WebMention é suportado.
Um comentário WebMention é enviado com o texto "Esta página está sendo discutida em =SITE\_DOMAIN=: "=TITLE=" =TOPIC\_LINK= =CATEGORY_AND_TAGS=" (usando o default_locale do site).
O site recebe o WebMention (potencialmente delegando para fed.brid.gy, aplicando anti-spam, etc.) e eventualmente o exibe como um comentário.
O ator (autor do comentário) receberia o logotipo de alta qualidade do site ou o avatar @system, e o nome curto do fórum.
Só um aparte: não mencionei isso na postagem, mas o protocolo suporta o envio de curtidas e repostagens como cidadãos de primeira classe, como respostas, seria bom se o Discourse implementasse isso também.
O Pavilion enviou uma inscrição para a NLnet de 40.000 Euros para adicionar suporte de federação ao Discourse (veja abaixo). Foi rejeitado e acabamos nos inscrevendo (e sendo aceitos) no DAPSI em vez disso.
Uma atualização aqui. Pavilion e CDCK (Discourse.org) estão discutindo a construção de um plugin ActivityPub para Discourse. Após alguma discussão, chegamos à especificação abaixo. Quaisquer comentários ou sugestões são bem-vindos antes de finalizarmos. Observe que
O suporte para conteúdo de entrada (por exemplo, posts no Mastodon, etc. sendo importados para o Discourse) está intencionalmente excluído. Será possível adicionar isso em uma versão posterior.
O suporte para seguir usuários (em oposição a categorias) também está intencionalmente excluído. Também seria possível adicionar isso em uma versão posterior.
O Pavilion construirá o plugin MVP (eu trabalharei nele), e o CDCK o possuirá e hospedará (ou seja, será um plugin CDCK, não um plugin Pavilion).
Visão Geral
Um Plugin ActivityPub (AP) para Discourse.
O objetivo do plugin é uma implementação MVP das especificações ActivityPub, ActivityVocab e ActivityStreams no Discourse com uma integração demonstrada da funcionalidade MVP para uma plataforma compatível com AP, nomeadamente Mastodon. Na medida do possível, a implementação será construída para suportar suporte adicional aos protocolos e quaisquer extensões.
Esta especificação diz respeito à ativação do suporte AP em uma base por categoria, onde apenas o primeiro post de cada tópico em uma categoria habilitada para AP é federado (“apenas o primeiro post”).
Usuários
O uso do plugin será documentado de forma abrangente no meta em um tópico de plugin.
Usuário Normal
Assina (também conhecido como “segue”) uma categoria Discourse habilitada para federação (FDC) no Mastodon (ou qualquer outro serviço fediverso) usando o identificador da categoria, por exemplo, @announcements@meta.discourse.org.
Vê um trecho do primeiro post de todos os tópicos FDC (postados após a assinatura) em seu feed Mastodon, cada um com um link de volta para o tópico associado, por exemplo, “Discutir em nosso fórum”.
Qualquer ação relacionada ao post no Mastodon não aparece no Discourse.
Qualquer ação relacionada ao post no Discourse não aparece no Mastodon.
Trechos de posts federados podem ser controlados pelo autor do post usando marcação semelhante à usada para controlar trechos de tópicos, por exemplo, <div>{text}</div>
Administrador
Habilita a federação em uma base por categoria usando uma configuração de categoria. A federação só pode ser habilitada em categorias visíveis para “todos” em instâncias públicas.
Define o nome de usuário federado da categoria através da interface de configurações da categoria (não pode ser alterado).
Define listas de permissão e negação de domínios através de configurações do site a partir das quais a atividade é automaticamente aceita ou rejeitada.
Define uma “lista de bloqueio” de nomes de usuário federados para fazer parte de um Objeto(s) de Bloqueio na caixa de saída do servidor.
Define o comprimento máximo de caracteres de uma nota federada usando uma configuração do site, ou seja, activitypub_note_excerpt_maxlength.
Define o texto associado ao link incluído no primeiro post de um tópico Discourse federado em “Personalizar > Texto”.
Define se o link de volta (e o texto) para o fórum é incluído em posts federados em uma base por categoria.
Adiciona um par de chaves através de configurações do site para assinar o conteúdo federado.
Técnico
O plugin incluirá testes abrangentes (testes unitários/de integração e testes js).
A categoria é um Ator ActivityPub automatizado dentro do Discourse (como um Grupo ActorType). O preferredUsername federado é definido pelo administrador ao habilitar a federação e armazenado em um campo personalizado da categoria. O nome federado (também conhecido como nome de exibição) é o full_name da categoria.
Os usuários são Atores no conteúdo federado pelo Ator da categoria. O preferredUsername federado é o nome de usuário do Discourse do usuário no momento da federação. O preferredUsername de um usuário é armazenado em um campo personalizado do usuário caso o usuário altere seu nome de usuário do Discourse. O nome federado (também conhecido como nome de exibição) é o nome do usuário no Discourse.
Em geral, os objetos ActivityPub serão associados aos seus objetos Discourse equivalentes usando campos personalizados, quando apropriado (por exemplo, IDs de objeto ou ator), e novas tabelas, quando apropriado (por exemplo, inbox e outbox).
A principal Atividade ActivityPub a ser implementada é Seguir e atividades e modelos associados necessários para implementá-la, ou seja, inbox, outbox e Ações e Coleções necessárias.
Posts do Discourse seriam federados como Notas do ActivityStream, com o conteúdo em HTML.
A autenticação será tratada usando Assinaturas HTTP, veja aqui e aqui. Todas as outras Considerações de Segurança na especificação ActivityPub serão abordadas conforme apropriado.
Os endpoints de federação serão protegidos conforme apropriado para a especificação, ou seja, garantir que redirect_to_login_if_required seja usado nos controladores, adicionar guardião para permissão de categoria que todos possam ver.
Estou muito animado para ver esta notícia! Obrigado! Além disso, fico feliz que você esteja começando com uma implementação inicial simples em vez de tentar “comer o elefante proverbial” (não uma referência oblíqua ao Mastodon). Hesito em sugerir adicionar algo, mas como você pede sugestões, uma que espero que exija um trabalho insignificativamente maior:
O que você pensaria em, opcionalmente, também postar trechos de respostas, usando inReplyTo para encadeá-las? Acho que isso destacaria o diálogo que ocorre no Discourse e seria mais convidativo; juntamente com o “Discuta em nosso fórum”, eu esperaria que ver a conversa fosse mais provável de atrair mais pessoas.
O problema de federar respostas neste estágio é que você pode criar expectativas de engajamento que não serão atendidas até que você tenha suporte adequado para isso. É importante manter as expectativas do usuário claras aqui. Enquanto alguns usuários podem entender as limitações em torno dessas respostas federadas, outros podem não entender. O outro problema é o de tentar reduzir o número de desafios técnicos a serem enfrentados de uma vez.
Dito isso, já contemplamos uma extensão de “tópico inteiro” para a especificação de “primeiro post apenas” que você vê acima. Compartilhei algumas das notas técnicas para isso abaixo para dar uma ideia de onde isso poderia levar. Eu enfatizaria que a extensão “tópico inteiro” não faz parte da especificação inicial e é apenas uma possibilidade neste estágio.
Extensão de tópico inteiro
Notas de Entrada seriam publicadas como novos tópicos ou respostas (usando inReplyTo ou Replies).
A segurança do Discourse e os filtros de spam serão aplicados aos objetos de entrada o melhor possível usando Aceitar / Rejeitar objetos.
As postagens de notas seriam atribuídas a um usuário em estágio associado ao ID do ator por meio de um campo personalizado. Isso exigirá uma variação não baseada em e-mail do conceito de usuário em estágio, pois o usuário não terá um e-mail real (um espaço reservado pode ser gerado usando o ID do ator federado e preferredUsername).
A associação de usuários do ActivityPub em estágio com usuários padrão do Discourse seria possível, mas não está incluída atualmente em nenhuma parte desta especificação. Este é um problema de “identidade federada” e suas soluções associadas.
As postagens federadas não suportariam @menções federadas, ou qualquer outra coisa nesse sentido fora das especificações principais do ActivityPub/Stream. O suporte para tais recursos pode ser adicionado em versões posteriores, por exemplo, usando Webfinger, seguindo o Mastodon.
A chave nesta primeira versão é focar na implementação mínima viável. Uma vez que essa base seja estabelecida, a federação completa (ou mais completa), potencialmente alinhada com essas notas de “tópico inteiro”, será mais viável. Eu enfatizaria, no entanto, que a direção do plugin será algo a ser determinado pela CDCK. Qualquer coisa que eu mencione aqui são apenas maneiras possíveis de como a especificação base poderia ser construída.
Algumas das postagens e discussões em andamento do Fediverse:
PS. Gostaria também de mencionar que fui abordado por Daniël Klabbers, desenvolvedor principal do Flarum, em novembro do ano passado, que me disse que eles estavam trabalhando em uma extensão ActivityPub. Não sei qual é o status, mas pode ser bom se todos os projetos no domínio dos Fóruns trabalharem juntos para obter o máximo de interoperabilidade possível no espaço.
Em relação a essa interoperabilidade, também gostaria de destacar o processo de Proposta de Aprimoramento do Fediverse, o FEP no Codeberg:
Aqui, por exemplo, o Lemmy finalizou recentemente um FEP para Grupos ActivityPub. As discussões acontecem no SocialHub em:
(O processo FEP está ganhando força com o crescimento do Fediverse e atualmente é o melhor lugar para padronizar mecanismos de protocolo)
Obrigado @aschrijver, muito útil! Pessoalmente, estarei bastante focado na implementação do MVP especificada acima, trabalhando em estreita colaboração com a CDCK. Na frase concisa de @mcdanlj, é crucial que esse esforço não tente “engolir o elefante”. Estamos ansiosos para ouvir qualquer feedback construtivo sobre a especificação, particularmente no aspecto técnico.
Gostaria de acrescentar, no entanto, que outros dois membros do Pavilion, @nmeyne (um veterano da comunidade SSI; particularmente credenciais verificáveis) e @merefield, também estão trabalhando nesse espaço e estão interessados em algumas das questões mais amplas que você levantou.
Como ilustração de mal-entendidos reais de uma ilusão de fidelidade, uma das questões que encontramos nos Fóruns Maker, onde importamos muitas comunidades do Google+ quando o Google+ acabou, é que a importação foi de fidelidade suficientemente alta que os novatos no site não percebem que estão tentando interagir com outros usuários que ainda não chegaram ao site do Google+, e, portanto, temos uma resposta pronta para informá-los que a pessoa com quem estão tentando falar não está lá para responder a eles.
Obrigado por fornecer os detalhes sobre a ideia de “extensão de tópico inteiro”.
Caso isso seja adicionado no futuro… só para constar, eu realmente gosto da abordagem que o Pterotype para Wordpress ofereceu, que é que quaisquer comentários federados são encaminhados diretamente para moderação / aprovação do grupo antes de serem postados de volta no tópico original do fórum como uma resposta.
No caso de um fórum, esta pode ser uma tarefa mais adequada para os tipos TL4 / TL3 em vez da equipe.
Pessoalmente, achei que isso se provou especialmente útil para evitar que respostas fora do tópico / estilo de mídia social sobrecarreguem o tópico de discussão original.
Sim, o uso da fila de revisão é algo que discutimos para o conteúdo recebido. Como você observou, isso é algo a ser considerado se e quando chegarmos lá (não na primeira versão).
Apenas uma observação de que as questões administrativas relativas a este trabalho foram resolvidas, então começarei a trabalhar na especificação na próxima semana. Qualquer feedback técnico adicional ou notas sobre a especificação são bem-vindos.
Levará alguns meses para que isso se concretize, então aguente firme.
Se uma postagem for excluída no Discourse, uma ação Delete pode ser enviada aos seguidores?
Nos Maker Forums, temos pontos suficientes de “google points” que recebemos muitos spammers de SEO. Temos permissões relativamente flexíveis para novos usuários porque uma forma comum de novo uso é uma pessoa frustrada buscando ajuda relevante para o site, e isso nos ajuda a ajudá-los mais rapidamente. Mas isso significa que os spammers tendem a fazer uma postagem de spam e, em seguida, ela é relativamente rapidamente marcada como spam, removida da lista e, em seguida, excluída.
Eu adoraria que essas postagens federadas fossem excluídas e a exclusão publicada via Delete para que possamos limpar o spam dos caches federados. Isso está possivelmente no escopo?
Poderia ser útil neste caso se houvesse um atraso na federação, de um certo número de horas, para permitir que o spam fosse resolvido antes da federação. (Talvez até aplicar o atraso apenas às primeiras postagens de usuários relativamente novos?)
Se não for significativamente mais trabalho no início, federar as edições de postagens como Atividades Update também seria valioso. Se for uma daquelas coisas que podem ser contribuídas após o MVP, então um design que acomode razoavelmente a adição disso mais tarde seria ótimo.
Para que valha a pena, eu definiria o atraso baixo na(s) minha(s) instância(s). Eu não planejo usá-lo para evitar federar postagens de spam, porque seria razoavelmente provável que fosse um sinal que traria um moderador de seu feed fediverso para nosso Discourse para tomar uma ação. Tenho chat_integration_delay_seconds definido para 20 para edições rápidas de erros de digitação, e esperaria fazer algo semelhante aqui. No mínimo, essa configuração estabelece um precedente para tal atraso.
Uma breve atualização! Estamos há um mês no desenvolvimento e, de modo geral, já temos o seguinte funcionando:
Pessoas podem seguir categorias com ActivityPub ativado
O primeiro post de tópicos em categorias com ActivityPub ativado são federados para seguidores
Há uma série de peças menores também, mas não vale a pena entrar em detalhes nesta fase. Haverá pelo menos mais um mês de desenvolvimento antes de começarmos os testes internos.
