Plugin ActivityPub

o mesmo aqui. Não consigo alterar o proprietário de um tópico. Mesmo que a categoria NÃO seja federada.

Esses são avisos, não erros. Eles não significam necessariamente que algo está errado, eles estão lá para lhe dar mais informações sobre o que está acontecendo. Pode haver uma série de razões pelas quais o conteúdo do Fediverso não está sendo processado, muitas das quais têm a ver com a pessoa que envia o conteúdo. Se você não quer que eles apareçam em seus logs, desative o registro detalhado para o plugin ActivityPub (activity pub verbose logging)

O tópico está em uma categoria ActivityPub ou tem uma tag ActivityPub?

O tópico foi criado em uma categoria ActivityPub ou com uma tag ActivityPub?

Observe que a alteração do proprietário de um tópico está intencionalmente desabilitada para tópicos ActivityPub. Quanto ao porquê disso, por favor, veja acima:

É uma categoria com Activitypub, mas estamos falando do proprietário do tópico que não está envolvido com o activitypub, pois é uma conta diferente.

Acho que deveria haver uma opção para permitir a mudança do proprietário de qualquer maneira, caso contrário, não faz sentido que o Discourse tenha o modal para mudar o proprietário.
Além disso, alterá-lo sem enviar nenhuma atualização para o activitypub é perfeito para nós.

1 curtida

Entendo que as pessoas queiram a capacidade de alterar a propriedade das postagens. A questão a ser abordada a esse respeito é a que descrevi acima, especificamente isto:

O conteúdo que aparece no seu Discourse é de um serviço do qual você não é um Administrador e sobre o qual, exceto pelo ActivityPub, você não teria controle algum. Simplesmente estender a capacidade de alterar o autor desse conteúdo sem a devida consideração desse fato não seria prudente.

Quanto ao conteúdo de autoria de usuários do seu Discourse em um tópico que é publicado via ActivityPub, considere o que deve acontecer se quaisquer atualizações forem feitas ao conteúdo depois que você alterar o autor da postagem. Devemos:

  1. parar de publicar atualizações do ActivityPub; ou
  2. publicá-las pelo “velho” Ator (usuário); ou
  3. publicá-las pelo “novo” Ator (usuário).

Publicar atividades de Atualização para um Objeto existente com um novo Ator (ou seja, 3) funcionará com o Discourse (como tentei dar uma indicação para esta questão), mas não funcionará com outros serviços ActivityPub. De fato, já insisti nesse ponto, por esse motivo, no ecossistema ActivityPub. Veja aqui:

E tenho um PR pendente para o Mastodon para tornar o 3 possível

Para dar um exemplo de apenas um dos problemas aqui, considere o caso em que você está publicando conteúdo ActivityPub com sua conta (e seu nome e foto) anexados a ele. Um de seus “concorrentes” segue seu conteúdo. Em seu servidor, eles então alteram a propriedade de todas as postagens com seu conteúdo para serem postagens deles (com o nome e a foto deles) em vez de postagens suas. Isso pode, de forma um tanto compreensível, irritá-lo. Sim, é claro que isso é possível com código personalizado de qualquer maneira, mas a questão é se você deseja incorporar isso às indicações padrão do plugin.

Pensando nisso durante a noite, uma abordagem que poderia amenizar isso um pouco é se adicionássemos o Ator de publicação à exibição de status do ActivityPub:

Estou aberto a outras ideias nessa linha.

Verdade, acho que vou remover a modal inteiramente em tópicos ActivityPub até resolvermos a questão subjacente aqui.

2 curtidas

Eu entendo o problema, no nosso caso usamos Activitypub com uma conta para cada categoria e postamos essa atualização.
Portanto, quem é o dono da thread não importa tanto para nós no Activitypub para os vários casos, por isso digo que deveríamos ser capazes de fazer isso de qualquer maneira.

O ActivityPub não se trata apenas de como você usa seu fórum, mas de como seu fórum interage com o resto do fediverso. Além disso, para construir algo no plugin, precisamos levar em conta outros casos de uso também.

Não quero dar a impressão de que permitir a mudança do proprietário da postagem não é um problema ativamente considerado, ou que não será permitido em uma atualização futura. Estou interessado em quaisquer ideias que as pessoas tenham para resolver os problemas subjacentes aqui, alguns dos quais descrevi acima.

Abordando este exemplo, seria razoável proibir a alteração da propriedade de postagens que foram federadas, permitindo que os administradores alterem a propriedade de postagens criadas dentro dessa instância do Discourse, independentemente de serem federadas.

Um administrador pode se passar por um usuário. Portanto, um administrador é capaz, dentro da plataforma com suas funcionalidades existentes, de criar conteúdo disfarçado de qualquer usuário na plataforma. Espero que os administradores não abusem desse poder; eu não abuso. No entanto, esse poder é semelhante em impacto à capacidade de alterar a propriedade de uma postagem, federada ou não. Em geral, “um administrador pode fazer algo nefasto” já é verdade de inúmeras maneiras.

