Plugin ActivityPub

Bem, um usuário do Mastodon o verá no contexto de uma linha do tempo, e as linhas do tempo são geralmente limitadas. No Mastodon, por padrão, uma linha do tempo total não excede 400 postagens. Se você estiver olhando o original, estará olhando no Discourse de qualquer maneira. Portanto, embora seja verdade na teoria, não vejo isso causando confusão real na prática. Você já tem que ser um seguidor para ver o conteúdo; seguir um link para o original o levará ao Discourse, onde a confusão é resolvida.

Não é perfeito, mas talvez uma opção “menos ruim”?

Suponho que, como alternativa, você possa federar uma edição que anote a postagem como substituída por uma transferência de propriedade, algo como adicionar o link “discuta isso em nosso fórum”?

Claro, não estou argumentando que não é uma diferença, apenas dizendo que parece uma diferença aceitável, em comparação com o bloqueio de um recurso útil e utilizado do Discourse.

Excluir o original deixará threads órfãs no contexto de outras plataformas para as quais você está federando, já que você não pode alterar o ator associado a uma atividade em uma edição (pelo que entendi).

Uma alternativa poderia ser parar de federar edições de forma alguma se a postagem no Discourse tiver um autor diferente de quando foi federada pela primeira vez. Talvez com um aviso? “Alterar o proprietário desativará a federação para esta postagem, você realmente deseja prosseguir?”

Sim. É assim que aparece no Discourse para um usuário normal, que pode não saber que pode clicar no ícone de lápis e revisar as alterações, ou não tem permissões. Estas estão enraizadas no uso normal do Discourse, como vejo:

  • Tornar uma postagem uma wiki é dizer que você aceita que as edições de outras pessoas apareçam no uso normal sob seu próprio nome.
  • Mesmo que não seja uma wiki, usuários com privilégios suficientes podem editar sua postagem no Discourse, dependendo da configuração do site.

Do meu ponto de vista, isso é o mais próximo de equivalente que se obtém, dadas as diferenças no modelo subjacente.

Como vejo, “clique para ver a postagem no site original” já mostra conteúdo diferente entre implementações que são fediverso-primeiro, mesmo ignorando este plugin. Conjunto diferente de comentários visíveis, marcação diferente, tratamento diferente de artigos. Portanto, algumas diferenças sendo visíveis através deste plugin não me surpreendem; acho que é inevitável.

(Obrigado novamente por sua consideração atenciosa dessas ideias. Reconheço que estes são casos de limites difíceis, sou grato pelo trabalho, não presumo que minhas ideias sejam as melhores e não pretendo criar qualquer senso de obrigação para esta fase ou qualquer fase de trabalho sobre isso, nem mesmo para responder a qualquer coisa em particular que estou escrevendo.)

1 curtida

Assim como com a mudança de categoria, acho que realmente depende do cenário. Considere, por exemplo

  1. Postagem 1 criada na Categoria 1 pelo Usuário 1 (Ator 1)
  2. Autor da Postagem 1 alterado pelo Usuário 3 (um administrador) para o Usuário 2 (Ator 2) 2 minutos depois
  3. A Categoria 1 é seguida por 400 Atores em 20 domínios e 5 plataformas de software diferentes, cada uma com implementações ligeiramente diferentes de linhas do tempo e descoberta de conteúdo.
  4. Dentro de 2 minutos após a criação da Postagem 1, há 2 Notas com conteúdo idêntico e Atores diferentes POSTADAS para esses 400 Seguidores.

Acho que isso provavelmente causará confusão para um subconjunto razoável de seguidores, sem mencionar o fato de que o Usuário 2 pode nem mesmo perceber que seu nome agora está associado a esse conteúdo duplicado que ele não escreveu em 20 domínios diferentes. Eles podem estar bem com administradores fazendo isso em uma única instância, é algo implicitamente consentido ao postar nessa instância, no entanto, acho que devemos ter muito cuidado ao estender esse consentimento implícito para todo o fediverso, especialmente nas circunstâncias imperfeitas de duplicar o conteúdo. Alterar proprietários de postagens é uma função administrativa poderosa, específica do Discourse, e implicitamente ligada ao “contrato social” de uma única instância.

