Ja, aber das wäre ein umfangreiches und teures Plugin.
1 „Gefällt mir“
Kann ich mit SSO oder LDAP den Login hin und her ermöglichen, ohne alle auf einen einzigen Domain-Login umstellen zu müssen?
Zum Beispiel habe ich die Foren A, B, C. Ich möchte, dass Mitglieder von Forum A sich mit ihren Forum A-Anmeldedaten in Forum B und C anmelden und posten können. Dasselbe soll für registrierte Mitglieder von B und C gelten.
Ich denke, dieser Beitrag und die folgenden sollten in ein eigenes Thema verschoben werden, da sie sich mit einer Teilmenge der hier diskutierten Funktionen befassen.
1 „Gefällt mir“
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) - Integrations - Discourse Meta könnte Ihnen helfen 
1 „Gefällt mir“
Theoretisch gäbe es neben der Erstellung eines Discourse-Plugins, das als ActivityPub Federation Protocol-Server fungiert, auch die Möglichkeit, Konten auf einem separaten ActivityPub-Server einzurichten, der das client Social API-Protokoll unterstützt, und ein Discourse-Plugin, das mit diesem Server über das Client-Protokoll kommuniziert, anstatt ein ActivityPub-Server zu sein. Dies könnte den Vorteil einer engeren Integration in bestehende ActivityPub-Knoten haben. Ich glaube jedoch nicht, dass dies einfacher zu implementieren ist als das Serverprotokoll, und es wäre für den Forenbetreiber deutlich mehr manuelle Einrichtung erforderlich, als ein Federation Protocol-Server zu sein.
In meiner Vorstellung, was implementiert werden soll, um die Möglichkeit der Benutzerinteraktion zu ermöglichen, müsste es eine Möglichkeit geben, Discourse-Benutzer-Akteure von Discourse-System-Akteuren (z. B. Kategorien) zu unterscheiden. Ich könnte mir vorstellen, dass @#slug@discourse.example.org ein Kategorie-Akteur wäre, was Raum für die spätere Hinzufügung von @username@discourse.example.org Benutzer-Akteuren ließe. Angesichts der Verbreitung von Hashtags könnte dies jedoch in der Praxis einfach nicht funktionieren.
Es wäre einfacher, sich nur auf die Punkte 1-3 zu konzentrieren, mit der Annahme, dass 4-5 darauf hinauslaufen, Discourse in einen Allzweck-ActivityPub-Server zu verwandeln, was definitiv nicht der Sinn der Sache ist.
2 „Gefällt mir“
Mastodon verwendet die folgenden regulären Ausdrücke zur Validierung:
USERNAME_RE = /[a-z0-9_]+([a-z0-9_\\.-]+[a-z0-9_]+)?/i
MENTION_RE = /(?<=\A|[^\\/[:word:]])@((#{USERNAME_RE})(?:@[[:word:]\\.\\-]+[[:word:]]+)?)/i
Soweit ich das beurteilen kann, wird USERNAME_RE auf entfernte Benutzer angewendet. Daher ist mir nicht klar, wie Discourse-Benutzer und -Kategorien auf diese Weise in separaten Namespaces untergebracht werden können. Es schließt auch normale Unterkategorien-Slugs aus. @parentcategory:subcategory@discourse.example.org funktioniert mit diesem RE ebenfalls nicht.
Ich vermute, es könnte eine optionale Subdomain @username@users.discourse.example.org geben, aber das würde mehr SSL- und DNS-Einrichtung erfordern und wahrscheinlich oft falsch konfiguriert sein. Es ist vielleicht einfach nicht lohnenswert, diesen Weg zu gehen.
1 „Gefällt mir“
Vielleicht macht es Sinn, keine Föderation mit anderen Plattformen zu schaffen, sondern eine Föderation zwischen allen Instanzen von Discourse zu schaffen, da die Anzahl der Instanzen von Discourse sehr groß ist.
2 „Gefällt mir“
Hier gibt es sicher ein riesiges Potenzial. Die Möglichkeiten und Machbarkeiten verdienen eine gründliche und nüchterne Betrachtung.
Das könnte Territorium von Xanadu sein… (Lesen Sie Jeffs Beitrag oben und folgen Sie dem Link darin.) Eine so breite Integration ist wahrscheinlich auch für die meisten Administratoren/Betreiber von Discourse-Instanzen unerwünscht. Eine formelle Umfrage unter Administratoren und Betreibern ist angebracht (im Gegensatz zu einer “Umfrage nach Traffic-Level” in Diskussionsforen).
Dies scheint eine Einladung zu Sicherheitslücken zu sein, da es die “Schlüssel zum Königreich” für jeden bietet, der die Benutzeranmeldeinformationen einer der föderierten Seiten hacken kann. Zumindest müssten diese Funktionen standardmäßig deaktiviert oder explizit als Plugins geladen werden – mit den meisten aktivierten und gesperrten Sicherheitsfunktionen. Zoom hat uns diese Lektion gelehrt, indem es seine Plattform zu Recht offen und einfach zu bedienen ließ (um schnell Benutzer zu gewinnen und zu pflegen), aber dann schnell absichern musste, sobald die Rüpel die Haustür unverschlossen fanden.
Nichtsdestotrotz wäre eine Mikro-Föderation von Seiten ein Schub für die Discourse-Implementierung. Wenn ich einen Kreis von Seiten für meine Gemeinde erstellen könnte, der denselben Benutzerpool (z. B. Kreis-/Stadtbürger) vereint, würde dies die Menschen in Kommunikation bringen und einige positive Ergebnisse in der lokalen Verwaltung und im Gemeinschaftsleben ermöglichen. Dieses gleiche Prinzip gilt auch für jedes Unternehmen, das groß genug ist, um den Verwaltungsaufwand mehrerer Discourse-Instanzen zu rechtfertigen, damit jede Abteilung ihren eigenen Discourse-Container mit einfacher Navigation zu anderen Abteilungen haben kann. *DAS wäre die Verkörperung von meta.discourse. *
Jeff, Sam und Co. [@codinghorror @sam] und/oder ihr Lenkungsausschuss müssten jedoch zuerst entscheiden, ob Discourse eine soziale Plattform oder eine Enterprise-Plattform ist. Meine Stimme ist für Enterprise, da ich dort das größte Potenzial für beide Seiten dieser Spaltung sehe. Enterprise wird die größte finanzielle Belohnung und den unmittelbaren sozialen Nutzen bringen, indem es die Fähigkeit von Unternehmen verbessert, Mitarbeiter zu unterstützen (kümmern Sie sich gut um das Unternehmen, und das Unternehmen kann sich gut um Sie kümmern). Einige dieser kommerziellen Mittel könnten dann wahrscheinlich eine social.discourse.org-Stiftung unterstützen. Es ist auch sehr wahrscheinlich, dass für ein Unternehmen nützliche Funktionen gut in den sozialen Bereich übertragen werden. Diese beiden Faktoren führen zu einem allgemeinen Win-Win.
Die beiden Domänen müssen jedoch getrennt sein, da sie so unterschiedlich sind. Und Nice-to-have-Funktionen müssen zwangsläufig die Version bevorzugen, die den primären Anwendungsfall darstellt.
Glücklicherweise fließen die Vorteile in beide Richtungen, da jeder, der an social.discourse.org interessiert ist, seine Belohnung aus den sozialen Aspekten des Gemeinschaftsaufbaus und der Möglichkeit, gemeinschaftsbezogene Aktivitäten zu verfolgen, erhält, also wird er für diese nicht-finanziellen Belohnungen arbeiten – und oft hart arbeiten. Diese social.discourse.org-Arbeit wird zwangsläufig zu Entwicklungen und Funktionen führen, die im Unternehmenskontext nützlich sind und dadurch einen Mehrwert für Enterprise Discourse Incorporated zurückgeben, im Austausch für die gemeinnützige Unterstützung der Social Discourse Foundation. Noch mehr Win-Win.
Beachten Sie, dass oben kein einziges Ausrufezeichen steht. Dies sind nur reine Fakten und Aussagen über wahrscheinliche Ergebnisse. Sehr pragmatisch.
Ich suche seit mehreren Jahren nach einer geeigneten GroupWare-Plattform für meine Unternehmen. Slack weckte kurzzeitig hohe Hoffnungen, da es für den internen Geschäftsgebrauch entwickelt wurde (und eine sehr interessante Entstehungsgeschichte hat), aber es hat nicht einmal die erste Screening-Runde überstanden. Ich bin sehr beeindruckt von Discourse und optimistisch, was es angeht.
1 „Gefällt mir“
Das ist der Sinn dieses Themas, d. h. zwischen Discourse-Instanzen.
Es wird in der OP angegeben:
2 „Gefällt mir“
Richtig, und
und
eine Mikro-Föderation von Websites wäre ein Schub
Alles on-topic, oder? 
Nicht unbedingt eine Voraussetzung. Es gibt das Plugin-Ökosystem zu berücksichtigen.
Erheblich große Funktionen werden oft als Plugins oder sogar als Theme-Komponenten (wo möglich) entwickelt, die keinen solchen administrativen Aufwand oder eine zentrale Planung beinhalten.
Das ist Teil der Schönheit des Discourse-Ökosystems.
Pavilion hat zum Beispiel Locations, Topic List Previews, Multilingual, Follow, Layouts, Custom Wizard (um nur einige zu nennen) entwickelt, und das alles ohne Rücksprache mit CDCK. Daher sind wir teilweise an dieser Diskussion beteiligt.
7 „Gefällt mir“
Gott segne unsere Plugin-Entwickler! Sie stellen großzügig Proof-of-Concept-Beispiele zur Verfügung, die im Feld getestet und für die Aufnahme in das Kernprodukt in Betracht gezogen werden können. Ihr mehrsprachiges Plugin ist ein hervorragendes Beispiel!
Bei python.org wird diese Rolle von Bibliotheksentwicklern gespielt, die manchmal „unverzichtbare“ Funktionen entwickeln, die in das Python-Kernpaket oder die Standarddistributionsbibliothek aufgenommen werden.
2 „Gefällt mir“
Ich setze mich in mehreren Themen in diesem Forum für die Unterstützung der Föderation durch Discourse ein, wie z. B. hier. Da das Fediverse jetzt Mainstream wird und Tumblr und vielleicht Flickr und ähnliche Plattformen die Föderationsunterstützung hinzufügen, stellt sich die Frage, ob Discourse ebenfalls Interesse an der Hinzufügung dieser Unterstützung hat.
Ich wurde vom Kernentwickler von Flarum kontaktiert, um Rat zur AP-Implementierung zu erhalten, und habe einige Links weitergegeben, darunter den gerade erwähnten.
PS. Auf dem Discourse-Forum von SocialHub, einer Entwickler-Community für das Fediverse, suchen wir schon seit langem nach Möglichkeiten, Teil des Fediverse zu werden, da sich separate Foren für die meisten Menschen als zu große Barriere für die Teilnahme erwiesen haben.
7 „Gefällt mir“
Ich habe mich in letzter Zeit leicht für Mastodon interessiert (genug, um einen Domainnamen zu kaufen, aber nicht um Mastodon tatsächlich zu installieren), daher habe ich ein wenig über die Authentifizierung von Discourse mit Mastodon gelesen.
Ich habe ein paar Beiträge gefunden, die darauf hindeuten, dass es schwieriger ist, als die Leute dachten. Soweit ich mich erinnere, sah es so aus, als ob ein Zuschuss für die Entwicklung eines Plugins angeboten worden wäre, der aber offenbar gescheitert ist. Meine wilde Vermutung ist, dass es sich um ein 10.000-Dollar-Problem handelt; wenn ich richtig liege, ist das die Art von Fürsprache, die Sie brauchen werden.
Bearbeiten: Aber ich habe Authentifizierung mit Föderation verwechselt.
1 „Gefällt mir“
Meine allgemeine Sorge hier ist, dass die Ideen im Allgemeinen riesig sind, es ist super schwierig, sie in kleine Teile zu zerlegen.
Ich finde die Idee der Föderation interessant. Eine mögliche konkrete Implementierung könnte sein:
- Erlaube Discourse-Administratoren, eine Kategorie zu föderieren.
- Benutzer auf Mastodon können ihr dann folgen, z. B. folgen:
announcements@meta.discourse.org - Wenn neue Ankündigungsthemen erstellt werden, wird ein neuer Beitrag mit Auszügen und einem Link zum Original föderiert.
- Wenn Benutzer auf Discourse antworten, werden neue Antworten föderiert und zugeschrieben (als Antworten auf das ursprüngliche Thema).
- Wenn jemand im Fediverse antwortet, wird ein “Schatten”-Beitrag im Thema erstellt, der dem Poster auf Mastodon zugeschrieben wird.
Etwas wie das ist zumindest klein genug, um richtig in meinen Kopf zu passen.
13 „Gefällt mir“
Das Problem mit ActivityPub ist, dass es ein leicht lesbarer offener Standard ist, aber die Implementierung macht einen noch nicht zum „Teil des Fediverse“. Es gibt eine Reihe anderer Dinge zu implementieren, und – für eine Diskussionsforen-Domäne – ein benutzerdefiniertes ActivityPub-Vokabular für Nachrichtenaustausche. Es gibt andere Projekte, von denen man „bootstrappen“ kann, und einige Bibliotheken, die man möglicherweise übernehmen kann, aber es wird tatsächlich einige bedeutende Entwicklungen geben, die erforderlich sind.
In Bezug auf die Interessenvertretung… Ich persönlich bin der Meinung, dass eine gut gemachte AP-Unterstützung dem Produkt USPs hinzufügen kann. Sich nicht bei jedem Forum anmelden zu müssen, ist eine Sache… es ist auch für mich eine Hürde. Soll ich mich bei noch einem Discourse anmelden, nur für diesen einen Beitrag, den ich hinzufügen möchte?
Aber Föderation könnte viel mehr Wert bringen. In meinem Traum-Szenario würde ich eine persönliche Discourse-Instanz installieren oder mich bei einer Instanz anmelden, die – wie Mastodon – von Anfang an komplett leer wäre. Dann würde ich sie selbst mit einer Community-Struktur füllen, basierend auf meinen Bedürfnissen und Interessen. Diese thematische Gruppe auswählen und sie unter dieser Kategorie hinzufügen, eine weitere Gruppe hinzufügen.
Update: Gekreuzter Beitrag mit @sam .. dies war eine Reaktion auf @pfaffman
5 „Gefällt mir“
Ja, das wäre ein guter Anfang. Der Lemmy-Link-Aggregator funktioniert in etwa so, indem er eine Föderation von Communities anbietet. Beachten Sie, dass die Föderation – obwohl es ein sehr wünschenswertes Merkmal wäre, breiter zu interagieren – zunächst nur zwischen Discourse-Instanzen / Mandanten implementiert werden könnte.
Nicht alles passt zu Mastodon. Es ist eine Microblogging-App, unterstützt kein Markdown (obwohl andere Fedi-Apps das tun).
Derzeit wird weiter an der föderierten Groups-Unterstützung gearbeitet. Lemmy ist ein Beispiel. Bonfire wird Google±ähnliche Kreise usw. hinzufügen.
3 „Gefällt mir“
Ja! Das ist der Workflow, den ich gerne sehen und fördern würde. 
Die Länge des Auszugs wäre praktisch konfigurierbar, wobei 0 den gesamten Artikel und nicht einen Auszug bedeutet. Beachten Sie, dass das 500-Zeichen-Limit von Mastodon willkürlich ist und nichts mit dem Fediverse, ActivityPub oder ActivityStream zu tun hat. Die Mastodon-Knoten, die ich betreibe, haben derzeit 2000-Zeichen-Limits, und das Limit von social.kernel.org beträgt 31337 Zeichen. Selbst das Standard-Mastodon mit seinem 500-Zeichen-Limit für das Schreiben von Beiträgen zeigt längere Beiträge problemlos an.
Eine geringfügige Schwierigkeit, die ich sehe, ist, dass die Benutzer- und Kategorie-Namespaces in Discourse getrennt sind, aber in ActivityPub derselbe “Actor” sind, und mindestens Mastodon hat einen ziemlich restriktiven regulären Ausdruck für die Erkennung von Actors. Bei @announcements@meta.discourse.org für die Kategorie Announcements würde dieser Kommentar als von @mcdanlj@meta.discourse.org verfasst föderiert werden.
Standardmäßig möchte ich als Discourse-Administrator den Kategorie-Slug als Actor-Namen verwenden. Ich nehme an, dass der Administrator, wenn er die Föderation für eine Kategorie einrichtet, den Actor-Namen auswählt, der standardmäßig der Slug ist und (wie ein Gruppenname) in Bezug auf die Discourse-Benutzernamen eindeutig wäre.
(Nebenbei bemerkt, ich habe mir früher Sorgen über den Mastodon-Regex zur Erkennung von Actor-Namen gemacht, aber ich denke, dass er tatsächlich nur für die @-Erwähnung von Personen verwendet wird, was hier sowieso nicht nützlich ist. Es könnte also sogar funktionieren, z. B. #documentation:admins als @documentation:admins@meta.discourse.org darzustellen, obwohl ich das definitiv mit mehreren der großen Microblogging-Systeme testen würde, einschließlich Mastodon und Pleroma.)
3 „Gefällt mir“
Ich glaube, wie das aus der Sicht eines Mastodon- oder Pleroma-Benutzers tatsächlich aussehen würde, wäre, dass @announcements@meta.discourse.org einen Themenbeitrag von z.B. @sam@meta.discourse.org boostet / rebloggt und dann auch einen Kommentarbeitrag von z.B. @mcdanlj@meta.discourse.org als Kommentar zum OP boostet/rebloggt – Weder der OP noch ein Kommentar wird tatsächlich von der Kategorie erstellt, sondern von einer Person in einer Kategorie.
Es könnte sein, dass das Plugin zunächst nur Webfinger für die Kategorie-Akteure implementiert (um ihnen folgen zu können), aber es könnte am Ende sinnvoll sein, es auch für einzelne Benutzer zu implementieren. Ich möchte vielleicht auf Mastodon @sam@meta.discourse.org folgen, um seine Beiträge und Kommentare zu sehen.
2 „Gefällt mir“
Frage: Wie ist der aktuelle Stand dieser Diskussion und die Pläne für mögliche Umsetzungen? Benötigen Sie beispielsweise Unterstützung beim Testen? Oder ist diese Frage “viel zu früh” 