Ja, Discourse könnte etwas Ähnliches mit seinem Kommentar-Widget tun. Unter anderem könnte es helfen, die Unbeholfenheit zu verringern, die manche Menschen empfinden, wenn sie ein Forum starten, das nur wenige aktive Benutzer hat: AI sockpuppet accounts to jumpstart my community?. Neue Discourse-Sites könnten Blogbeiträge nutzen, um ihr Forum zu bewerben und zu bestücken. Das ist jetzt schon irgendwie möglich, aber wenn Benutzer direkt aus dem Widget heraus kommentieren könnten, würde der Prozess nahtloser ablaufen.
3 „Gefällt mir“
Ein einfaches, mit Discourse verbundenes Kommentarformular auf der WordPress-Seite, damit Besucher nicht zuerst zu Discourse gehen und sich dort ein Konto erstellen müssen, bevor sie einen Kommentar posten können, würde die Reibung verringern und das Engagement fördern, zumindest für Publisher wie mich.
Für meinen Anwendungsfall wäre es ideal, wenn ein Kommentator seinen Kommentar einfach mit einem Namen und einer E-Mail-Adresse hinterlassen könnte. Dies könnte dann verwendet werden, um einen gestuften Benutzer in Discourse zu erstellen und ihn einzuladen, sich vollständig anzumelden, um die Konversation fortzusetzen, ohne ihn daran zu hindern, seinen Kommentar zu hinterlassen.
Wir stellen fest, dass die zusätzliche Reibung bei der Erstellung eines Kontos, um einen Kommentar zu einem veröffentlichten Artikel zu hinterlassen, es schwierig macht, das Engagement zu steigern und letztendlich die Community in unserem Forum zu vergrößern. Als beispielsweise ein Autor nach unserem Kommentarbereich gefragt wurde (unter Verwendung der aktuellen Discourse-WordPress-Integration), gab er uns das folgende Feedback:
Was den Gesprächsbereich betrifft: Jetzt, wo Sie es erwähnen … ich erinnere mich, das gesehen zu haben. Und zu der Zeit dachte ich tatsächlich, ich würde es vorerst vergessen, da es zeitaufwändig schien, sich anzumelden. Das ist ein starker Beweis dafür, wie die meisten Leute über diesen Prozess denken würden. Ich bin normalerweise grenzwertig besessen davon, Kommentare zu meinen Texten zu sehen. Ich erinnere mich, dass ich innerlich gelacht und gesagt habe: „Ich bin wohl nicht besessen genug, um mich gerade jetzt damit zu befassen.“ Idealerweise würden Sie Kommentare für alle ohne Anmeldeprozess offen lassen. Aber jede Vereinfachung/Erleichterung würde das Engagement dort verbessern. Kommentare wie diese sind normalerweise eine Impulsaktion. Wenn die Leute auch nur im Geringsten behindert werden, werden sie tendenziell weiterziehen und sich nicht die Zeit nehmen.
3 „Gefällt mir“
Ich habe gerade neulich darüber nachgedacht. Seltsamerweise habe ich die WordPress-Kommentare auf meinen Blog-Posts vermisst, weil es für die Leute so schnell schien, loszulegen, sehr niedrige Einstiegshürde.
Trotz eines wirklich einfachen Anmeldevorgangs müssen die Leute jetzt, wenn sie einen Beitrag kommentieren wollen, eine neue Seite besuchen. Ich denke, das Überschreiten dieser Schwelle kann zu mühsam sein. Fast so, als ob ich A kommentieren möchte, aber ich muss B besuchen, um A zu kommentieren, und dann zu A zurückkehren, um den Kommentar zu sehen. Es würde sich natürlicher anfühlen, A direkt unter A zu kommentieren.
Ich mag die Idee, Benutzer zu stufen. Ich kann mir vorstellen, das vielleicht zusammenzuhacken, indem das WordPress-Kommentarformular eine E-Mail an das Discourse-Forum sendet und dann auf diese Weise einen Benutzer stuft, obwohl ich mir vorstelle, dass es auf diese Weise komplexer wird, es vollständig zu integrieren.
3 „Gefällt mir“
Ich glaube, das war früher möglich, aber ich bin mir ziemlich sicher, dass Discourse jetzt den „From Header“ der E-Mail mit seinem Return Path vergleicht. Wenn diese nicht übereinstimmen, wird die E-Mail abgelehnt. (Wenn Discourse den Return Path nicht überprüft, könnte das Kommentarsystem leicht missbraucht werden – jede E-Mail-Adresse könnte in das Formular eingegeben werden.)
Es gibt ein paar Möglichkeiten, wie das Problem von Discourse als Kommentarsystem angegangen werden könnte. Ich denke, der beste Ansatz wäre, dass Discourse seinen Kommentar-Embed-iframe verbessert, damit Benutzer damit als authentifizierte Discourse-Benutzer interagieren können. Wenn das nicht möglich ist, könnte eine eingebettete Discourse-Kommentar-Web-App entwickelt werden. Das wäre ein interessantes Projekt, aber ich möchte sicher sein, dass Discourse keine ähnliche Funktionalität über seinen eingebetteten Kommentar-iframe bereitstellt, bevor ich es zu weit verfolge.
Es gibt auch einige mögliche WordPress-spezifische Lösungen. Die einfachste wäre, WordPress-Kommentare und das WP Discourse-Plugin zu aktivieren. Das Risiko besteht darin, dass dies die Aktivität im Discourse-Forum verringern würde. Ich denke, es gäbe jedoch Möglichkeiten, dies in der WordPress-Benutzeroberfläche zu unterstützen – zum Beispiel, indem auf verwandte Konversationen verlinkt wird, die auf Discourse stattfanden.
Es wäre auch möglich, etwas Spezifisches für WordPress-Sites zu entwickeln, die als Discourse SSO-Provider fungieren. Darüber habe ich in früheren Beiträgen in diesem Thema geschrieben. Um dies gut zu machen, wären möglicherweise erhebliche Änderungen am WP Discourse-Plugin erforderlich. Es sei denn (ich denke laut nach):
Was ich mit dem obigen Screenshot zeigen möchte, ist, dass für den Fall einer WordPress-Site, die der Discourse SSO-Provider ist, Kommentare mit dem Discourse-Kommentar-iframe angezeigt werden könnten. Kommentare könnten über ein Formular erstellt werden, das an die Discourse-API gesendet wird. Dies erfordert möglicherweise einige Änderungen am Discourse-Kommentar-iframe, um sicherzustellen, dass er aktualisiert wird, wenn ein neuer Kommentar hinzugefügt wird, erfordert jedoch nicht, dass Benutzer mit ihm als authentifizierte Discourse-Benutzer interagieren können.
4 „Gefällt mir“
Wenn ich das richtig verstehe, wäre die Idee also, dass sich der Kommentator auf der WordPress-Seite registriert, dann über den eingebetteten Discourse-iFrame einen Kommentar hinterlässt, der im Thema auf Discourse gepostet wird, dann die Anzeige auf WordPress aktualisiert wird, sodass er sofort erscheint.
Die WordPress-Registrierung würde die E-Mail validieren, nehme ich an. Dies würde aber auch erfordern, dass WordPress als Discourse SSO-Anbieter wechselt – machbar, aber in gewisser Weise bedauerlich, da es die Hürde auf die andere Seite verlagert für Leute, die sich vielleicht nur für das Forum anmelden möchten.
Ich neige dazu, dem zuzustimmen, was Sie hier gesagt haben:
Wenn es sogar möglich wäre, sich direkt im iFrame zu registrieren oder zumindest vorbereitet zu werden, sodass man mit dem Kommentar fortfahren könnte (der vielleicht erst nach E-Mail-Validierung gepostet wird), wäre das für mich eine Lösung, die Benutzerfreundlichkeit und Sicherheit ausbalanciert.
2 „Gefällt mir“
Ja, das hast du richtig verstanden. Wenn WordPress der SSO-Anbieter ist, ist das Problem, Benutzern das Kommentieren von Discourse-Themen zu ermöglichen, nicht allzu schwer zu lösen. Der knifflige Teil, was die Arbeit mit dem aktuellen Stand des WP Discourse-Plugins betrifft, ist die Frage, wie die Kommentare auf WordPress angezeigt werden sollen – derzeit spiegelt der WP Discourse-Kommentarbereich nicht die Antworten des Discourse-Themas wider. Stattdessen wird eine Auswahl der „besten“ Kommentare angezeigt.
Es wäre möglich, das WP Discourse-Plugin zu aktualisieren, um diesen Anwendungsfall zu behandeln, aber um es richtig zu machen, müsste die Art und Weise, wie es Discourse-Kommentare behandelt, komplett neu geschrieben werden. Es ist nicht meine Entscheidung, aber ich denke, dass die Verbesserung des Discourse-Kommentar-Iframes eine bessere Zeitverwendung wäre.
5 „Gefällt mir“
Ich wollte nur meine Stimme dafür abgeben, dass ich mir diese Funktion wünsche.
Es wäre wirklich gut, wenn sich Benutzer auf WP einfach registrieren/anmelden und direkt unter einem Beitrag auf WP kommentieren könnten, ohne zum Forum navigieren zu müssen, damit das Ganze mehr wie ein Kommentarsystem wirkt. Ihr Kommentar würde sowohl unter dem Beitrag als auch im erstellten Diskurs-Thread erscheinen. Und sie haben immer die Wahl, nahtlos entweder in Discourse, WordPress oder beidem zu posten. Ich habe keine Ahnung, wie das erreicht werden könnte, aber das wäre eine wirklich nahtlose Integration von WP-Kommentaren mit Discourse, die sich weniger sperrig anfühlt und zweifellos die Anzahl der Kommentare, die wir derzeit mit dem vorhandenen Plugin erhalten, erheblich verbessern würde.
3 „Gefällt mir“
Vielleicht das:
Aber es übernimmt meines Wissens nach komplett das Login von Discourse.
Würde das es Benutzern ermöglichen, Kommentare direkt unter einem WordPress-Beitrag zu posten und diesen Beitrag automatisch im entsprechenden Discourse-Thread zu befüllen?
Ich arbeite gerade daran. Die erste Version ist für eine Headless-WordPress-Site, die das Remix-Framework für ihr Frontend verwendet. Sobald das erledigt ist, werde ich eine Version für reguläre WordPress-Sites erstellen. Es wird wahrscheinlich ein Plugin sein, das das WP Discourse-Plugin erweitert. Ich hoffe, dass das meiste, was ich auf der Headless-WordPress-Site mache, auf reguläre WordPress-Sites übertragen werden kann, aber es könnten einige Kompromisse erforderlich sein.
Benutzern zu erlauben, direkt von einer externen Website aus zu kommentieren, ist trivial zu implementieren. Die Hauptanforderung ist, dass die externe Website Zugriff auf die Anmeldeinformationen des Benutzers für Discourse hat. Dies kann entweder geschehen, indem die externe Website als DiscourseConnect-Anbieter für Discourse verwendet wird, oder indem Discourse als DiscourseConnect-Anbieter für die externe Website konfiguriert wird.
Im zweiten Szenario – bei dem die externe Website nicht der DiscourseConnect-Anbieter für Discourse ist – muss der Benutzer beim ersten Mal, wenn er von der externen Website aus kommentieren möchte, auf einen Link klicken, um sein Konto auf der externen Website mit seinem Discourse-Konto zu verknüpfen (oder sich auf Discourse zu registrieren, falls er dies noch nicht getan hat). Aus Sicht des Benutzers kann dies ziemlich nahtlos erfolgen.
Die obige Änderung lässt das Ganze jedoch nicht wie ein reguläres Kommentarsystem wirken. Eine normale Erwartung an ein Kommentarsystem ist, dass man alle Kommentare lesen und mit ihnen interagieren kann. Das WP Discourse-Plugin zeigt nur eine Auswahl von Kommentaren an, die von einer speziellen Route von Discourse abgerufen werden. Es bietet keine Funktionalität zur Interaktion mit Kommentaren.
Die schwierigen Teile des Problems sind:
- Paginierung aller Kommentare eines Themas auf WordPress, unter Berücksichtigung, dass es Tausende davon geben könnte
- Bereitstellung einer Benutzeroberfläche, die dem Benutzer Feedback gibt, wo er sich in einer langen Kommentarliste befindet
- Ermittlung, wie Kommentare angezeigt werden, die direkte Antworten auf andere Kommentare sind. (Die Konvention von Discourse hierfür stimmt nicht mit der Art und Weise überein, wie die meisten Kommentarsysteme mit Antworten umgehen.)
- Ermöglicht Benutzern, direkt auf einen Kommentar zu antworten, einen Kommentar zu mögen, eigene Kommentare zu bearbeiten usw.
- Umgang mit Kommentaren, die auf Discourse erstellt wurden und Inhalte oder Markup enthalten, die auf der externen Website nicht einfach gerendert oder mit ihnen interagiert werden können. Zum Beispiel Oneboxes, Umfragen…
- Bereitstellung einer Möglichkeit, Kommentare nach neuesten, ältesten, besten usw. zu filtern…
All dies muss erreicht werden, ohne den Server der externen Website übermäßig zu belasten, zu viele API-Anfragen an Discourse zu stellen oder zu viel Speicher auf dem Gerät des Benutzers zu verbrauchen (das Ziel ist es, ein leichtgewichtiges Kommentarsystem zu schaffen). Es ist machbar, aber es ist nichts, das einfach in den bestehenden WP Discourse-Code übernommen werden kann, ohne ihn erheblich zu verändern.
4 „Gefällt mir“
Schön zu hören, dass Sie damit begonnen haben!
Nur ein Gedanke: Da ein Teil der Idee darin besteht, die Hürden für Kommentare zu verringern, könnte es eine gute Idee sein, sich auf die nahtlose Abwicklung des ersten Kommentars zu konzentrieren. Wie oben erwähnt, scheinen viele Leute einfach mit ihrer E-Mail-Adresse kommentieren zu wollen. Das Problem sind dann die Validierung und das Login oder die Kontoerstellung (je nachdem, wie DiscourseConnect konfiguriert ist).
Sobald ein Benutzer angemeldet ist, würde ich erwarten, dass er eher das entsprechende Forumsthema besucht, um alle Discourse-basierten Diskussionsfunktionen zu nutzen. Ich hoffe nur, dass all diese schwierigen Teile des Problems die Lösung für das Problem des “ersten Kommentars” nicht behindern. Tausende von Kommentaren zu haben, für die wir dann die Paginierung herausfinden müssen, wäre dann ein “gutes Problem, das man haben kann”. 
4 „Gefällt mir“
Das ist mir genug, denn neue und alte Benutzer werden teilnehmen und sich miteinander beschäftigen. Es ist für mich keine große Sache, ein externer
Ja, das ist eine berechtigte Sorge. Der erste Schritt ist, eine Demo-Website online zu stellen. Eine Live-Website zum Ausprobieren sollte offensichtlich machen, wo die Hürden liegen.
Es wäre technisch möglich, anonymen Benutzern das Kommentieren von Beiträgen zu gestatten. Der einzige nicht-hacky Weg, der mir einfällt, wäre, dass die Kommentare im Namen des anonymen Benutzers von einem echten Benutzer gepostet werden. Das fühlt sich aber etwas seltsam an.
Ich weiß, dass WordPress eine Einstellung hat, die es “Gast”-Benutzern erlaubt, Kommentare zu erstellen. Dies hat die Einschränkung, dass ein “Gast”-Kommentar nicht mit einem echten Benutzer verknüpft wird, wenn sich der Benutzer, der den Gast-Kommentar erstellt hat, nach der Erstellung des Kommentars auf der Website registriert. Das Posten “im Namen von” einem Benutzer müsste auf ähnliche Weise funktionieren – es gäbe keine Möglichkeit zu wissen, dass der Benutzer, der den anonymen Kommentar erstellt hat, der Inhaber der E-Mail-Adresse war, die er mit dem Kommentar angegeben hat.
Idealerweise werden Benutzer entweder auf der externen Website oder in Discourse authentifiziert, bevor sie einen Kommentar erstellen.
Aus Sicht des Benutzers wäre die geringstmögliche Hürde der Fall, dass die externe Website der SSO-Anbieter für Discourse ist. Dies würde es ihnen ermöglichen, Kommentare zu Discourse-Themen zu schreiben, ohne jemals die Discourse-Website besuchen zu müssen.
Aus Sicht des Website-Betreibers wäre der technisch einfachste Weg zur Authentifizierung von Benutzern, Discourse als Authentifizierungsanbieter für die externe Website zu verwenden. Dies ist die Konfiguration, die ich derzeit auf meiner lokalen Testseite verwende. Die externe (Remix)-Website hat nicht einmal eine Benutzertabelle. Sie erstellt lediglich eine Benutzersitzung basierend auf der Antwort der Discourse-Route /session/sso_provider.
Der Nachteil der Verwendung von Discourse als Authentifizierungsanbieter für die externe Website ist, dass Benutzer gezwungen werden, den Discourse-Registrierungs-/Anmeldevorgang zu durchlaufen. An diesem Prozess ist nichts auszusetzen, außer dass Benutzer gezwungen werden, alle Discourse-Assets herunterzuladen, obwohl sie vielleicht nur einen Kommentar auf der externen Website hinterlassen möchten. Es ist also irgendwie langsam. Ich werde das weiter untersuchen…
Das wäre es Vielleicht reduzieren wir das auf Hunderte für ein realistischeres Szenario. Der Punkt, den ich machen möchte, ist, dass das Problem komplex wird, sobald man über eine Seite mit Beiträgen (20 Beiträge) hinausgeht.
Bearbeiten: Es wäre vielleicht möglich, Discourse-Einladungen zu verwenden, um den Prozess zu optimieren – wenn ein anonymer Benutzer einen Kommentar zu einem Beitrag schreiben möchte, würde neben dem Kommentarformular ein E-Mail-Feld angezeigt. Das Absenden des Kommentars würde Discourse auslösen, eine Einladung an die E-Mail-Adresse zu senden. Der Kommentar würde in einer Warteschlange gehalten, bis die Einladung angenommen wurde. Dies würde es Benutzern ermöglichen, den Kommentar zu schreiben, wenn sie die Inspiration dazu haben, und ihnen sofortiges Feedback über den Status ihres Kommentars geben.
4 „Gefällt mir“
Ich bin gespannt, was @simon’s Lösung hier sein wird.
Ich wollte nur anmerken, dass eine Lösung, die sich in dieser Hinsicht auf einer anderen Spur entwickelt, die Verwendung von ActivityPub ist. In seiner neuesten Version hat das offizielle Wordpress ActivityPub-Plugin die Unterstützung für das Discourse ActivityPub-Plugin hinzugefügt.
Das bedeutet, wenn Sie das Wordpress ActivityPub-Plugin installiert haben und das Discourse ActivityPub-Plugin installiert haben, müssen Sie nur eine Kategorie einrichten, um einem Wordpress-Akteur, der einen Beitrag veröffentlicht (oder der gesamten Wordpress-Website), zu “folgen”, und Ihre Wordpress-Beiträge werden als neue Themen in dieser Discourse-Kategorie erscheinen.
(Beachten Sie, dass das Wordpress-Plugin eine Verögerung bei der Veröffentlichung hat, weshalb es im Video eine Minute dauert, bis es in Discourse erscheint; überspringen Sie zu 1:40, um zu sehen, wie es erscheint).
Das Wordpress ActivityPub-Plugin unterstützt auch die Activity-Aufnahme und ist bereits so eingerichtet, dass eingehende Activities als Antwort auf einen Beitrag als “Kommentar” zu diesem Beitrag verarbeitet werden. Dieser spezielle Teil funktioniert jedoch noch nicht mit den vom Discourse-Plugin gesendeten Activities (ich glaube, das Wordpress-Plugin unterstützt noch keine angekündigten Notizen). Aber das sollte bald auch funktionieren.
Siehe weiter
6 „Gefällt mir“
Beachten Sie, dass Matthias, der Betreuer des Wordpress-Plugins, dies zum Laufen gebracht hat, sodass bald die Unterstützung für die Veröffentlichung von Beiträgen und native Zwei-Wege-Kommentare zwischen Discourse und Wordpress (über ActivityPub) verfügbar sein sollte.
https://socialhub.activitypub.rocks/t/this-is-a-test-federation/4164/2
https://pfefferle.org/this-is-a-test-federation/#comment-148
3 „Gefällt mir“
Dieses Thema begann mit der Idee, dass ein Discourse-basiertes Kommentarsystem ähnliche Funktionen wie Coral bieten könnte, mit dem zusätzlichen Vorteil, dass Website-Kommentare in reguläre Discourse-Themen ausgegliedert werden können. Discourse bietet die Möglichkeit, die Kommentare einer Website zu moderieren und Diskussionen im Zusammenhang mit den Kommentaren im Forum zu ermöglichen.
Ich glaube nicht, dass die Notwendigkeit der Moderation diskutiert werden muss.
Die Notwendigkeit, Kommentare in tatsächliche Discourse-Themen auszugliedern, mag weniger offensichtlich sein. Ich gehe davon aus, dass jede Art von Online-Konversation schwierig ist – persönliche Gespräche bieten alle möglichen subtilen Hinweise, die online nicht existieren. Sinnvolle Online-Gespräche mit mehr als einer Handvoll Leuten sind nahezu unmöglich. Hier kommt Discourse ins Spiel. Die Gruppenfunktionalität von Discourse bietet die Möglichkeit, einzuschränken, wer an einem Thema teilnehmen kann. Kommentatorengruppen können an abgeschotteten Discourse-Themen teilnehmen. Dies ist eher das Gegenteil der Funktionsweise des Fediverse.
Davon abgesehen bin ich neugierig, wie die Integration von Discourse/WordPress im Fediverse funktionieren könnte. Wenn Sally beispielsweise einen WordPress-Beitrag von Bob kommentiert, was würde mit Sallys Kommentar passieren, wenn sie ein Discourse-Konto hätte? Was würde mit Sallys Kommentar passieren, wenn sie kein Discourse-Konto hätte? Gibt es eine Möglichkeit, dass Sally sich dagegen entscheiden könnte, dass ihr Kommentar im Fediverse veröffentlicht wird?
Das Thema verfehlt, aber angesichts der verschiedenen Gesetze zu Online-Schäden, die in westlichen Ländern umgesetzt oder vorgeschlagen werden, wer ist verantwortlich, wenn Sallys Kommentar als beleidigend eingestuft wird? Ich gehe davon aus, dass dies zu diesem Zeitpunkt eine unbeantwortbare Frage ist.
3 „Gefällt mir“
Interessant!
Die Art und Weise, wie ich vorschlagen würde, über die Funktionsweise von ActivityPub mit Moderation und Gruppierung (und anderen Rubriken der Online-Kommunikation) nachzudenken, ist, dass es sich in erster Linie um einen Kommunikationsstandard handelt. Er bietet einige Mechanismen, um diese Fragen zu behandeln, überlässt sie aber weitgehend den verschiedenen Clients im System.
E-Mail als Kommunikationsstandard ist eine unvollkommene, aber vielleicht nützliche Analogie. „E-Mail“ ist eine Sammlung von Kommunikationsstandards, die es Ihnen ermöglicht, Nachrichten mit jedem im Internet auszutauschen. Sie hat verschiedene „Qualitätskontroll“-Probleme, z. B. Spam. Es gibt einige Aspekte der Sammlung von Standards, die wir als „E-Mail“ bezeichnen und die helfen, diese Probleme zu bewältigen (z. B. DMARC, DKIM, SPF usw.), aber vielleicht ist der wichtigste Weg, wie Qualitätskontrolle gehandhabt wird, in den E-Mail-Clients selbst. Gmail wurde zu einem beliebten E-Mail-Client, teilweise weil er Spam (und ähnliche Qualitätskontrollprobleme) wohl recht gut bewältigte.
Wenn wir die Analogie fortsetzen, wäre Discourse das „Gmail“ von ActivityPub. Alle Moderationstools, Benutzergruppierungen und andere Funktionen, die Discourse zu einer großartigen Diskussionsplattform machen, sind (so gut wie) immer noch im Kontext von ActivityPub verfügbar. Ich werde dies weiter ausführen, indem ich beginne, Ihre Fragen zu beantworten.
Ich beginne damit, zu beschreiben, was passiert, und können dann vielleicht zu den nuancierteren Fragen übergehen. Ich werde hier vieles überspringen, um die Grundlagen zu beantworten:
-
Sallys Kommentar wird als ActivityPub-Objekt von WordPress veröffentlicht.
-
Das Objekt wird in Discourse aufgenommen und in einen Beitrag umgewandelt.
-
Wenn Sallys „Actor“ mit einem Benutzerkonto in Discourse verknüpft ist, wird der Beitrag mit diesem Benutzerkonto verknüpft. Wenn ihr Actor noch nicht mit einem Benutzerkonto verknüpft ist, wird ein Staging-Benutzer aus Sallys Actor erstellt und dieser wird der Eigentümer des Beitrags.
Sie können das oben Genannte in diesem Thema sehen:
-
Die Discourse-Kategorie WordPress - SocialHub folgt Matthias’ WordPress.
-
Matthias hat einen neuen Artikel auf seinem Blog mit seinem normalen WordPress-Konto veröffentlicht.
-
Dies erschien in Discourse als neues Thema, wobei der Beitrag mit einem Staging-Benutzer verknüpft war, der mit Matthias’ Actor verknüpft war.
-
Die Funktionsweise von Kommentaren ist genau dieselbe.
Nur um vielleicht die offensichtlichste Frage zu beantworten: Kann Matthias den „gestagten“ Benutzer, der aus seinem WordPress-Actor erstellt wurde, und seinen normalen Discourse-Benutzer auf diesem Server zusammenführen?
Die kurzfristige Antwort ist, dass das Discourse-Plugin über eine „Authorization“-Funktion verfügt, die es Ihnen derzeit ermöglicht, die Inhaberschaft von Actors von anderen Discourse-Servern oder Mastodon-Servern zu beanspruchen, wodurch solche gestagten Benutzer in Ihr Konto zusammengeführt werden (was bedeutet, dass Sie nun die Beiträge in Ihrem Haupt-Discourse-Konto besitzen). Diese Funktion könnte auf WordPress erweitert werden. Ich verstehe, dass dies etwas wortreich ist, und es ist vielleicht einfacher zu verstehen, was ich meine, mit dieser Demo:
Die längerfristige Antwort ist, dass Identitätsnachweise möglicherweise irgendwann in ActivityPub-Aktivitäten integriert werden, was möglicherweise die Notwendigkeit einer benutzergesteuerten Autorisierung beseitigt und bedeutet, dass die „Zusammenführung“ (eher) automatisch erfolgen könnte.
Vielleicht ist eine weitere Frage, ob eine „Zusammenführung“ notwendig ist, da Matthias die Identitätsattribute seines gestagten Benutzers immer noch über seinen ActivityPub-Actor kontrolliert (der auf WordPress bearbeitbar ist und dessen Änderungen an den gestagten Benutzer in Discourse weitergegeben werden).
Ich sage das meiste davon als eine Art Vorrede, damit wir zu Ihren nuancierteren und wichtigeren Fragen übergehen können. Ich hoffe, ich mache bisher Sinn.
2 „Gefällt mir“
Es ergibt Sinn.
Was das Moderationsthema betrifft, spreche ich davon, Discourse zur Moderation von WordPress-Kommentaren zu verwenden. Das ist die Funktionalität, die es Discourse ermöglichen würde, auf ähnliche Weise wie Coral verwendet zu werden. Dies ist leicht zu erreichen, wenn WordPress-Kommentare tatsächlich Discourse-Kommentare sind, die über die API von WordPress nach Discourse veröffentlicht werden. Es funktioniert einfach out-of-the-box. Dies ermöglicht Dinge wie die Verwendung von KI-gestützten Moderationstools, die von Discourse bereitgestellt werden. Ich frage mich, ob etwas Ähnliches mit der WordPress/Discourse ActivityPub-Integration erreicht werden könnte.
Was ist der Identitätsnachweis für den gestuften Benutzer? Wird seine E-Mail-Adresse vom Ursprungsserver übermittelt?
Was meine (persönliche) Sorge betrifft, Inhalte nicht im gesamten Fediverse veröffentlichen zu wollen, scheint es technisch möglich zu sein, eine Eins-zu-Eins-ActivityPub-Beziehung zwischen einer Discourse-Site und einer WordPress-Site einzurichten, aber ich frage mich, ob dies den Zweck des ActivityPub-Protokolls untergräbt.
Bearbeitung: Es könnte sich lohnen hinzuzufügen, dass das Ziel darin besteht, eine Win-Win-Beziehung zwischen einer Website und einem zugehörigen Discourse-Forum zu schaffen. Die Moderationstools von Discourse sollen die Gewissheit geben, dass das Kommentarsystem der Website gut moderiert ist. Der Kommentarbereich der Website soll dazu dienen, die Discourse-Site mit Themen und Benutzern zu füttern.
2 „Gefällt mir“
Der Beitrag, der aus dem ActivityPub-Objekt konvertiert wird, durchläuft fast die gleichen Vor- und Nachverarbeitungsfunktionen wie ein Beitrag, der über die API erstellt wird. Der Einstiegspunkt ist anders (d. h. ein ActivityPub-Controller anstelle des Beitragscontrollers), aber die Art und Weise, wie Beiträge erstellt werden, ist weitgehend dieselbe.
*Genauer gesagt, wenn Sie einen Beitrag über die API erstellen, wird die eigentliche Verarbeitung über den NewPostManager durchgeführt, der dann die meiste Arbeit an den PostCreator übergibt. Die Hauptaufgabe des NewPostManager (für unsere Zwecke hier) ist die Überprüfungsschlange. Alles andere wird im PostCreator behandelt.
Derzeit überspringt das ActivityPub-Plugin den NewPostManager und übergibt ihn an den PostCreator in seinem eigenen (d. h. des Plugins) PostHandler. Ich habe dies hauptsächlich getan, um die Komplexität in der anfänglichen Implementierung zu reduzieren. Es gibt keinen inhärenten Grund, warum der PostHandler des Plugins den Beitrag nicht an den NewPostManager übergeben und die Vorteile der Überprüfungsschlangenprüfungen nutzen könnte.
Kurz gesagt, es gibt keinen wesentlichen Unterschied zwischen Beiträgen, die über das ActivityPub-Plugin und über die normale API erstellt werden.
Dafür gibt es mehrere Ebenen.
-
Erstens wird die POST-Anfrage vom Ursprungsserver an Ihren Server mithilfe von HTTP-Signaturen signiert, um sicherzustellen, dass die Anfrage tatsächlich vom Ursprung stammt.
-
Zweitens hat jeder Actor (d. h. Benutzer) auf diesem Ursprungsserver eine UUID, d. h. eine ID, die an seine Domäne gebunden ist und im Fediverse eindeutig ist. Sie sieht ungefähr so aus:
https://angus.ngrok.io/ap/actor/f4b517bf6f81dbddfad3e44a45c9619d
E-Mails werden in ActivityPub nicht verwendet.
-
Jede Aktivität (z. B. ein Create-Objekt eines beitragsähnlichen Objekts), die Sie empfangen, ist mit einer Actor-ID verknüpft. Und jede Actor-ID kann auf Actor-Attribute aufgelöst werden.
-
Wenn Sie also eine “Aktivität” empfangen, z. B. die Erstellung eines neuen beitragsähnlichen Objekts, auf Ihrem Server, kennen Sie gemäß der Domäne, von der Sie die Aktivität erhalten haben, die Attribute des Actors, der die Aktivität ausführt. Sie vertrauen hier der sendenden Domäne, aber das ist immer der Fall, in dem z. B. Discourse den WordPress-Instanzen mit dem WP Discourse-Plugin vertraut, um die richtigen Benutzerattribute zu senden.
Der gestufte Benutzer selbst benötigt also keinen Identitätsnachweis an sich, genauso wenig wie ein gestufter Benutzer per E-Mail einen Identitätsnachweis benötigt.
Die Notwendigkeit eines Identitätsnachweises entsteht, wenn die reale Person, die mit dem ActivityPub-Actor verbunden ist, und ein weiterer Discourse-Account, wie im Beispiel mit Matthias oben, ihre Identität konsolidieren (oder “abgleichen”) möchten. Möglicherweise gefällt ihnen nicht, dass sie effektiv zwei “Benutzer” in einem einzigen Discourse haben. Ich möchte darauf hinweisen, dass sie ohne eine solche Konsolidierung Folgendes kontrollieren können:
-
Die Identitätsattribute des ActivityPub-Actors / gestuften Benutzers über die Quell-Domäne, z. B. durch Aktualisierung ihres WordPress-Profils, wobei diese Aktualisierungen föderiert werden und Discourse dieselben anwendet); und
-
Den Inhalt, der dem ActivityPub-Actor / gestuften Benutzer über die Quell-Domäne zugeordnet ist, z. B. durch Bearbeitung ihres WordPress-Kommentars, wobei eine Update-Aktivität gesendet und dann von Discourse verarbeitet wird.
Dennoch kann es ihnen “unordentlich” erscheinen, effektiv zwei Benutzer in Discourse zu haben. Deshalb verfügt das Plugin über die Funktion “Autorisierung”, mit der Sie zeigen können, dass Ihr normaler Discourse-Benutzer mit dem ActivityPub-Actor mit seinem gestuften Benutzer verbunden ist. Dies geschieht derzeit über plattformspezifische Autorisierungsmechanismen:
-
Für Mastodon geschieht dies über die OAuth-API von Mastodon. Sie müssen Ihr Konto auf Mastodon authentifizieren, um nachzuweisen, dass Sie den entsprechenden Actor kontrollieren.
-
Für Discourse geschieht dies über die Benutzer-API. Dies wird im Video in meinem vorherigen Beitrag gezeigt.
-
Es gibt einige Möglichkeiten, wie dasselbe für WordPress geschehen könnte, z. B. DiscourseConnect über das WP Discourse-Plugin. Dies ist noch nicht implementiert.
Sobald Sie nachweisen, dass Sie den Actor besitzen, der mit dem gestuften Benutzer verbunden ist, wird der gestufte Benutzer mit Ihrem normalen Benutzer zusammengeführt, seine Beiträge werden Ihre, und alle neuen Aktivitäten, die diesem Actor zugeordnet sind, werden automatisch Ihre. Aber diese Funktion ist eigentlich eher zur Verbesserung der Benutzererfahrung gedacht und streng genommen nicht notwendig. Die reale Person hinter diesen verschiedenen Benutzern kontrolliert von Anfang an sowohl die Benutzerattribute als auch deren Inhalte.
Ja, es ist möglich, das Ziel ausgehender Veröffentlichungen zu steuern und die Quelle eingehender Veröffentlichungen einzuschränken. Ob dies den Zweck von ActivityPub verfehlt, ist umstritten. Streng genommen ist ActivityPub nur ein Standard. Ich würde argumentieren, dass es keinen Grund gibt, warum Sie den Standard nicht auf diese Weise verwenden können. Historisch gesehen wurde ActivityPub mit dezentralen sozialen Netzwerken, insbesondere Mastodon, in Verbindung gebracht, weshalb Sie vielleicht das Gefühl haben, dass dieser Ansatz den Zweck von ActivityPub verfehlt. Aber ich würde zwischen dem ActivityPub-Standard selbst und seinen bestehenden Implementierungen hier unterscheiden.
Darüber hinaus möchte ich in diesem Zusammenhang darauf hinweisen, dass, ähnlich wie bei E-Mails, das, was wir “ActivityPub” nennen, eigentlich eine Sammlung von Standards ist. Das Standards-Dokument mit dem Titel “ActivityPub” muss zusammen mit einem anderen Standards-Dokument namens “ActivityStreams” gelesen werden, das die wichtigsten Objekte beschreibt. Der ActivityStreams-Standard ist “dienstneutraler” als ActivityPub selbst (d. h. weniger an dezentrale soziale Netzwerke gebunden).
Um (eine weitere) Analogie zu verwenden: Blockchain als Technologie ist einfach ein dezentrales Register. Als es mir zum ersten Mal erklärt wurde, dachte ich an das Torrens-System der Landregistrierung, das im 19. Jahrhundert (in Australien) aus denselben Gründen erfunden wurde, aus denen die Blockchain erfunden wurde (d. h. zur Verhinderung von Betrug bei Immobilientransaktionen). Aber die beliebteste Implementierung der Blockchain ist Bitcoin, die einen (anderen) spezifischen Zweck und bestimmte kulturelle Werte hat. Die Analogie ist nicht die beste, aber man kann sich vorstellen, dass Mastodon und dezentrale soziale Netzwerke für ActivityPub das sind, was Bitcoin für Blockchain ist.
Tatsächlich ist einer der Gründe, warum ich geholfen habe, eine neue W3C ActivityPub for Forums Arbeitsgruppe mit NodeBB, Flarum und anderen einzurichten, den Fokus der ActivityPub-Integration von den bestehenden Implementierungen (z. B. Mastodon) auf die Anliegen von Foren, wie die von Ihnen angesprochenen Moderationsfragen, zu verlagern. Wir haben tatsächlich heute unser nächstes Treffen. Wenn Sie Zeit haben, würde ich mich freuen, einen Mit-“Discourser” (ist das ein Begriff?) dort zu haben
4 „Gefällt mir“
Ich spreche davon, die Moderationstools von Discourse zu verwenden, um Kommentare zu moderieren, die auf WordPress erscheinen. Technisch gesehen könnte dies mit einer Discourse-API-Anfrage oder einem Webhook erfolgen – nachdem eine Moderationsaktion in Discourse stattgefunden hat, könnte eine Anfrage gestellt werden, um den Status des Kommentars in WordPress zu ändern.
Unter der Annahme, dass Änderungen vorgenommen werden, damit ActivityPub-Beiträge von der Überprüfungswarteschlange bearbeitet werden, gäbe es immer noch ein Problem mit der Zeitverzögerung zwischen dem Zeitpunkt, an dem der Kommentar ursprünglich in WordPress veröffentlicht wird, und dem Zeitpunkt, an dem er in Discourse erscheint. Ich glaube, das sind ein paar Minuten?
Für diesen speziellen Fall ist eines der Hauptverkaufsargumente „Verwenden Sie Discourse, um die Kommentare Ihrer Website zu moderieren“. Darauf folgen die Moderationsfunktionen von Discourse, das Vertrauensstufensystem, die Überprüfungswarteschlange, KI-gestützte Moderationstools usw. Dies sind Tools, die für kleinere Blogs wünschenswert wären, aber für Mainstream-Nachrichtenseiten eine Anforderung darstellen. Ich denke, der beste Weg, dies zu erreichen, ist, Discourse als einzige Quelle der Wahrheit für Kommentare zu verwenden, anstatt Kommentare in zwei (oder mehr) Datenbanken zu haben.
Das ist großartig! Ohne Zeit zu haben, weiter darüber nachzudenken, glaube ich nicht, dass ich ein guter Vertreter für Discourse wäre.
Ich habe einige allgemeine Bedenken hinsichtlich der Idee, Themen, Beiträge und Benutzer nur als Datenbits zu behandeln. Es muss einen Weg geben, sicherzustellen, dass der Kontext, in dem eine Diskussion stattfindet, nicht verloren geht.
Auf einer praktischeren Ebene hat sich das ActivityPub-Protokoll vor der Einführung der Gesetze gegen Online-Schäden, die in verschiedenen Ländern eingeführt werden, durchgesetzt. Es muss eine gewisse Zusicherung geben, dass Server, die Daten von einem Ursprungsserver konsumieren, Löschanfragen respektieren. Andernfalls riskieren Benutzer, die Inhalte auf einem Ursprungsserver generieren, rechtliche Konsequenzen, wenn ihre Inhalte in ihrem Land später als schädlich eingestuft werden.
3 „Gefällt mir“