Concordo (pelo menos na medida em que entendo :grin:) que alterar a propriedade de uma postagem feita por federação (portanto, não uma postagem de tópico?) não faz muito sentido. Ao contrário de alterar a propriedade de postagens feitas no site, não me lembro de ter visto um caso de uso articulado.

Gosto disso não apenas do ponto de vista da robustez contra esse tipo de ataque, mas para tornar a federação mais visível, facilitando para um visitante do site encontrar atores para seguir. Como isso ficaria para um caso em que há um ator de categoria (e, talvez um dia, um ator de site?) e um ator de pessoa? Você teria uma lista?

  • Publicado por [@categoria@site](link)
  • Publicado por [@pessoa@site](link)
1 curtida

Obrigado pela sua análise útil.

Concordo.

Esta análise só se sustenta para postagens não federadas. A questão não é se a alteração do proprietário de uma postagem faz sentido para o Discourse em si. A questão é quais efeitos a alteração de propriedade tem sobre o conteúdo federado. Se você alterar a propriedade de uma postagem local que foi federada, terá que lidar com esta questão:

Eu começaria observando que tanto 1 quanto 2 têm problemas substanciais, que posso detalhar se necessário. A resposta pode ser aquela que o plugin já suporta, a saber, “3”, no entanto, se seguirmos esse caminho, isso acontecerá (assumindo que meu PR atual para o Mastodon não seja mesclado):

  1. O tópico é federado.
  2. As postagens do tópico aparecem no Mastodon.
  3. O administrador do site altera o proprietário da postagem.
  4. O novo proprietário da postagem faz várias edições na postagem.
  5. As edições não chegam ao Mastodon (ou a qualquer outra plataforma ActivityPub, por sinal)

E, consequentemente:

  1. Alguém virá aqui e dirá “minhas edições não estão sendo federadas”. A razão para isso não será imediatamente óbvia porque, no que diz respeito ao Discourse, elas estão sendo federadas.

O ponto chave aqui é que, se adotássemos essa abordagem, seríamos a primeira plataforma no fediverso (que eu saiba) a fazer isso. Ser o único nó em um sistema interconectado de nós a fazer algo não é algo obviamente desejável. Podemos promover mudanças a esse respeito, mas teríamos que estar cientes de que é isso que estaríamos tentando.

Dito isso, já implementei 3, e suspeito que essa será a resposta eventual que me permitirá remover essa restrição. Ainda tenho alguma esperança de que alguém possa apresentar uma abordagem um pouco mais sutil, ou algo em que eu ainda não pensei.

Apenas o Ator attributedTo do objeto seria listado, então haveria apenas um.

1 curtida

Eu vejo a feiura. O processo de pensamento que me levou até lá é algo como isto…

Eu poderia imaginar ingenuamente algo como o #3 com apenas um pouco do #2 — Para também federar uma atualização gerada do usuário antigo que adiciona à última versão que eles publicaram algum texto gerado pelo sistema no topo ou na parte inferior algo vagamente como “para futuras atualizações, siga @newuser@site”.

Então, faria sentido (novamente, ingenuamente) alocar um novo ID para a postagem atualizada sob o novo attributedTo e que é usado para as atualizações do novo proprietário.

Um caso de borda óbvio para mim seria mudar a propriedade de volta para o proprietário original — ele reverte para o ID da postagem antiga ou aloca ainda outro ID? Eu pensaria que reverte, caso em que o ID da postagem federada teria que ser uma chave para uma tupla (usuário, postagem do discourse). Eu esperaria que isso exigisse uma migração para suportar com compatibilidade retroativa.

Tudo isso como um experimento mental me faz apreciar mais claramente por que você não estaria ansioso para apressar sua proposta de alteração para o Mastodon ser considerada! :slightly_smiling_face:

Excluindo a aceitação do seu PR do Mastodon, eu poderia imaginar ser capaz de marcar postagens individuais como não federadas, que seriam federadas como uma exclusão se fossem anteriormente federadas, e/ou poderiam ser feitas com o plugin instalado, mas antes da federação ser habilitada, e então permitir a mudança de propriedade para postagens apenas não federadas. Todas as postagens onde quero poder mudar a propriedade são postagens que não são valiosas para federar, até onde posso dizer.

Eu poderia imaginar que isso seria valioso mesmo que seu PR do Mastodon seja aceito e a mudança de propriedade seja suportada. Não tenho certeza se faz sentido federar as postagens de tópicos de categoria, por exemplo. Pelo menos, eu acho que excluiria todas elas de federar no meu site, mesmo que a mudança de propriedade fosse suportada, se eu tivesse a opção de excluí-las.

Um experimento mental interessante, no entanto, isso não funcionaria por alguns motivos.

  • Você não segue usuários individuais no discourse activitypub.
  • Você não pode alterar o ID de um objeto activitypub existente (você teria que criar um novo objeto).
  • Como você diz, se a propriedade mudasse novamente, ou várias vezes, você acabaria com vários objetos para uma postagem, o que seria incontrolável.

