Sim, mas seria um plugin extenso e caro.
1 curtida
Com SSO ou LDAP, posso permitir o login de um lado para o outro sem ter que mover todos para um único login de domínio?
Por exemplo, tenho os fóruns A, B, C. Gostaria que os membros do fórum A pudessem fazer login e postar com suas credenciais do fórum A nos fóruns B e C. O mesmo deve acontecer com os membros registrados de B e C.
Eu acho que esta postagem e as seguintes deveriam ir para um tópico próprio, pois se referem a um subconjunto dos recursos discutidos aqui.
1 curtida
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta pode ser útil para você 
1 curtida
Em teoria, suponho que outra possibilidade além de criar um plugin do Discourse que funcione como um servidor do Protocolo de Federação ActivityPub seria configurar contas em um servidor ActivityPub separado que honre o protocolo client da API Social, e ter um plugin do Discourse falando o protocolo do cliente para esse servidor, em vez de ser um servidor ActivityPub. Isso poderia ter o benefício de uma integração mais próxima com nós ActivityPub existentes. Mas não acho que seja mais fácil de implementar do que o protocolo do servidor, e seria muito mais trabalho de configuração manual para o operador do fórum do que ser um servidor de protocolo de federação.
Na minha ideia do que implementar, para permitir a possibilidade de interação do usuário, teria que haver uma maneira de distinguir atores-usuário-discourse de atores-sistema-discourse (por exemplo, categorias). Eu poderia imaginar que @#slug@discourse.example.org seria um ator de categoria, deixando espaço para a adição posterior de atores-usuário @username@discourse.example.org. Mas dada a prevalência de hashtags, isso pode simplesmente não funcionar na prática.
Seria mais simples focar apenas nos pontos 1-3, sob a teoria de que 4-5 estão se aproximando de tentar transformar o Discourse em um servidor ActivityPub de propósito geral, o que definitivamente não é o objetivo.
2 curtidas
O Mastodon usa as seguintes expressões regulares para validação:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<=\^|[^\\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\\.\\-]+[[:word:]]+)?)/i
Pelo que pude apurar, USERNAME_RE é aplicado a usuários remotos, então não está claro como ter usuários e categorias do Discourse em namespaces separados dessa forma. Também descarta slugs de subcategorias normais. @parentcategory:subcategory@discourse.example.org também não funcionará com essa RE.
Acho que poderia haver um subdomínio opcional @username@users.discourse.example.org, mas isso exigiria mais configuração de SSL e DNS e provavelmente seria mal configurado muitas vezes. Talvez não valha a pena ir por aí.
1 curtida
Talvez faça sentido não criar uma federação com outras plataformas, mas sim criar uma federação entre todas as instâncias do discourse, já que o número de instâncias do discourse é muito grande.
2 curtidas
Há um enorme potencial aqui, com certeza. As possibilidades e a viabilidade justificam uma consideração completa e sóbria.
Isso pode ser território de Xanadu… (Leia o post de Jeff acima e siga o link nele.) Tal integração ampla provavelmente também é indesejável para a maioria dos administradores/operadores de instâncias do Discourse. Uma pesquisa formal com administradores e operadores está em ordem (em oposição a “pesquisa por nível de tráfego” em fóruns de discussão).
Isso parece um convite a hacks de segurança, pois oferece as “chaves do reino” a qualquer um que consiga hackear as credenciais de usuário de qualquer um dos sites federados. No mínimo, esses recursos teriam que ser desativados por padrão ou explicitamente carregados como plugins - com a maioria dos recursos de segurança ativados e bloqueados. O Zoom nos ensinou essa lição ao deixar corretamente sua plataforma aberta e fácil de usar (para ganhar e cultivar usuários rapidamente na fase de ramp-up), mas depois teve que bloquear rapidamente assim que os malfeitores encontraram a porta da frente destrancada.
No entanto, uma microfederação de sites seria um impulso para a implementação do Discourse. Se eu pudesse criar um círculo de sites para meu município que unisse o mesmo pool de usuários (cidadãos do condado/cidade, por exemplo), isso colocaria as pessoas em comunicação e poderia permitir alguns resultados positivos na governança local e na vida comunitária. O mesmo princípio também se aplica a qualquer empresa grande o suficiente para justificar o custo administrativo de múltiplas instâncias do Discourse, para que cada divisão possa ter seu próprio contêiner Discourse com navegação fácil para outras divisões. ESSE seria o corpo do meta.discourse.
Jeff, Sam e Cia. [@codinghorror @sam] e/ou seu Comitê de Direção precisariam primeiro decidir, no entanto, se o Discourse é uma plataforma social ou uma plataforma corporativa. Meu voto é para corporativa porque vejo o maior potencial lá para ambos os lados dessa divisão. O corporativo produzirá a maior recompensa financeira e benefício social imediato, melhorando a capacidade das empresas de apoiar funcionários (cuidar bem do negócio e o negócio pode cuidar bem de você). Alguns desses fundos comerciais poderiam então apoiar uma fundação social.discourse.org. Também é muito provável que recursos úteis para uma empresa se transfiram bem para o domínio social. Esses dois fatores criam um ganho geral para todos.
Os dois domínios precisam ser distintos, no entanto, porque são muito diferentes. E os recursos “legais de ter” necessariamente precisarão favorecer a versão que for o caso de uso principal.
Felizmente, os benefícios fluem em ambas as direções, pois qualquer pessoa interessada em social.discourse.org obtém sua recompensa dos aspectos sociais da construção de comunidade e da capacidade de buscar atividades relacionadas à comunidade, portanto, trabalhará - e muitas vezes trabalhará duro - por essas recompensas não financeiras. Esse trabalho social.discourse.org levará inevitavelmente a desenvolvimento e recursos que são úteis no contexto corporativo e, assim, retornará valor para a Enterprise Discourse Incorporated em troca de suporte sem fins lucrativos para a Fundação Social Discourse. Ainda mais ganha-ganha.
Note que não há um único ponto de exclamação acima. Estes são apenas fatos simples e declarações de resultados prováveis. Muito pragmático.
Tenho procurado uma plataforma GroupWare adequada para minhas empresas há vários anos. O Slack inspirou brevemente grandes esperanças, pois foi desenvolvido para uso interno em negócios (e tem uma história de origem muito interessante), mas nem sequer passou pela primeira triagem. Estou muito impressionado com o Discourse e otimista em relação a ele.
1 curtida
Esse é o objetivo principal deste tópico, ou seja, entre instâncias do Discourse.
Está declarado no OP:
2 curtidas
Certo, e
e
uma microfederação de sites seria um impulso
Tudo dentro do tópico, não é? 
Não necessariamente um pré-requisito. Existe o ecossistema de plugins a ser considerado.
Recursos significativamente grandes são frequentemente desenvolvidos como plugins ou até mesmo Componentes de Tema (onde possível) que não envolvem tal sobrecarga administrativa nem planejamento centralizado.
Essa é parte da beleza do ecossistema Discourse.
O Pavilion, por exemplo, criou Locations, Topic List Previews, Multilingual, Follow, Layouts, Custom Wizard (para citar alguns) tudo sem consulta à CDCK. Daí, em parte, nosso envolvimento nesta discussão.
7 curtidas
Deus abençoe nossos desenvolvedores de plug-ins! Eles fornecem generosamente exemplos de prova de conceito que podem ser testados em campo e considerados para inclusão no produto principal. Seu plug-in multilíngue é um excelente exemplo!
No python.org, essa função é desempenhada por desenvolvedores de bibliotecas que, às vezes, criam funções “preciso disso” que são aceitas para inclusão no pacote principal do Python ou na biblioteca de distribuição padrão.
2 curtidas
Tenho defendido que o Discourse adicione suporte de federação em vários tópicos neste fórum, como aqui. Com o Fediverso se tornando popular agora, e o Tumblr e talvez o Flickr e outros adicionando suporte de federação, a questão é se o Discourse tem mais interesse em adicionar suporte também.
Fui contatado pelo desenvolvedor principal do Flarum para obter conselhos sobre a implementação do AP e passei alguns links de volta, entre eles o que acabei de mencionar.
PS. No fórum SocialHub, uma comunidade de desenvolvedores para o Fediverso, estamos há muito tempo procurando como podemos fazer parte do Fediverso, pois fóruns separados têm se mostrado uma barreira muito grande para a maioria das pessoas participar.
7 curtidas
Tenho me interessado um pouco pelo Mastodon ultimamente (o suficiente para comprar um nome de domínio, mas não para instalar o Mastodon), então li um pouco sobre a autenticação do Discourse com o Mastodon.
Encontrei alguns posts sugerindo que é mais difícil do que as pessoas pensavam. Se bem me lembro, parecia que uma bolsa havia sido oferecida para desenvolver um plugin, mas parece que não deu certo. Minha suposição é que é um problema de US$ 10.000; se eu estiver certo, é o tipo de defesa que você vai precisar.
Editar: mas eu estava confundindo autenticação com federação.
1 curtida
Minha preocupação geral aqui é que as ideias são geralmente enormes, é super difícil dividi-las em pequenas partes.
Eu acho a ideia de federação interessante. Uma possível implementação concreta poderia ser:
- Permitir que administradores do Discourse federem uma categoria.
- Usuários no Mastodon podem então segui-la, por exemplo, seguir:
announcements@meta.discourse.org - Quando novos tópicos de anúncio são criados, uma nova postagem é federada com um trecho e link para o original.
- À medida que os usuários respondem no Discourse, novas respostas são federadas e atribuídas (como respostas ao tópico original).
- Quando alguém no fediverso responde, uma postagem “sombra” é feita no tópico atribuída ao postador no Mastodon.
Algo assim é pelo menos pequeno o suficiente para caber adequadamente na minha cabeça.
13 curtidas
O problema com o ActivityPub é que ele é um padrão aberto de fácil leitura, mas implementá-lo não o torna “parte do Fediverso” ainda. Há um monte de outras coisas a serem implementadas e - para um domínio de Fóruns de Discussão - um vocabulário ActivityPub personalizado para trocas de mensagens. Existem outros projetos para “inicializar” e algumas bibliotecas para possivelmente adotar, mas haverá, de fato, um desenvolvimento significativo necessário.
Em termos de defesa… Eu pessoalmente sinto que, quando bem feito, o suporte AP pode adicionar USPs ao produto. Não ter que se inscrever em todos os fóruns é uma coisa… é uma barreira para mim também. Devo me inscrever em mais um Discourse, apenas para esta única postagem que quero adicionar?
Mas a federação pode trazer muito mais valor. No meu cenário dos sonhos, eu instalaria um Discourse pessoal ou me inscreveria em uma instância que - como o Mastodon - estaria completamente vazia no início. Então eu a preencheria com a estrutura da comunidade, com base nas minhas necessidades e interesses. Escolher este grupo temático e adicioná-lo nesta categoria, adicionar outro grupo.
Atualização: Postado cruzado com @sam .. isso foi em reação a @pfaffman
5 curtidas
Sim, isso seria um ótimo começo. O agregador de links do Lemmy funciona um pouco assim, onde oferece uma federação de Comunidades. Note que - embora seria muito bom interagir de forma mais ampla - a federação poderia ser implementada apenas entre instâncias / tenants do Discourse no início.
Nem tudo se encaixa no Mastodon… é um aplicativo de Microblogging, não suporta markdown (embora outros aplicativos fedi façam isso).
Atualmente, o suporte para Groups federados está sendo trabalhado. Lemmy é um exemplo. Bonfire adicionará círculos semelhantes ao Google+, etc.
3 curtidas
Sim! Este é o fluxo de trabalho que eu adoraria ver. E promover. 
O comprimento do trecho seria convenientemente configurável, com 0 significando o artigo inteiro em vez de um trecho. Observe que o limite de 500 caracteres do Mastodon é arbitrário e não tem nada a ver com o Fediverse, ActivityPub ou ActivityStream. Os nós do Mastodon que executo atualmente têm limites de 2000 caracteres, e o limite do social.kernel.org é de 31337 caracteres. Mesmo o Mastodon padrão, com seu limite de 500 caracteres para escrever posts, ainda exibe posts mais longos sem problemas.
Uma pequena dificuldade que vejo é que os namespaces de usuário e categoria são separados no Discourse, mas são o mesmo “Ator” no ActivityPub, e pelo menos o Mastodon tem uma expressão regular bastante restritiva para reconhecer Atores. Dado @announcements@meta.discourse.org para a categoria Announcements, este comentário seria federado como escrito por @mcdanlj@meta.discourse.org
Por padrão, como administrador do Discourse, eu gostaria de usar o slug da categoria como o nome do Ator. Suponho que, quando o administrador configurar a federação para uma categoria, ele selecione o nome do Ator, que seria o padrão para o slug, e seria (como um nome de grupo) único em relação aos nomes de Usuário do Discourse.
(A propósito, eu costumava me preocupar com a regex do Mastodon para reconhecer nomes de atores, mas acho que ela é realmente usada apenas para mencionar pessoas, o que não é valioso aqui de qualquer maneira. Então, pode até funcionar ter, digamos, #documentation:admins representado como @documentation:admins@meta.discourse.org, embora eu definitivamente quisesse testar isso com vários dos principais sistemas de microblogging, incluindo definitivamente Mastodon e Pleroma.)
3 curtidas
Eu acho que o que isso realmente pareceria da perspectiva de, digamos, um usuário do Mastodon ou Pleroma, seria que @announcements@meta.discourse.org impulsionaria / repostaria uma postagem de tópico de, digamos, @sam@meta.discourse.org e, em seguida, também impulsionaria/repostaria uma postagem de comentário de, digamos, @mcdanlj@meta.discourse.org como um comentário para o OP — Nem o OP nem um comentário são realmente feitos pela categoria, são feitos por uma pessoa, em uma categoria.
Pode ser que o plugin inicialmente implementasse apenas webfinger para os Atores da categoria (para poder segui-los), mas pode fazer sentido, no final, implementá-lo também para usuários individuais. Eu poderia razoavelmente, no Mastodon, querer seguir @sam@meta.discourse.org para ver suas postagens e comentários.
2 curtidas
Pergunta: qual é o status atual desta discussão e os planos para possíveis implementações? Você precisa de algum suporte de teste, por exemplo? Ou essa pergunta é “muito cedo” 