Acho que o argumento para wikis é mais forte, no entanto, eu observaria novamente o que você já aludiu. Wikis são um conceito enraizado no Discourse normal. Associar as edições de qualquer pessoa (não apenas da equipe) ao autor original é um conceito do Discourse, sem um análogo no ActivityPub. Devemos ter cuidado ao estender esse conceito usando os métodos padrão do ActivityPub para todo o fediverso. Essas atividades de Atualização serão tratadas como qualquer outra atividade de Atualização em muitas instâncias e plataformas de software diferentes, descontextualizadas de seu contexto original de wiki. Além disso, como você também aludiu, já existe um problema potencial nesse sentido com a capacidade da equipe e de usuários altamente confiáveis de editar as postagens de outras pessoas. Acho que essa questão mais limitada precisa de mais consideração antes de chegarmos à questão dos wikis.

Não estou tentando estabelecer uma escolha binária entre Discourse e ActivityPub para esses recursos. O que estou dizendo é que não devemos simplesmente tentar mapear funcionalidades sensíveis do Discourse para o Fediverse sem pensar cuidadosamente nas consequências. O padrão deve ser que esses recursos mais sensíveis sejam desativados em postagens do ActivityPub até que tenhamos um pouco mais de confiança de que não acabaremos prejudicando ou surpreendendo um subconjunto razoável de usuários ou casos de uso.

Pessoalmente, não sinto que chegamos lá com nenhum dos dois, embora meu instinto seja que o caso do wiki tem mais potencial nesta fase, mesmo que eu ainda não veja uma boa solução.

8 curtidas

Esses dois itens também foram concluídos, acabei de mesclar o PR de Angus para verificação de identidade via OAuth. Excetuando correções de bugs e melhorias de desempenho, isso completa a fase atual de recursos adicionados ao plugin.

Como está, o plugin é bastante rico em recursos. Para recapitular rapidamente os principais recursos, o plugin oferece suporte a:

  • Publicação de posts apenas para seguidores no ActivityPub (o padrão é Público)
  • Publicação do Primeiro Post ou Tópico Completo (o padrão é Primeiro Post)
  • Sincronização bidirecional ao usar a publicação de Tópico Completo, ou seja, todos os posts criados no Discourse em um tópico serão publicados no ActivityPub e vice-versa, respostas no ActivityPub serão postadas no Discourse
  • Opção de publicar posts como Notas (para serviços de conteúdo mais curtos como o Mastodon) ou Artigo (mais apropriado para serviços de conteúdo longo)
  • Verificação de identidade

Em seguida, trabalharemos no ajuste fino dos recursos atuais, melhorando a usabilidade. O feedback ainda é bem-vindo, é claro. Estou particularmente interessado em maneiras de explicar como tudo isso funciona para usuários regulares, não é uma tarefa fácil.

Estou muito alinhado com o @angus, nosso objetivo é fazer o que é prático e alcançável com um esforço razoável. Para esse fim, estamos dispostos a aceitar alguma funcionalidade reduzida no Discourse neste momento. Essa é a nossa melhor chance de descobrir se limitações específicas são importantes de abordar ou não (por exemplo, os usuários do plugin frequentemente encontrarão limitações de wiki-ActivityPub?).

6 curtidas

Eu entendi corretamente, então, que chegamos ao ponto em que faz sentido articular as restrições?

Olá :slight_smile:

Primeiramente, obrigado por desenvolver tudo isso.

Em seguida, estou muito interessado em conectar diferentes serviços ActivityPub e, pelo que li, trata-se principalmente de enviar mensagens de Discourse para Mastodon, de um lado para o outro.

Estou ciente de que o protocolo é agnóstico em relação ao serviço, mas existe algum tipo de documentação para, digamos, conectar diferentes instâncias do Discourse, ou integração do Nextcloud, ou PeerTube, etc.?

