Olá, @rishabh, @riking, @codinghorror,
(Sim, há um TL;DR abaixo)
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)