Apenas uma observação de que estamos atualmente nesta etapa
5 curtidas
Isso está ótimo!
Recentemente, configurei um servidor Discourse para nossa CoSocial Co-op, que executa um servidor Mastodon. Acabei configurando o plugin OAuth2 para que aceitemos apenas logins do nosso servidor Mastodon → https://members.cosocial.ca (instalação nova e simples, apenas “prova de OAuth”).
Minha pergunta / solicitação de recurso é que seja possível preparar/mesclar atores do Mastodon em contas do Discourse, para que, quando as contas no Mastodon responderem, elas possam ser vinculadas / pertencentes à conta do Discourse associada.
Como o Lemmy Não Faz Isso
Documentei como o Lemmy não faz isso – você pode interagir via Mastodon, e uma conta é criada no Lemmy para essa conta do Mastodon, mas você não pode realmente fazer login e usar os recursos de primeira classe do Lemmy com sua conta do Mastodon.
4 curtidas
Isso está na pauta…
E já está na fila para revisão
3 curtidas
Ótimo. Parece que os usuários do meu plugin Discourse OAuth precisariam "confirmar novamente" para interagir com este plugin AP.
Acho que está perfeitamente bem nesta fase, apenas quero sinalizar o servidor OAuth como mais um ponto, desde que não entre em conflito. O "bom de ter" seria "se OAuth com servidor Mastodon, então vincular automaticamente a identidade do ator AP". Totalmente futuro e também exclusivo para esse tipo de configuração!
(E desculpas por não ter aberto a página para olhar essa parte! Ótimo!)
1 curtida
O PR adicionando este conjunto de recursos agora foi mesclado.
Como Angus observou acima, o próximo passo é a verificação do usuário via tokens OAuth.
2 curtidas
Os problemas que vi anteriormente com o markdown bruto aparecendo também parecem estar afetando o meta. Estou seguindo @feature@meta.discourse.org e, há algumas horas, esta postagem foi criada e federada desse Ator:
Isso apareceu para mim no Mastodon com falhas assim:
No Elk, parece assim; um pouco melhor:
Acabei de começar a seguir @feature@meta.discourse.org na minha conta pura do Mastodon agora para testar isso, mas é claro que é tarde demais para ver esta postagem específica lá. 
Portanto, o markdown incorporado que vi anteriormente da minha própria instalação não era um banco de dados ruim, ou se era, era um problema de banco de dados compartilhado com o meta e, portanto, provavelmente não associado aos meus testes.
2 curtidas
Sim, consigo reproduzir isso, vejo uma saída semelhante em uma instância do Mastodon e no Ivory (aplicativo iOS).
2 curtidas
Não tenho certeza se isso está funcionando corretamente. O plugin está ativado e criei um tópico em uma categoria com ActivityPub ativado, mas não estou vendo o selo ao lado das postagens (e minha tentativa de seguir o ator da categoria no activitypub parece ter falhado, já que está agindo como um servidor faria se os follows precisassem ser aprovados manualmente por um usuário).
Acabei de notar que o mesmo problema parece ter ocorrido com Feature no Meta.
1 curtida
Seria ótimo entender o objetivo final das restrições, sem se preocupar com o estado intermediário.
Por exemplo, acho que vi uma referência em um PR de que a alteração de proprietários de postagens será bloqueada se o plugin estiver ativado. Como administrador, tenho que usar esse recurso em raras ocasiões (por exemplo, ao alterar o moderador de uma categoria, faço do novo moderador principal da categoria o proprietário da categoria sobre a postagem fixa). Espero que, no final, isso apareça como uma exclusão e uma nova postagem, ou até mesmo apenas ignorado, em vez de bloquear a alteração de propriedade.
Também me pergunto sobre mover postagens entre categorias. Tenho que fazer isso com razoável frequência, especialmente quando novos usuários postam na categoria errada. Eu esperaria ingenuamente que isso resultasse em um ator de categoria removendo seu impulso e o novo ator de categoria adicionando um impulso, mas não excluindo a postagem subjacente, de modo que, se outra pessoa tivesse visto e impulsionado uma postagem, seu impulso não desapareceria apenas porque o impulso do ator da categoria desapareceu.
Geralmente, seria muito útil saber o que você espera que seja proibido quando este plugin for adicionado, após a conclusão do desenvolvimento de recursos atualmente especificado, independentemente das restrições atualmente em vigor.
1 curtida
@hello-smile6 Estou vendo a mesma coisa com o plugin atualizado hoje:
Não vejo configuração para isso, então presumo que seja um bug.
2 curtidas
Obrigado pelo relatório adicional. Estou investigando isso.
Obrigado pelo relatório, estamos investigando isso.
Eu entendo seu ponto de vista, no entanto
-
Enquanto o plugin está em desenvolvimento ativo, tentar explicar as coisas dessa forma seria improdutivo, pois a explicação pode mudar.
-
Existem muitos cenários e casos extremos diferentes que o plugin já lida, para que eu explique cada um narrativamente neste momento levaria muito tempo (ou seja, efetivamente fazendo este longo post várias vezes). Já existem mais de 400 especificações diferentes para o plugin.
-
No entanto, as restrições são frequentemente explicadas narrativamente nos comentários nas PRs e commits, que acho que você já está lendo.
Isso foi discutido em profundidade na PR
Restringei a alteração de proprietários de posts e a criação de wikis de posts, mesmo para administradores, em tópicos AP. Isso ocorre porque posts AP remotos precisam reter a fidelidade com o original e ambas as ações podem potencialmente quebrar essa fidelidade.
Pode haver uma maneira de fazer a federação funcionar com wikis e alteração de proprietários de posts, no entanto, sugiro que adicionemos isso como um “recurso” em uma PR futura, pois envolverá multiplicar ou alterar o ator associado a um objeto que é federado em várias plataformas. Acho que nunca poderemos permitir a alteração de proprietários de posts importados de ap (notas), pois a associação ator/objeto não é de propriedade do Discourse, mas do local onde o conteúdo foi criado. Para dar uma analogia ilustrativa, neste contexto, a exclusão de um post associado a uma nota importada é menos uma “exclusão” em si, do que uma escolha de não mostrar uma Nota.
Existem muitos cenários diferentes envolvendo a movimentação de posts. Lidarei com o específico que você mencionou por enquanto, nomeadamente mover um post entre duas categorias diferentes habilitadas para ActivityPub.
Você está assumindo que a única vez que um post é movido entre categorias é quando o post é postado inicialmente na categoria errada, e a movimentação ocorre logo após a criação do post. E se, 4 meses após um post ter sido feito, você mover esse post para outra categoria porque deseja consolidar uma certa coleção de posts em um novo tópico em uma categoria diferente? Faria sentido enviar um “Desfazer” para o boost original nesse cenário?
Isso depende se estamos falando da configuração do Primeiro Post ou da configuração do Tópico Completo. Para o primeiro, adicionaremos um botão para que o primeiro post seja publicado manualmente para lidar especificamente com o cenário de movimentação de categoria. Para o último, adicionar automaticamente um boost pode fazer sentido, vou pensar mais sobre isso.
Eu entendo seu ponto de vista, no entanto, já compartilhei muitos detalhes sobre o estado final na especificação da Fase 2 acima. Além dessa especificação, e colocando isso da forma mais gentil possível, existem muitos casos de uso e cenários para eu discutir todos em profundidade com você, e depois também com a equipe do Discourse.org, enquanto trabalho neles 
Atualizarei o OP com uma visão geral do comportamento esperado assim que a Fase 2 for concluída.
1 curtida
Não consigo reproduzir este problema. Acabei de seguir feature@meta.discourse.org de uma conta Mastodon de teste e não vi nenhum erro (nem no Mastodon nem no Discourse).
1 curtida
Pode estar relacionado à instância que eu segui, esta instância faz algo incomum?
Oh céus, na minha tentativa de fazer uma pergunta clara, soei como se estivesse pedindo muito trabalho. Peço desculpas por ter me comunicado mal. Agradeço a resposta atenciosa.
Era isso que eu pretendia perguntar, não atualizações detalhadas contínuas neste tópico. O meu “depois” em “depois que o desenvolvimento de recursos atualmente especificado for concluído” foi para indicar quando a clarificação seria valiosa, não para pedir que você descrevesse o estado futuro. Minha pergunta foi formulada de forma ambígua. Desculpe por isso!
É isso que eu realmente queria entender: O objetivo final, em termos gerais, é restringir o Discourse apenas ao que o ActivityPub canônico suporta, ou é federar de uma experiência nativa irrestrita do Discourse para o fediverso em uma base de melhor esforço? Minha experiência passada com integrações do Discourse me levou a esperar o melhor esforço; agora entendo que seu plano é buscar a fidelidade em vez disso, ao custo da funcionalidade do Discourse, e não apenas como uma medida temporária durante o desenvolvimento.
Não estou assumindo isso. Por que quatro meses fariam diferença aqui? Está recém em uma categoria federada, por que isso não faria a categoria federada impulsioná-la? Eu, pelo menos, teria esperado ingenuamente que isso acontecesse. Frequentemente vejo pessoas impulsionando postagens com muitos meses de idade, então não conheço nenhuma razão específica pela qual isso seria diferente.
E sim, acho que faria sentido enviar um Desfazer para o boost original. Isso parece ser comum. (De fato, Desfazer um boost e depois um novo boost parece ser um mecanismo típico para “impulsionar” conteúdo; não relacionado a este propósito, mas ilustrando que Desfazer em um boost é comumente usado e, portanto, não deve causar problemas a outras implementações do ActivityPub.)
Vejo a mesma coisa agora para feature@meta.discourse.org de mastodon.cloud, que acho que está executando o Mastodon puro.
1 curtida
Pessoalmente, não penso em nenhuma das duas formas. O Discourse.org definirá a agenda geral aqui, mas, de forma geral, as decisões são tomadas com base em como funciona e o que é prático. Se houver uma maneira sensata e sustentável de permitir alterações de autoria em todas as postagens, independentemente da proveniência, então ótimo.
Apenas focando no desfazimento do impulsionamento original, esse Undo específico não parece ter um propósito? É também, argumentavelmente, um pouco surpreendente em alguns cenários, como meu exemplo tentou mostrar. A intenção da mudança de categoria pode não ser reverter (Undo) a “descoberta” original do conteúdo. Pode ser para alterar a organização do conteúdo posteriormente por um motivo diferente.
Em outras palavras, aplicar uma reversão automática do Announce original em uma mudança de categoria no Discourse funciona em alguns cenários, mas não em outros. E mesmo em cenários onde parece fazer mais sentido, o Announce original não está realmente causando nenhum dano. Portanto, buscando os princípios de menor dano e menor surpresa, parece que simplesmente deixar o Announce original em vigor faz mais sentido. Desculpe se estou perdendo alguma coisa.
Para pensar nisso de outro ângulo, não acho certo pensar nas atividades de Announce de um Categoria Ator como sinônimas da função taxonômica das Categorias em si. Um Announce é a forma como um ator de Categoria compartilha conteúdo com seus seguidores, mas não é uma taxonomia em si. É uma forma de o conteúdo ser descoberto no Fediverso. Não acho que precise haver uma relação de 1:1 entre categorias e as atividades de Announce dos atores de categoria.
3 curtidas
Ah. Então é realmente uma questão para a equipe. 
Isso também faz sentido. Concordo, não há muito valor em desfazer o impulso.
Então é um sinal acionado por borda; significaria “uma postagem acabou de entrar nesta categoria, seja por ser escrita ou movida para a categoria”. Isso é conceitualmente simples.
Eu então pensaria em mudar a autoria de uma postagem da mesma forma. Seria o novo ator criando uma nova atividade para a postagem do novo autor, e não há necessidade particular de fazer nada com a atividade antiga feita sob o antigo autor, porque o antigo autor não estaria escrevendo nenhuma edição e não deveria ser creditado por essas novas mudanças. Eles não excluíram realmente sua postagem no Discourse, então excluir a atividade do autor original não refletiria necessariamente alguma verdade fundamental. Mas o que havia sido postado antes pelo ator do antigo autor seria o que eles haviam escrito, e não haveria razão para excluir essas postagens. E se alguém seguisse o link de volta para o Discourse, veria o conteúdo e a autoria atuais, com (dadas permissões suficientes) a visualização do histórico de edições.
A mesma lógica se aplica a wikis. Elas aparecem no Discourse sob autoria singular, mas permitem que outros escrevam. As atualizações de outros autores não são amplamente atribuídas (a menos que você tenha permissão suficiente para ler o histórico). Não é realmente significativo se essa atribuição é exibida por um avatar na visualização da web dentro do Discourse ou por um ator activitypub associado a uma atividade; o resultado final é a atribuição apresentada ao leitor humano em um ou outro pipeline de renderização.
1 curtida
Hm, não tenho certeza se concordo. O resultado final disso serão duas Notas idênticas no Fediverso, ambas de autoria de Atores diferentes, ambas ainda visíveis em várias plataformas. Para uma nova pessoa que acessa esse conteúdo pela primeira vez, ela verá o mesmo conteúdo de autoria de pessoas diferentes. Inversamente, quando você muda um autor no Discourse, você essencialmente reescreve a história; para uma nova pessoa que acessa o conteúdo pela primeira vez, você apenas vê o novo autor. Há uma diferença aí, você não acha?
Não tenho certeza se entendi completamente. Você está dizendo que todas as edições na postagem da wiki, por qualquer usuário, devem ser tratadas como atividades de Atualização padrão atribuídas ao Ator original (ou seja, a pessoa que a postou)?
Note que este é o assunto deste PR, acompanhado de notas explicativas.
4 curtidas