1 curtida

Desativamos as alterações de autor de postagem e wikis em tópicos do ActivityPub por enquanto, pelos motivos que já mencionei (suas suposições não funcionam com o ActivityPub imediatamente). Esses são os únicos dois recursos que foram temporariamente desativados em tópicos do ActivityPub dessa forma. Qualquer outra funcionalidade reduzida deve ser relatada como um problema.

Este é um plugin do ActivityPub que segue de perto a especificação do ActivityPub, portanto, foi projetado para funcionar com qualquer serviço que siga essa especificação, o que inclui todos os que você mencionou (e outros). O Mastodon é a primeira plataforma ActivityPub com a qual focamos em integrar porque, na prática, você precisa garantir a compatibilidade com um serviço de cada vez e é a maior plataforma ActivityPub.

4 curtidas

Tentado duas vezes em https://meta.discourse.org/u/rokejulianlockhart/preferences/activity-pub

```json { "errors": ["Você não tem permissão para visualizar o recurso solicitado."], "error_type": "invalid_access" } ```

O que eu faço?

2 curtidas

Olá @rokejulianlockhart, obrigado pelo feedback. Como você está realizando o fluxo de autorização? Você está clicando em “Autorizar” na captura de tela acima em um navegador (qual navegador também?) Ou você está copiando/colando os URLs de alguma forma? Pergunto porque você os tem em sua postagem. Aqui está um vídeo do fluxo padrão funcionando para mim em meta.discourse.org

Você está fazendo algo diferente disso?

2 curtidas

@angus,

  1. rokejulianlockhart@mastodon.social

  2. Você está prestes a fazer login no site “mastodon.social” com o nome de usuário “rokejulianlockhart”, mas o site não requer autenticação. Isso pode ser uma tentativa de enganá-lo.

    “mastodon.social” é o site que você deseja visitar?

    Aqui eu clico

    Sim

  3. Log in - Mastodon

    Autorização necessária
    meta.discourse.org gostaria de permissão para acessar sua conta. É um aplicativo de terceiros. Se você não confia nele, não deve autorizá-lo.
    Revisar permissões

    Contas
    Acesso somente leitura

    Aqui eu clico

    Autorizar

  4. Em seguida, o anterior

    “mastodon.social” é o site que você deseja visitar?

    prompt aparece, e eu faço o mesmo.

  5. https://meta.discourse.org/ap/auth/redirect?code=s2H3Og_3oLTb8cAsYN9Kmgeh8xPySeOaWSp2bdZ2sEE

    1. .JSON

      {"errors":["Você não tem permissão para visualizar o recurso solicitado."],"error_type":"invalid_access"}
      
    2. Headers

      X-Firefox-Spdy: h2
      content-encoding: gzip
      content-type: application/json; charset=utf-8
      date: Mon, 25 Sep 2023 11:39:30 GMT
      referrer-policy: strict-origin-when-cross-origin
      server: nginx
      vary: Accept-Encoding
      x-content-type-options: nosniff
      x-discourse-route: o_auth/redirect
      x-discourse-username: rokejulianlockhart
      x-download-options: noopen
      x-frame-options: SAMEORIGIN
      x-permitted-cross-domain-policies: none
      x-request-id: 01276bd6-77ea-42ae-8f60-6fa365a70e1f
      x-xss-protection: 0
      
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
      Accept-Encoding: gzip, deflate, br
      Accept-Language: en-GB,en;q=0.7,en-US;q=0.3
      Connection: keep-alive
      Host: meta.discourse.org
      Sec-Fetch-Dest: document
      Sec-Fetch-Mode: navigate
      Sec-Fetch-Site: cross-site
      Sec-Fetch-User: ?1
      Upgrade-Insecure-Requests: 1
      User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
      

Olá, após a última atualização, parece que os perfis de usuário (/u/user) foram quebrados. O nome de usuário e a foto de perfil apareceriam (mais a lista de ofensas do usuário no topo).