Uma coisa que posso fazer agora nesse sentido é alterar a restrição para se a primeira postagem em um tópico local é publicada. Isso ajudará com alguns tópicos, como você diz.

1 curtida

Meu mal-entendido; Pensei que você também tivesse criado a capacidade de fazer isso, bem como atores de categoria. (Não é uma solicitação de recurso, apenas um mal-entendido.)

Era isso que eu estava tentando descrever, e claramente falhei. Foi pretendido como algo como uma reductio ad absurdum em qualquer caso. :smiling_face:

Isso seria maravilhoso! :heart:

1 curtida

Olá, existe uma limitação para o Lemmy?

Não consigo seguir: @batepapo@lemmy.eco.br por exemplo

Na verdade, eu consigo seguir. O botão “deixar de seguir” até aparece no perfil, mas quando atualizo a página, tudo desaparece.

1 curtida

Ótimo trabalho! Tenho uma pergunta sobre os minutos de atraso na entrega do ActivityPub. Existe alguma forma de desativar o recurso para que a postagem fique visível imediatamente?

Configurar 1 minuto é quase imediato, mas eu gostaria de postar em tempo real também.

1 curtida

@David_Ghost leia isto

2 curtidas

Esta é a primeira coisa que notei também. Qual seria a desvantagem de adicionar o título de um novo tópico à postagem distribuída via ActivityPub?

[Título do tópico do Discourse]
[linha vazia]
[Texto do tópico do Discourse, como publicado agora]

O pessoal do Lemmy estava trabalhando para adicionar compatibilidade com o Discourse. Está na minha agenda verificar isso.

Isso significa que o Discourse está enviando um “Seguir” mas não está recebendo um “Aceitar” do Lemmy.

Atualmente, você só pode fazer isso usando uma variável de ambiente (por exemplo, definida no seu arquivo app.yml)

DISCOURSE_ACTIVITY_PUB_DELIVERY_DELAY=0

O título de um tópico já é publicado. É o name da coleção associada ao tópico.

É assim que a federação do Discourse para Discourse, ou do Discourse para NodeBB, ou do Discourse para qualquer plataforma semelhante a fóruns inclui títulos de tópicos. O Mastodon não processa títulos. Se colocássemos o título do tópico no conteúdo da Nota, como você sugere, isso criaria problemas, por exemplo, para quando o conteúdo é federado para plataformas que suportam títulos.

Fundamentalmente, a limitação que você descreve é que o Mastodon é uma plataforma de microblogging. Já adicionamos funcionalidade para acomodar isso, ou seja, a marcação [note][/note] para permitir que você direcione o conteúdo que está federando. Se você quiser ter uma federação adequada semelhante a um fórum, sugiro federar com outras instâncias do Discourse.

Sim, existem muitas instâncias do Mastodon. Mas também existem muitas instâncias do Discourse. Se uma instância do Discourse com a qual você deseja federar ainda não estiver configurada para isso, ficarei feliz em ajudá-los a se configurarem.

5 curtidas

É possível excluir Atores?
E seria possível configurar várias categorias, para que ele poste tudo o que há de novo no Discourse?
Caso contrário, alguém terá que seguir xx identificadores no Mastodon para obter todo o conteúdo de todas as categorias.

Você pode desabilitar um Ator, o que desabilita tudo relacionado a esse ator.

Se você excluir a categoria ou a tag à qual o ator está associado, isso excluirá o Ator. Excluir um ator isoladamente não é possível no momento. Eu recomendaria apenas desabilitar o Ator.

Isso pode ser possível no futuro (médio a longo prazo) se adicionarmos um ator de “Aplicação” para um Discourse inteiro. Federar tudo em um Discourse através de um único Ator provavelmente sempre será um caso de uso de nicho.

1 curtida

Hm, ok. Talvez meu entendimento das possibilidades seja diferente…

Ontem eu configurei e funcionou bem. Eu deletei os Posts no Discourse, porque eu estava apenas testando, mas os posts ainda estão online no Mastodon. Então pensei que poderia deletar a conta para deletar o conteúdo do Mastodon também.
Se eu apenas desabilitar, o conteúdo ainda fica online no Mastodon.
E se eu não puder deletar, não poderei usar este identificador com outras categorias no futuro. Talvez eu queira mudar algumas categorias no futuro, mas não poderei usá-lo com este identificador que tem xx seguidores. Então preciso criar um novo identificador e todos terão que segui-lo novamente. Não vejo nenhuma vantagem em apenas desabilitar um identificador que não preciso mais.

E: Quando desabilito um identificador, o outro também é desabilitado. Então, posso executar vários identificadores ou nenhum?

Mas é isso que eu quero, ou estou entendendo errado? Quero informar as pessoas em uma rede social sobre as discussões em todo o meu discourse e não apenas para uma tag ou categoria. Se eu executar uma seção de “Notícias”, posso entender, mas quero que todos participem das discussões, então tenho que postar tudo e não apenas uma categoria.