Oui, mais ce serait un plugin coûteux et complexe.
1 « J'aime »
Avec SSO ou LDAP, puis-je autoriser la connexion dans les deux sens sans avoir à déplacer tout le monde vers un seul identifiant de connexion de domaine ?
Par exemple, j’ai les forums A, B et C. J’aimerais que les membres du forum A puissent se connecter et poster avec leurs identifiants du forum A sur les forums B et C. Il en va de même pour les membres enregistrés de B et C.
Je pense que ce message et les suivants devraient faire l’objet d’un sujet distinct car ils concernent un sous-ensemble des fonctionnalités discutées ici.
1 « J'aime »
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta pourrait vous être utile 
1 « J'aime »
En théorie, je suppose qu’une autre possibilité, outre la création d’un plugin Discourse fonctionnant comme un serveur ActivityPub Federation Protocol, serait de configurer des comptes sur un serveur ActivityPub distinct qui respecte le protocole client Social API, et qu’un plugin Discourse utilise le protocole client pour communiquer avec ce serveur, plutôt que d’être un serveur ActivityPub. Cela pourrait avoir l’avantage d’une intégration plus étroite avec les nœuds ActivityPub existants. Mais je ne pense pas que ce soit plus facile à implémenter que le protocole serveur, et cela demanderait beaucoup plus de travail de configuration manuelle pour l’opérateur du forum que d’être un serveur de protocole de fédération.
Dans mon idée de ce qu’il faut implémenter, pour permettre la possibilité d’interaction utilisateur, il faudrait un moyen de distinguer les acteurs-utilisateurs de Discourse des acteurs-systèmes de Discourse (par exemple, les catégories). Je pourrais imaginer que @#slug@discourse.example.org serait un acteur de catégorie, laissant la place à l’ajout ultérieur d’acteurs-utilisateurs @username@discourse.example.org. Mais compte tenu de la prévalence des hashtags, cela pourrait simplement ne pas fonctionner en pratique.
Il serait plus simple de se concentrer uniquement sur les points 1 à 3 en partant du principe que les points 4 et 5 s’approchent trop de la tentative de transformer Discourse en un serveur ActivityPub à usage général, ce qui n’est certainement pas le but.
2 « J'aime »
Mastodon utilise les expressions régulières suivantes pour la validation :
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?\u003c=^|[^\\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\\.\\-]+[[:word:]]+)?)/i
D’après ce que je peux comprendre, USERNAME_RE est appliqué aux utilisateurs distants, il n’est donc pas clair comment avoir des utilisateurs et des catégories Discourse dans des espaces de noms séparés de cette manière. Cela exclut également les slugs de sous-catégories normaux. @parentcategory:subcategory@discourse.example.org ne fonctionnera pas non plus avec cette expression régulière.
Je suppose qu’il pourrait y avoir un sous-domaine optionnel @username@users.discourse.example.org, mais cela nécessiterait plus de configuration SSL et DNS et serait probablement mal configuré souvent. Cela ne vaut peut-être tout simplement pas la peine d’aller dans cette direction.
1 « J'aime »
Il est peut-être logique de ne pas créer de fédération avec d’autres plateformes, mais de créer une fédération entre toutes les instances de Discourse, étant donné que le nombre d’instances de Discourse est très important.
2 « J'aime »
Il y a un potentiel énorme ici, c’est certain. Les possibilités et les faisabilités méritent une considération approfondie et sobre.
Cela pourrait relever du territoire de Xanadu… (Lisez le post de Jeff ci-dessus et suivez le lien qu’il contient.) Une intégration aussi large serait probablement indésirable pour la plupart des administrateurs/opérateurs d’instances Discourse. Une enquête formelle auprès des administrateurs et opérateurs est de mise (par opposition à une “enquête par niveau de trafic” dans les forums de discussion).
Cela ressemble à une invitation aux piratages de sécurité car cela expose les “clés du royaume” à quiconque peut pirater les identifiants d’utilisateur de l’un des sites fédérés. À tout le moins, ces fonctionnalités devraient être désactivées par défaut ou explicitement chargées en tant que plugins - avec la plupart des fonctionnalités de sécurité activées et verrouillées. Zoom nous a enseigné cette leçon en laissant à juste titre sa plateforme ouverte et facile à utiliser (pour gagner et cultiver rapidement des utilisateurs lors de la montée en puissance), mais a ensuite dû la verrouiller rapidement une fois que les voyous ont trouvé la porte d’entrée déverrouillée.
Néanmoins, une micro-fédération de sites serait un coup de pouce à l’implémentation de Discourse. Si je pouvais créer un cercle de sites pour ma municipalité qui unisse le même pool d’utilisateurs (citoyens du comté/de la ville par exemple), cela mettrait les gens en communication et pourrait permettre des résultats positifs dans la gouvernance locale et la vie communautaire. Ce même principe s’applique également à toute entreprise suffisamment grande pour justifier les frais généraux d’administration de plusieurs instances Discourse afin que chaque division puisse avoir son propre conteneur Discourse avec une navigation facile vers les autres divisions. CE serait l’incarnation de meta.discourse.
Jeff, Sam et Co. [@codinghorror @sam] et/ou leur comité de pilotage devraient d’abord décider, cependant, si Discourse est une plateforme sociale ou une plateforme d’entreprise. Mon vote va à l’entreprise car j’y vois le plus grand potentiel pour les deux côtés de cette scission. L’entreprise produira la plus grande récompense financière et le bénéfice social immédiat en améliorant la capacité des entreprises à soutenir leurs employés (prendre bien soin de l’entreprise et l’entreprise pourra bien prendre soin de vous). Une partie de ces fonds commerciaux pourrait probablement ensuite soutenir une fondation social.discourse.org. Il est également très probable que les fonctionnalités utiles à une entreprise se répercutent bien dans le domaine social. Ces deux facteurs créent une situation gagnant-gagnant globale.
Les deux domaines doivent être distincts, cependant, car ils sont si différents. Et les fonctionnalités “agréables à avoir” devront nécessairement favoriser la version qui est le cas d’utilisation principal.
Heureusement, les avantages coulent dans les deux sens car toute personne intéressée par social.discourse.org obtient sa récompense des aspects sociaux de la création de communauté et de la capacité à poursuivre des activités liées à la communauté, travaillera donc - et souvent dur - pour ces récompenses non financières. Ce travail social.discourse.org mènera inévitablement au développement et à des fonctionnalités utiles dans le contexte de l’entreprise et retournera ainsi de la valeur à Enterprise Discourse Incorporated en échange d’un soutien à but non lucratif de la Fondation Social Discourse. Encore plus gagnant-gagnant.
Notez qu’il n’y a pas un seul point d’exclamation ci-dessus. Ce ne sont que des faits simples et des déclarations de résultats probables. Très pragmatique.
Je cherche une plateforme de GroupWare adaptée pour mes entreprises depuis plusieurs années. Slack a brièvement suscité de grands espoirs car il a été développé pour un usage interne en entreprise (et a une histoire d’origine très intéressante), mais il n’a même pas passé le premier tour de sélection. Je suis très impressionné par Discourse et optimiste à son sujet.
1 « J'aime »
C’est tout l’intérêt de ce sujet, c’est-à-dire entre les instances de Discourse.
Il est indiqué dans l’OP :
2 « J'aime »
D’accord, et
et
une micro-fédération de sites serait un coup de pouce
Tout est dans le sujet, n’est-ce pas ? 
Pas nécessairement un prérequis. Il y a l’écosystème des plugins à considérer.
Les fonctionnalités d’une taille significative sont souvent développées sous forme de plugins ou même de composants de thème (lorsque c’est possible) qui n’impliquent pas une telle surcharge administrative ni une planification centralisée.
C’est une partie de la beauté de l’écosystème Discourse.
Pavilion, par exemple, a créé des emplacements, des aperçus de listes de sujets, multilingue, suivre, des mises en page, un assistant personnalisé (pour n’en nommer que quelques-uns) sans consultation avec CDCK. Par conséquent, en partie, notre implication dans cette discussion.
7 « J'aime »
Que Dieu bénisse nos développeurs de plug-ins ! Ils fournissent généreusement des exemples de preuves de concept qui peuvent être testés sur le terrain et envisagés pour inclusion dans le produit principal. Votre plug-in multilingue en est un excellent exemple !
Sur python.org, ce rôle est joué par les développeurs de bibliothèques qui créent parfois des fonctions « indispensables » qui sont acceptées pour inclusion dans le package principal de Python ou la bibliothèque de distribution standard.
2 « J'aime »
Je plaide pour que Discourse ajoute le support de la fédération dans plusieurs sujets de ce forum, comme ici. Alors que le Fediverse devient populaire, et que Tumblr et peut-être Flickr et d’autres ajoutent le support de la fédération, la question est de savoir si Discourse est plus intéressé à ajouter également ce support.
J’ai été contacté par le développeur principal de Flarum pour obtenir des conseils sur l’implémentation d’AP et j’ai renvoyé certains liens, dont celui mentionné précédemment.
PS. Sur le forum SocialHub, une communauté de développeurs pour le Fediverse, nous cherchons depuis longtemps comment nous pouvons faire partie du Fediverse, car les forums séparés se sont avérés être une barrière trop importante pour que la plupart des gens puissent participer.
7 « J'aime »
Je me suis récemment intéressé de près à Mastodon (assez pour acheter un nom de domaine, mais pas pour installer Mastodon), j’ai donc lu quelques articles sur l’authentification de Discourse avec Mastodon.
J’ai trouvé quelques messages suggérant que c’était plus difficile que prévu. Si ma mémoire est bonne, il semblait qu’une subvention avait été offerte pour développer un plugin, mais elle semble avoir échoué. Ma folle supposition est qu’il s’agit d’un problème à 10 000 $ ; si j’ai raison, c’est le genre de plaidoyer dont vous aurez besoin.
Modification : mais je confondais authentification et fédération.
1 « J'aime »
Ma préoccupation générale ici est que les idées sont généralement énormes, il est très difficile de les décomposer en petits morceaux.
Je trouve l’idée de fédération intéressante. Une implémentation concrète possible pourrait être :
- Permettre aux administrateurs de Discourse de fédérer une catégorie.
- Les utilisateurs sur Mastodon pourront alors la suivre, par exemple suivre :
announcements@meta.discourse.org - Lorsque de nouveaux sujets d’annonces sont créés, un nouveau message est fédéré avec un extrait et un lien vers l’original.
- Lorsque les utilisateurs répondent sur Discourse, les nouvelles réponses sont fédérées et attribuées (en tant que réponses au sujet original).
- Lorsque quelqu’un sur le fediverse répond, un message “fantôme” est créé sur le sujet, attribué à l’auteur sur Mastodon.
Quelque chose comme ça est au moins assez petit pour tenir correctement dans ma tête.
13 « J'aime »
Le problème avec ActivityPub est que c’est un standard ouvert facile à lire, mais l’implémenter ne vous rend pas encore « partie du Fediverse ». Il y a un tas d’autres choses à implémenter, et - pour un domaine de forums de discussion - un vocabulaire ActivityPub personnalisé pour les échanges de messages. Il existe d’autres projets à « amorcer » et quelques bibliothèques à adopter éventuellement, mais il y aura effectivement un développement significatif nécessaire.
En termes de plaidoyer… Je pense personnellement que, lorsqu’il est bien fait, le support AP peut ajouter des arguments de vente uniques (USP) au produit. Ne pas avoir à s’inscrire à chaque forum est une chose… c’est aussi une barrière pour moi. Dois-je m’inscrire à un Discourse de plus, juste pour cette seule publication que je veux ajouter ?
Mais la fédération pourrait apporter beaucoup plus de valeur. Dans mon scénario de rêve, j’installerais un Discourse personnel ou m’inscrirais à une instance, qui - comme Mastodon - serait complètement vide au début. Ensuite, je la remplirais moi-même avec une structure communautaire, en fonction de mes besoins et intérêts. Choisir ce groupe thématique, et l’ajouter sous cette catégorie, ajouter un autre groupe.
Mise à jour : Publication croisée avec @sam .. ceci était en réaction à @pfaffman
5 « J'aime »
Oui, ce serait un bon début. L’agrégateur de liens Lemmy fonctionne un peu comme ça, où il offre une fédération de Communautés. Notez que - bien que ce serait très utile d’interagir plus largement - la fédération pourrait être implémentée juste entre des instances / locataires Discourse au début.
Tout ne rentre pas dans Mastodon… c’est une application de microblogging, elle ne supporte pas le markdown (bien que d’autres applications fedi le fassent).
Actuellement, un support plus fédéré des Groupes est en cours de développement. Lemmy en est un exemple. Bonfire ajoutera des cercles similaires à Google+, etc.
3 « J'aime »
Oui ! C’est le flux de travail que j’aimerais voir. Et promouvoir. 
La longueur de l’extrait serait commodément configurable, 0 signifiant l’article entier plutôt qu’un extrait. Notez que la limite de 500 caractères de Mastodon est arbitraire et n’a rien à voir avec le Fediverse, ActivityPub ou ActivityStream. Les nœuds Mastodon que j’exploite ont actuellement des limites de 2000 caractères, et la limite de social.kernel.org est de 31337 caractères. Même Mastodon par défaut, avec sa limite de 500 caractères pour l’écriture des messages, affiche correctement les messages plus longs.
Une difficulté mineure que je vois est que les espaces de noms utilisateur et de catégorie sont séparés dans Discourse mais sont le même « Acteur » dans ActivityPub, et au moins Mastodon a une expression régulière assez restrictive pour reconnaître les Acteurs. Étant donné @announcements@meta.discourse.org pour la catégorie Announcements, ce commentaire serait fédéré comme étant rédigé par @mcdanlj@meta.discourse.org
Par défaut, en tant qu’administrateur Discourse, je voudrais utiliser le slug de la catégorie comme nom d’Acteur. Je suppose que lorsque l’administrateur configure la fédération pour une catégorie, il sélectionne le nom d’Acteur, qui serait par défaut le slug, et serait (comme un nom de groupe) unique par rapport aux noms d’utilisateurs Discourse.
(Soit dit en passant, je m’inquiétais auparavant de l’expression régulière de Mastodon pour reconnaître les noms d’acteurs, mais je pense qu’elle n’est en fait utilisée que pour mentionner les gens, ce qui n’est pas utile ici de toute façon. Il pourrait donc même fonctionner d’avoir, par exemple, #documentation:admins représenté comme @documentation:admins@meta.discourse.org bien que je voudrais absolument tester cela avec plusieurs des principaux systèmes de microblogging, y compris certainement Mastodon et Pleroma.)
3 « J'aime »
Je pense que ce à quoi cela ressemblerait réellement du point de vue d’un utilisateur de Mastodon ou de Pleroma, ce serait que @announcements@meta.discourse.org boost / reblog un sujet posté par, disons, @sam@meta.discourse.org et ensuite boost/reblog également un commentaire posté par, disons, @mcdanlj@meta.discourse.org comme commentaire à l’OP — Ni l’OP ni un commentaire n’est réellement fait par la catégorie, il est fait par une personne, dans une catégorie.
Il se pourrait que le plugin ne puisse initialement implémenter que webfinger pour les Acteurs de catégorie (afin de pouvoir les suivre), mais cela pourrait avoir du sens à la fin de l’implémenter également pour les utilisateurs individuels. Je pourrais raisonnablement, sur Mastodon, vouloir suivre @sam@meta.discourse.org pour voir ses posts et commentaires.
2 « J'aime »
Question : quel est l’état actuel de cette discussion et les plans pour d’éventuelles implémentations ? Avez-vous besoin d’aide pour les tests, par exemple ? Ou cette question est-elle « beaucoup trop prématurée » 