Percorremos nossa lista de plugins e desativamos um por um até que o problema desaparecesse. Também funcionou com o modo de segurança ativado. Aqui estão alguns dos erros do cliente que recebíamos:

Cannot read properties of null (reading 'getBoundingClientRect')
at Object.offset (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:5104:37)
at e.scrolled (https://amcforum.wiki/assets/discourse-9756bc4a118ac228ac6ac3f2b29c7d4a7d60a9f16ece25de4a772f0055c6eb94.js:2347:106)
at p.invoke (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4339:182)
at p.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4331:141)
at h.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4346:207)
at $._end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4410:9)
at $.end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4363:240)
at $._runExpiredTimers (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4417:192)

Aqui está como fica com o plugin ativado (para sua própria conta)

Para outro usuário (neste caso, 9pfs)

Aqui está outro bug engraçado causado pelo plugin:

Atualmente estamos executando a versão 3.2.0.beta2-dev deste commit https://github.com/discourse/discourse/commits/af305366909fd712362d727d0fa92f380d71d4cd e estamos executando a versão 0.1.0 do plugin deste commit https://github.com/discourse/discourse-activity-pub/commit/6f29542d603627016757f8cd9bb4a145e8f50866.

1 curtida

@rokejulianlockhart Você está com os cookies desativados ou alguma extensão de privacidade em execução? O fluxo de autorização atualmente depende de um cookie de sessão seguro para funcionar.

@aboutDavid Obrigado pelo relatório. Embora seja possível, parece improvável que o que você está compartilhando esteja sendo causado por um problema neste plugin. Você poderia compartilhar um link para o seu site? Você também tem algum tema ou componente de tema ativado?

2 curtidas

Da solução de problemas em modo de segurança, sabemos o seguinte com certeza:

  1. É um plugin não oficial
  2. Não é um tema ou componente de tema.

Até onde sei, temos dois plugins não oficiais:

  1. Animar avatares (Confirmado manualmente que não é o culpado)
  2. ActivityPub

Quanto a um link do site:

3 curtidas

A interface de atualização mostra uma marca de seleção ao lado de todos os plugins, exceto os dois (indicando que são plugins oficiais).

2 curtidas

O problema no seu site provavelmente está sendo causado por algo que usa o outlet user-profile-avatar-flair. Este plugin não usa esse outlet. O plugin de avatares animados, no entanto, usa.

Como você confirmou isso?

1 curtida

@aboutDavid verificou e garantiu que o plugin não tinha JS do lado do cliente. O problema é parcialmente do lado do servidor?

1 curtida

Não ter JS do lado do cliente não significa necessariamente que não haverá problemas do lado do cliente. Neste caso, o problema parece surgir da forma como um plugin outlet está sendo usado, possivelmente em um template. Você poderia tentar remover o plugin animated avatars e me informar o resultado?

(Como observação, o Animated Avatars Plugin tem JS do lado do cliente. Veja por exemplo).

1 curtida

Acabei de editar uma categoria aqui no Meta (para alterar algumas permissões de acesso de grupo). Não alterei nenhuma configuração relacionada ao activitypub, mas acabamos com estas três entradas no log da equipe:

Imagino que tecnicamente eles passaram de nil para seu valor padrão, então não houve nenhuma alteração real no comportamento? Ainda assim, seria bom evitar esse registro de remoção para evitar confusão.

2 curtidas

Obrigado pelo relatório David, darei uma olhada em breve.

1 curtida

Ops, hoje estou meio burro, desculpas

edit: sim, são provavelmente avatares animados, desculpe por perder seu tempo lol

3 curtidas

@angus, que eu saiba não.

e eu garanti que desativei o uBlock Origin, embora eu não use as listas de privacidade de qualquer maneira.


No entanto, encontrei um problema diferente testando isso hoje.

Log in - Mastodon

A autenticação do cliente falhou devido a cliente desconhecido, nenhuma autenticação de cliente incluída ou método de autenticação não suportado.

Google Search.