Os desenvolvedores por trás do Lemmy estão fazendo um excelente trabalho nessa frente de adaptar o ActivityPub para torná-lo utilizável por softwares de comunidade:
No entanto, eles precisaram estendê-lo, então não há outro software implementando suas atividades.
Nossa implementação de federação já está completa em termos de recursos, mas até agora não nos concentramos em absoluto em cumprir a especificação do ActivityPub. Como tal, o Lemmy provavelmente não é compatível com implementações que esperam enviar e receber atividades válidas.
Acho que, se o Lemmy conseguir torná-lo compatível com o Mastodon, podemos implementar a mesma API que o Lemmy usa, mapeando
Na terminologia do ActivityPub, isso seria uma Página, então, o que faz muito sentido se considerarmos o recurso de publicação de Página: a primeira parte seria anunciada como uma Página, e qualquer resposta seria uma Nota.
Não tenho certeza sobre Categoria → Comunidade. Como o suporte ao AP e o SSO tornam isso mais fluido. Costumo ter mais de uma instância do Discourse para uma única comunidade.
Só para dizer que as seguintes instâncias do Discourse começaram a compartilhar usuários e tópicos, e o ActivityPub no Discourse seria muito útil para todos nós:
Interessante, vale notar que o Mobilizon também está usando o ActivityPub para planejamento de eventos, desenvolvido pelo Framasoft… as mesmas pessoas que criam o Peertube.
É uma pena que o Discourse não esteja avançando na implementação do ActivityPub. Sinto que há muito potencial desperdiçado aqui, considerando que existem tantas comunidades que já usam o Discourse e se beneficiariam disso desde o primeiro dia… Mesmo que ainda não saibam!
Há algum tempo, entendi com @sl007 e @hellekin que vocês não pretendem prosseguir com essa Fase 1 no curto prazo, mesmo com o financiamento do NGI0. Como um colega promotor da interoperabilidade baseada no ActivityPub, também acho isso uma pena, claro. Mas, da perspectiva do Discourse, o software de fórum líder e mais popular, há muitas forças e outras prioridades a serem consideradas e essa decisão de negócio, sob essa luz, provavelmente faz muito sentido:
Decisão: Este RFC, como proposto, simplesmente não era atraente o suficiente para receber prioridade e ser incluído no Roadmap.
O RFC adotou uma abordagem MVP com “Vamos começar criando um feed de conteúdo agregado semelhante ao Facebook entre fóruns”, conforme proposto por @Falco. É apenas uma das muitas, muitas funcionalidades que podem resultar da existência de suporte nativo ao ActivityPub de alguma forma. Argumenta-se que ter tal cronograma é uma espécie de desvio do que normalmente se encontra em um fórum e, para mim, não parece uma funcionalidade central real. Mais uma extensão acoplada e, portanto, algo desejável, mas não essencial.
Uma abordagem diferente
Com a necessidade de chegar rapidamente a um MVP de suporte ao ActivityPub fora do caminho, talvez pudéssemos seguir o processo oposto:
Ideação: Brainstorming de casos de uso de interoperabilidade e avaliação de sua viabilidade em termos de benefício comercial e USP’s.
Ou seja, quais funcionalidades seriam verdadeiramente atraentes de ter no Discourse? Ou até mesmo: Onde o Discourse poderia perder a oportunidade se não estivesse a par do que é possível?
No último post de @Falco acima, ele menciona o Lemmy, que foi construído desde o início com base em um vocabulário de Dados Vinculados dedicado que corresponde ao seu domínio de negócios. Eles têm seu MVP pronto e em produção, e agora estão buscando expandir seu conjunto de funcionalidades sobre seu próprio domínio. Isso pode incluir a federação com o outro domínio de Microblogging, onde Mastodon, Pleroma e outros têm grande sucesso.
A abordagem para a ideação pode seguir este exercício:
Exercício: Vamos imaginar como o Discourse teria sido se, desde o início, fosse baseado de forma semelhante em seu próprio domínio de negócios baseado no ActivityPub (definido como um vocabulário de Dados Vinculados).
Vamos soltar a imaginação nesta sessão de brainstorming e deixar nossa criatividade fluir livremente.
A lista de casos de uso que resultam de tudo isso pode ser interessante o suficiente em termos de sentido de negócios para se tornar parte do Roadmap, mas, se não for, ainda pode inspirar a comunidade a criar plugins e componentes, e preparar o terreno para ser construído em uma etapa posterior.
ActivityPub versus Fediverse
Percebo que há um amplo equívoco sobre o que significa ter suporte ao ActivityPub em uma aplicação. Muitas pessoas pensam que a razão para fazê-lo é tornar-se “parte do Fediverse”. E aqui o pensamento vai imediatamente para a federação com instâncias do Mastodon, ou seja, implementar interoperabilidade com (ou seja, entrar) no domínio federado de Microblogging.
Sim, esta é uma oportunidade muito atraente após ter suporte ao ActivityPub, e muitas outras aplicações como PixelFed (alternativa ao Instagram), PeerTube (alternativa ao YouTube) e também o Lemmy (alternativa ao Reddit) estão buscando fazê-lo. Eles tornam o Fediverse um lugar mais atraente para participar, e muitas inovações estão tomando forma que tornam o futuro do Fediverse realmente emocionante.
MAS…
Argumenta-se que organizações que visam grandes bases de usuários, como o Discourse, podem fazer perguntas como: “Por que eu gostaria de integrar com o Fediverse com apenas cerca de 4 milhões de usuários?” ou “Por que eu integraria Microblogging no meu software que opera em um domínio completamente diferente?”. E eles estariam certos em afirmar isso, e abrir mão da implementação do ActivityPub com base nessa premissa.
PORÉM…
Implementações do ActivityPub tratam de muito mais do que tornar-se parte da (parte de Microblogging do) Fediverse. Faz todo o sentido implementar um vocabulário de Dados Vinculados projetado exclusivamente para o seu próprio domínio de negócios e ter suas próprias instâncias de produto federadas entre si. Ou todas as instâncias do seu produto e as de concorrentes do seu setor que também adotam o mesmo vocabulário, aliás.
Um exemplo disso é o projeto ForgeFed, que visa definir padrões de interoperabilidade para forjas de código (GitHub, GitLab, Gitea, SourceHut, etc.) para implementar. Fazer isso faz um enorme sentido, especialmente para os projetos menores de forjas de código, para oferecer uma alternativa atraente ao GitHub (que se tornou excessivamente dominante como uma plataforma centralizada e cada vez mais de jardim murado). Se amplamente adotado, os desenvolvedores não precisarão mais lidar com uma infinidade de contas de forja em servidores espalhados pela internet para participar de projetos de código interessantes, abrir issues, comentar e enviar PRs.
(Observe que - conforme indicado acima - o mesmo problema que as pessoas têm com forjas de código autônomas espalhadas por toda parte é o que eu e outros também experimentamos com nossa participação em uma infinidade de comunidades Discourse.)
Oportunidade: O Discourse está em uma posição única para liderar a definição de padrões de interoperabilidade para software de fórum e moldar o padrão de forma que se alinhe perfeitamente com o conjunto de funcionalidades atual do Discourse.
Existem alguns concorrentes emergentes no seu setor, que são inovadores, adotam abordagens frescas e iteram rapidamente na adição de novas funcionalidades (vocês no Discourse sabem melhor quem são esses ). Na minha opinião, o Discourse em termos de completude de funcionalidades ainda está muito acima do que os produtos deles têm a oferecer. E vocês têm uma comunidade como nenhuma outra para ajudá-los a evoluir o produto.
Mas a oportunidade de interoperabilidade que existe agora, também pode se tornar uma ameaça. Ou os concorrentes podem aproveitar a oportunidade primeiro, ou - talvez impulsionados pela Lei de Mercados Digitais da UE - as grandes plataformas de tecnologia criem algo com sobreposição no domínio de software de fórum. Em ambos os casos, seria mais difícil para o Discourse alinhar-se a esse padrão e ter a voz mais autoritária no design de sua especificação.
TL;DR
Isso se tornou um post mais longo do que eu pretendia. Desculpe por isso
Em resumo, estou argumentando que, dada a posição atual sobre ter suporte ao ActivityPub, pode ser prudente passar de um foco de curto prazo semelhante a um MVP para uma avaliação mais ampla do que a interoperabilidade do ActivityPub poderia trazer ao Discourse em termos de USP’s e posicionamento a longo prazo. Ou seja, elaborar o caso de negócios da adoção do ActivityPub, começando com uma fase de ideação.
(Como isso é melhor configurado - desde que vocês estejam interessados - eu deixo no meio, mas pode começar simplesmente com um novo tópico AP tendo um wiki de resumo dos casos de uso coletados no topo e pessoas discutindo ideias de casos de uso no tópico)
Arnold, o que impede você de encomendar isso como um plugin, se você tem acesso a financiamento?
Às vezes, desenvolver e validar funcionalidades em um plugin ajuda a promover uma adoção mais ampla e no núcleo.
Um bom exemplo disso são as Pré-visualizações da Lista de Tópicos (um plugin). As miniaturas incorporadas foram originalmente apenas adicionadas de forma improvisada. Agora, o núcleo do Discourse suporta miniaturas nativamente, como resultado da popularidade demonstrada.
@angus e eu construímos isso até um ponto em que o núcleo decidiu que a ideia estava madura e popular o suficiente para ser implementada por eles mesmos.
Essa abordagem reduz riscos e pode ajudar a superar barreiras práticas antes de entrar no roteiro do núcleo.
Já havia uma proposta de financiamento no marketplace, que alguém da equipe do Discourse assumiu, mas a proposta aceita acabou sendo descartada. A oferta ainda está aberta, mas exige que uma entidade europeia a assuma. Pode ser um membro europeu do The Pavilion. Fico feliz em ajudar com a proposta, pois reaproveitar a existente certamente agilizará o processo rumo ao financiamento bem-sucedido.
Seu link para o Dansup me lembra os plugins ActivityPub do WordPress disponíveis nos últimos anos. Semelhante a esta pessoa, tenho usado esses plugins no meu próprio WordPress desde o início: plugin ActivityPub e o agora bastante inativo Pterotype.
Seu site se torna um ator no fediverso, como @latest@meta.discourse.org. Você pode adicionar uma descrição para sua conta, e o ícone do seu site será exibido como sua foto de perfil federada. As postagens aparecerão na federação para outros usuários, e os comentários deles aparecerão em nosso site, exibindo o ícone e o nome de usuário federados deles.
Exemplo de resposta:
@doug@mastodoon.social:
Tenho gostado muito de acompanhar esse tópico sobre federação! Continuem com o bom trabalho.
Muito bom, pois é exibido no WordPress como apenas mais um comentário, mas também é um verdadeiro comentário federado via ActivityPub.
edição: Confira o Prismo, uma variação federada do Lemmy/Reddit construída em Ruby / PostgreSQL, que pode se alinhar mais de perto a um design para o Discourse.
Desenvolver plugins é certamente uma opção muito viável. Em meu exercício, propus pensar “como se” o Discourse tivesse sido construído desde o início com a federação em mente, como forma de investigar com uma mente aberta todas as possibilidades, sem olhar — por enquanto — o que é possível/viável/não viável em relação ao produto atual e ao ecossistema. Cada uma das ideias que surgirmos pode perfeitamente ser implementada como plugins.
Estou trabalhando principalmente em diferentes aspectos deste Fediverso. Minha resposta foi tanto como um grande fã e promotor do Discourse quanto como defensor do Fediverso, que — com toda a sua inovação — vejo como a oportunidade para se tornar o cenário de mídia social de próxima geração, impulsionado pelas pessoas e mais humano.
Obrigado, muito apreciado. É um ótimo pensamento, e espero que este tópico inspire qualquer desenvolvedor de plugins a descobrir as possibilidades.
Sim, adoro. Esses projetos podem ser uma ótima inspiração para o que poderia estar no tipo de Discourse sobre o qual @merefield está falando, ao focar no suporte ao Fediverso.
Concluímos no passado que a federação entre Discourse e Discourse é totalmente sem interesse; já temos interoperabilidade básica por meio do OpenGraph, o que parece ser suficiente. Se alguém tiver um caso de uso convincente, gostaria de ouvir, mas ainda não vi nenhum apresentado. Vocês só falaram sobre as possibilidades técnicas e não sobre quais recursos de produto essa tecnologia realmente habilita.
Ótimos pontos! Se o objetivo é que uma postagem em um fórum seja sincronizada com uma postagem em outro fórum Discourse… você já pode usar matterbabble com matterbridge.
Não, você tem razão. É isso que eu estava propondo que fizéssemos (em meu TL;DR com “elaborar o caso de negócios para a adoção do ActivityPub, começando por uma fase de ideação”).
Como essa proposta de brainstorm vai muito além do tema deste tópico e também não se refere a um único recurso ou RFC, mas sim a uma Visão, criei um tópico separado na categoria #community:
Por favor, veja uma proposta para estruturar um caso de uso comercial que poderia servir como ponto de partida para convencer @riking do interesse em implementar suporte ao ActivityPub no Discourse @merefield, você gostaria de se juntar à conversa lá? – Seria bem direto, é claro, se o AP fosse suportado!
Peço desculpas se isso estiver incorreto, mas por que não converter feeds RSS para ActivityPub usando o feed2toot? Vejo que ele oferece suporte ao Mastodon e ao Pleroma. O Discourse gera feeds RSS para categorias e grupos por padrão. O suporte a RSS também está integrado ao Hubzilla e ao Friendica.
Você poderia fornecer mais informações sobre o que está impedindo o Discourse de investigar mais a fundo os recursos de federação e quais seriam as áreas interessantes onde a comunidade do ActivityPub poderia fornecer mais informações e suporte?