It has nothing to actually do with Discourse so you’ll want to ask the feed2toot project. Good luck.
Thanks James for the information
Keith
Matrix commenting might be interest, since it is able to federate / “bridge” with other chat systems. Not ActivityPub based, but it is both decentralized and currently supported to x-post to Matrix via Chat Integration plugin.
“Por que protocolos federados não funcionam”
“o valor da liberdade”
Não acho isso muito convincente. Resume-se a:
- XMPP é uma bagunça
- A federação não resolve preocupações de privacidade em torno de metadados
- A afirmação “A lista de contatos do dispositivo é agora a rede social”.
O primeiro pode ser verdade sem ser geral, e o artigo nem sequer tenta fazer um argumento geral, além de “olhe para os modelos de issue do GitHub”, o que… parece mais uma reclamação sobre como isso é implementado do que um ponto significativo.
O segundo parece perfeitamente verdadeiro, mas também não é a única razão para a federação, e para mim não parece um bloqueio — o perfeito inimigo do bom, etc.
E a terceira coisa… não acho que isso seja verdade, exceto em um sentido restrito, e nesse sentido, não é realmente o que eu quero. Sim, posso ter mais de 20 aplicativos de mensagens em uma pasta no meu telefone e eles compartilham principalmente uma lista de contatos… mas isso não é “problema resolvido!” para mim!
do final da resposta de Matthew (Matrix) para Moxie (Signal)
É verdade que, se você está escrevendo um aplicativo de mensagens otimizado para privacidade a qualquer custo, a abordagem de Moxie é uma maneira de fazer isso. No entanto, isso acaba sendo um mundo perversamente fechado - uma rede fechada, onde clientes não oficiais são banidos, sem plataforma para construir, sem padrões abertos, e você acaba colocando todos os seus ovos em uma única cesta, confiando no passado, presente e futuro do Signal para manter seus valores, permanecer e, de alguma forma, evitar compromissos e censura… apesar de provavelmente ser o alvo de ataque de maior valor na internet.
Simplesmente, esse não é um mundo em que quero viver.
Devemos todo o sucesso da Internet (nem mesmo a Web) à abertura, interoperabilidade e descentralização. Declarar que abertura, interoperabilidade e descentralização são “muito difíceis” e não valem o esforço ao construir uma solução de mensagens é jogar fora todo o potencial da vitalidade, criatividade e inovação que vem de uma rede aberta. Claro, você pode acabar com um aplicativo de mensagens superprivado - mas um que começa a cheirar alarmantemente como um jardim murado como a iniciativa Internet.org do Facebook, ou uma palavra-chave da AOL, ou o AMP do Google.
Portanto, continuamos a aceitar de bom grado o desafio de Moxie de provar que ele está errado - para mostrar que é possível e imperativo criar uma plataforma de mensagens descentralizada e aberta que (se você usar aplicativos e servidores confiáveis) pode ser tão segura e protetora de metadados quanto o Signal… e, de fato, mais ainda, dado que você pode executar seu servidor fora da rede, e não precisa se registrar com um número de telefone, e no futuro pode nem precisar de um servidor.
Além disso, a postagem de Moxie é de 2016, apenas dois anos após a introdução do protocolo Matrix e dois anos antes do lançamento do ActivityPub.
Portanto, embora seja bom que eu possa hospedar meu próprio e-mail, essa também é a razão pela qual meu e-mail não é criptografado de ponta a ponta e provavelmente nunca será.
Desde então, o Delta.chat apareceu, baseando-se em protocolos de e-mail e no Autocrypt, o que torna essa afirmação inquestionavelmente errada: o e-mail é E2EE - e já era antes, com o OpenPGP, mas, de fato, o Autocrypt torna muito mais fácil para as pessoas usarem criptografia de ponta a ponta.
Seria totalmente viável para o Discourse implementar o Autocrypt e certamente ajudaria a alcançar o melhor dos dois mundos: centralizado e federado. Mas, é claro, se o Discourse adotasse usuários encenados como ponto de entrada para a federação entre instâncias do Discourse em primeiro lugar, faria muito mais sentido discutir a federação. Os interesses de Moxie na época eram justificar por que ele não deixaria as pessoas implantarem seus próprios servidores Signal. E sim, há muitos protocolos em desenvolvimento para resolver todos os tipos de problemas, incluindo a atualização de clientes.
Isso parece uma solicitação de recurso separada
você se importaria de criar outro tópico detalhando isso ou já existe um sobre isso?
Acho que já propus isso há algum tempo em uma discussão semelhante. Deixe-me encontrar…
- ActivityPub Support: Phase 1 RFC - #7 by hellekin
- ActivityPub Support: Phase 1 RFC - #45 by hellekin
Sinta-se à vontade para consolidar a proposta em um novo tópico de recursos.
Precisamos reinventar o USENET…
Aqui está outro artigo de Mathew sobre Matrix, uma plataforma federada. Citação principal:
É como se o USENET tivesse um filho com a Web!
![]()
Falar sobre e2e em uma discussão de federação não faz sentido algum. Alguém pode mover essas respostas para um novo tópico, por favor.
Talvez o Protocolo Lemmy seja um bom começo.
Você já tem o modo de lista de e-mails, e ele funciona de forma semelhante (exceto que é sobre Fedi).
Há um evento no Zoom 2022-04-28T20:00:00Z
No mundo atual das mídias sociais, vimos plataformas darem errado ao enfrentar os flagelos da desinformação e do trolling. Em regimes autoritários, plataformas inteiras são facilmente bloqueadas. E sim, um bilionário pode comprar uma plataforma e mudar as regras.
As mídias sociais descentralizadas (ou P-2-P), onde não há uma entidade controladora central, seriam melhores? Como você remove posts prejudiciais quando não há um centro de comando central? Os fundadores de algumas das principais redes de mídia social descentralizadas, de Matrix a Manyverse e a nova iniciativa Bluesky, explicam as possibilidades. Com demonstrações de como usar essas alternativas peer-to-peer para Facebook, Slack e Twitter.
Sobre Nossos Palestrantes:
Jay Graber é CEO da Bluesky, a iniciativa financiada por Jack Dorsey e Twitter, “para desenvolver e impulsionar a adoção em larga escala de tecnologias para conversação pública aberta e descentralizada.”Matthew Hodgson é Co-fundador do https://matrix.org/. Matrix é uma rede aberta para comunicação segura e descentralizada com mais de 40 milhões de usuários.
Andre Staltz é Criador do Manyverse, uma “rede social sem as coisas ruins”, gratuita e de código aberto, construída no protocolo peer-to-peer SSB.
Este evento faz parte de uma série de workshops apresentados pelo Metropolitan New York Library Council, Internet Archive, DWeb e Library Futures. Saiba mais aqui: https://metro.org/decentralizedweb
Por favor, revise nosso Código de Conduta, nossa Declaração sobre Pontos de Vista e detalhes sobre Serviços de Intérprete aqui: https://metro.org/code-of-conduct
Isso. Possivelmente também integrando ações remotas de "Curtir".
Notei que o Fediverso se tornou notavelmente mais ativo e populoso desde que Elon Musk iniciou sua oferta de aquisição do Twitter.
Nas instâncias do Discourse que administro (três no momento), eu adoraria poder usar o Mastodon (no meu caso) para poder seguir e "impulsionar" para um público maior, para tornar as informações em minhas instâncias mais acessíveis e visíveis para uma multidão de outros que possam se importar. Todas as minhas instâncias visam expandir o escopo do conhecimento público sobre vários tópicos, e um rico suporte de compartilhamento através da integração do ActivityPub seria útil para atingir esse objetivo.
Converter RSS para ActivityPub não ajudaria muito.
Se este fosse o meu projeto, seria em fases e começaria de forma simples:
- Apenas publicação: Categorias como Atores, incluindo respostas a tópicos devidamente encadeadas com
inReplyTo. Estas são enviadas aos seguidores em uma base por postagem ao mesmo tempo que, por exemplo, as postagens são encaminhadas para integrações de chat. Isso exigiria a publicação (pelo menos de algumas) categorias como Atores e o armazenamento de Seguidores para cada Ator. Esses Atores de categoria não seguiriam nem curtiram. Nenhum acesso autenticado seria usado. Honraria Atividades de Curtir, Bloquear e Desfazer. Talvez também um Ator para todo o servidor, para seguir facilmente toda a atividade no servidor. - Bidirecional mínimo: Opcionalmente, aceitar ações remotas de
Curtir. - Mais bidirecional: Interagir com ações de
Anunciar(ou seja, compartilhar, republicar, impulsionar), seja adicionando-as como curtidas ou exibindo-as separadamente. - Interação do usuário: Opcionalmente, suporte a webfinger para usuários, para permitir seguir os usuários como Atores para ver todas as suas postagens. Mais opcionalmente, limitado por grupo (eu poderia querer limitar ao TL2, por exemplo), a capacidade de se envolver em MPs com Atores externos do ActivityPub. Isso poderia possivelmente implementar a coleção de posts curtidos do usuário (pelo menos os públicos) na coleção
liked. - Bidirecional textual: Opcionalmente, respostas de não membros via ActivityPub aceitas como comentários — mas esta é complicada porque refletiria ingenuamente de volta como uma nova postagem, então os seguidores a veriam duas vezes. Provavelmente exigiria posts marcados com sua referência externa e não postados nas caixas de entrada dos seguidores.
Eu explicitamente não gostaria de suportar "seguir" Atores do ActivityPub de dentro do Discourse; transformar o Discourse em um clone do (por exemplo) Mastodon parece um grande desperdício em todos os aspectos. Na linguagem da especificação do ActivityPub, não seria um "Servidor Federado compatível com ActivityPub" e tudo bem. Além disso, a porção cliente do protocolo simplesmente não tem lugar neste plano.
Encontrada esta discussão sobre implementações do ActivityPub em Rails. Talvez valha a pena continuar a discussão lá. ![]()
Alguma sugestão de como posso federar 4 fóruns? Eles são bem grandes (100k, 20k, 50k, 20k membros). Total 200k.
Você não pode federar. Você pode configurar autenticação SSO ou LDAP personalizada, que todos os usuários podem compartilhar para acessar cada fórum com credenciais comuns.
Você também pode tentar criar um plugin para integrá-los.