Ein Thema wird mit einem Link im ersten Beitrag erstellt – zunächst wird entweder ein einzelner Link im ersten Beitrag oder eine URL im Titel erkannt.
Optional: Um trivialen Spam zu vermeiden, warten Sie entweder auf die erste Antwort oder aktivieren Sie eine Website-Einstellung.
Die Seite wird untersucht, um festzustellen, ob WebMention unterstützt wird.
Ein WebMention-Kommentar wird mit dem Text „Diese Seite wird auf =SITE\_DOMAIN=: „=TITLE=“ =TOPIC\_LINK= =CATEGORY_AND_TAGS=“ (unter Verwendung der Standard-Locale der Website) besprochen.
Die Website empfängt die WebMention (delegiert möglicherweise an fed.brid.gy, wendet Anti-Spam-Maßnahmen usw. an) und zeigt diese schließlich als Kommentar an.
Der Akteur (Kommentar „Autor“) würde entweder das hochwertige Website-Logo oder den @system-Avatar und den Kurznamen des Forums verwenden.
Nur am Rande: Ich habe es im Beitrag nicht erwähnt, aber das Protokoll unterstützt das Senden von Likes und Reposts als Bürger erster Klasse wie Antworten, es wäre schön, wenn Discourse das auch implementieren würde
Pavilion hat sich bei NLnet um 40.000 Euro beworben, um die Föderationsunterstützung für Discourse hinzuzufügen (siehe unten). Es wurde abgelehnt und wir haben uns stattdessen für DAPSI beworben (und wurden angenommen).
Eine Aktualisierung hier. Pavilion und CDCK (Discourse.org) diskutieren den Aufbau eines ActivityPub-Plugins für Discourse. Nach einiger Diskussion haben wir uns auf die unten stehende Spezifikation geeinigt. Kommentare oder Vorschläge sind willkommen, bevor wir sie finalisieren. Beachten Sie, dass
Die Unterstützung für eingehende Inhalte (z. B. Beiträge auf Mastodon usw., die in Discourse importiert werden) ist absichtlich ausgeschlossen. Es wird möglich sein, dies in einer späteren Version hinzuzufügen.
Die Unterstützung für das Folgen von Benutzern (im Gegensatz zu Kategorien) ist ebenfalls absichtlich ausgeschlossen. Es wäre auch möglich, dies in einer späteren Version hinzuzufügen.
Wesentliche Teile der Spezifikation folgen dem Ansatz von Lemmy.
Pavilion wird das MVP-Plugin bauen (ich werde daran arbeiten), und CDCK wird es besitzen und hosten (d. h. es wird ein CDCK-Plugin und kein Pavilion-Plugin sein).
Übersicht
Ein ActivityPub (AP) Plugin für Discourse.
Das Ziel des Plugins ist eine MVP-Implementierung der Spezifikationen ActivityPub, ActivityVocab und ActivityStreams in Discourse mit einer demonstrierten Integration der MVP-Funktionalität für eine AP-konforme Plattform, nämlich Mastodon. Soweit wie möglich wird die Implementierung so aufgebaut sein, dass sie die weitere Unterstützung der Protokolle und etwaige Erweiterungen ermöglicht.
Diese Spezifikation betrifft die Aktivierung der AP-Unterstützung auf Kategoriebasis, wobei nur der erste Beitrag jedes Themas in einer AP-aktivierten Kategorie föderiert wird („nur erster Beitrag“).
Benutzer
Die Plugin-Nutzung wird auf meta in einem Plugin-Thema umfassend dokumentiert.
Normaler Benutzer
Abonniert (auch „folgt“) eine Föderations-fähige Discourse-Kategorie (FDC) auf Mastodon (oder einem anderen Fediverse-Dienst) über den Handle der Kategorie, z. B. @announcements@meta.discourse.org.
Sieht einen Auszug des ersten Beitrags aller FDC-Themen (die nach dem Abonnement gepostet wurden) in seinem Mastodon-Feed, jeweils mit einem Link zurück zum zugehörigen Thema, z. B. „Diskutieren Sie in unserem Forum“.
Jede Aktion im Zusammenhang mit dem Beitrag in Mastodon erscheint nicht in Discourse.
Jede Aktion im Zusammenhang mit dem Beitrag in Discourse erscheint nicht in Mastodon.
Auszüge von föderierten Beiträgen können vom Autor des Beitrags mit Markup gesteuert werden, ähnlich dem, das zur Steuerung von Themenauszügen verwendet wird, z. B. <div>{text}</div>
Administrator
Aktiviert die Föderation auf Kategoriebasis über eine Kategorieeinstellung. Die Föderation kann nur in Kategorien aktiviert werden, die für „jeden“ auf öffentlichen Instanzen sichtbar sind.
Legt den föderierten Benutzernamen der Kategorie über die Benutzeroberfläche der Kategorieeinstellungen fest (kann nicht geändert werden).
Legt Listen von Domains fest, von denen Aktivitäten automatisch akzeptiert oder abgelehnt werden (Allow- und Deny-Listen über Site-Einstellungen).
Legt eine „Blockliste“ von föderierten Benutzernamen fest, die Teil eines Block-Objekts im Server-Postausgang sind.
Legt die maximale Zeichenlänge einer föderierten Notiz über eine Site-Einstellung fest, z. B. activitypub_note_excerpt_maxlength.
Legt den Text fest, der mit dem Link verbunden ist, der im ersten Beitrag eines föderierten Discourse-Themas unter „Anpassen > Text“ enthalten ist.
Legt fest, ob der Link zurück (und der Text) zum Forum in föderierten Beiträgen auf Kategoriebasis enthalten ist.
Fügt über Site-Einstellungen ein Schlüsselpaar hinzu, um föderierte Inhalte zu signieren.
Technik
Das Plugin wird umfassende Tests enthalten (Unit-/Integrationstests und JavaScript-Tests).
Die Kategorie ist ein automatisierter ActivityPub Actor innerhalb von Discourse (als Group ActorType). Der föderierte preferredUsername wird vom Administrator beim Aktivieren der Föderation festgelegt und in einem benutzerdefinierten Feld der Kategorie gespeichert. Der föderierte Name (auch Anzeigename) ist der full_name der Kategorie.
Benutzer sind Akteure in den Inhalten, die vom Kategorie-Akteur föderiert werden. Der föderierte preferredUsername ist der Discourse-Benutzername des Benutzers zum Zeitpunkt der Föderation. Der preferredUsername eines Benutzers wird in einem benutzerdefinierten Feld gespeichert, falls der Benutzer seinen Discourse-Benutzernamen ändert. Der föderierte Name (auch Anzeigename) ist der Discourse-Name des Benutzers.
Im Allgemeinen werden ActivityPub-Objekte mit ihren entsprechenden Discourse-Objekten über benutzerdefinierte Felder (z. B. Objekt- oder Akteur-IDs) und neue Tabellen (z. B. Posteingang und Postausgang), wo dies angebracht ist, verknüpft.
Die primäre ActivityPub-Aktivität, die implementiert werden soll, ist Follow und die zugehörigen Aktivitäten und Modelle, die zu ihrer Implementierung erforderlich sind, d. h. Posteingang, Postausgang und erforderliche zugehörige Aktionen und Sammlungen.
Discourse-Beiträge werden als ActivityStream Notes mit dem Inhalt als HTML föderiert.
Die Authentifizierung wird über HTTP-Signaturen gehandhabt, siehe hier und hier. Alle anderen Sicherheitsüberlegungen in der ActivityPub-Spezifikation werden entsprechend berücksichtigt.
Föderationsendpunkte werden entsprechend der Spezifikation geschützt, d. h. stellen Sie sicher, dass redirect_to_login_if_required in Controllern verwendet wird, fügen Sie Guardian für die Berechtigung „Jeder kann sehen“ für Kategorien hinzu.
Ich freue mich sehr, diese Nachricht zu sehen! Danke! Außerdem bin ich froh, dass Sie mit einer einfachen anfänglichen Implementierung beginnen, anstatt zu versuchen, den sprichwörtlichen Elefanten zu fressen (kein obliquer Bezug auf Mastodon). Ich zögere, etwas hinzuzufügen, aber da Sie um Vorschläge bitten, hier einer, der hoffentlich nur geringfügig mehr Arbeit bedeutet:
Was würden Sie davon halten, optional auch Auszüge von Antworten zu posten, wobei inReplyTo verwendet wird, um sie zu verknüpfen? Ich denke, das würde den Dialog auf Discourse hervorheben und einladender sein; zusammen mit dem “Diskutieren Sie in unserem Forum” würde ich erwarten, dass das Sehen der Konversation eher mehr Leute anzieht.
Vielen Dank für das Feedback und die Unterstützung!
Das Problem bei der Föderation von Antworten in diesem Stadium ist, dass Sie Erwartungen an Interaktion wecken könnten, die nicht erfüllt werden, bis Sie eine ordnungsgemäße Unterstützung dafür haben. Es ist wichtig, die Erwartungen der Benutzer hier klar zu halten. Während einige Benutzer die Einschränkungen bei diesen föderierten Antworten verstehen mögen, werden andere dies möglicherweise nicht. Das andere Problem ist der Versuch, die Anzahl der gleichzeitig zu bewältigenden technischen Herausforderungen zu reduzieren.
Dennoch haben wir bereits eine “Ganzes Thema”-Erweiterung der oben genannten Spezifikation “nur erster Beitrag” in Betracht gezogen. Ich habe einige der technischen Notizen dazu unten geteilt, um Ihnen eine Vorstellung davon zu geben, wohin dies führen könnte. Ich möchte betonen, dass die “Ganzes Thema”-Erweiterung nicht Teil der ursprünglichen Spezifikation ist und zu diesem Zeitpunkt nur eine Möglichkeit darstellt.
Ganzes Thema
Eingehende Notizen würden als neue Themen oder Antworten veröffentlicht (unter Verwendung von inReplyTo oder Replies).
Discourse-Sicherheits- und Spamfilter werden so gut wie möglich auf eingehende Objekte angewendet, indem Accept / Reject objects verwendet werden.
Notizbeiträge werden einem gestuften Benutzer zugeordnet, der über ein benutzerdefiniertes Feld mit der Actor-ID verknüpft ist. Dies erfordert eine nicht-e-Mail-basierte Variante des Konzepts des gestuften Benutzers, da der Benutzer keine echte E-Mail haben wird (ein Platzhalter kann mit der ID des föderierten Akteurs und preferredUsername generiert werden).
Die Zuordnung von gestuften ActivityPub-Benutzern zu Standard-Discourse-Benutzern wäre möglich, ist aber derzeit nicht Teil dieser Spezifikation. Dies ist ein Problem der “föderierten Identität” und seiner zugehörigen Lösungen.
Föderierte Beiträge würden keine föderierten @mentions oder ähnliches außerhalb der Kern-ActivityPub/Stream-Spezifikationen unterstützen. Die Unterstützung für solche Funktionen könnte in späteren Versionen hinzugefügt werden, z. B. unter Verwendung von Webfinger oder durch Folgen von Mastodon.
Der Schlüssel in dieser ersten Version ist die Konzentration auf die minimal lebensfähige Implementierung. Sobald diese Grundlage gelegt ist, wird eine vollständige (oder vollständigere) Föderationsunterstützung, möglicherweise in Anlehnung an diese “Ganzes Thema”-Notizen, machbarer sein. Ich möchte jedoch betonen, dass die Richtung des Plugins von CDCK bestimmt wird. Alles, was ich hier erwähne, sind nur mögliche Wege, auf denen die grundlegende Spezifikation aufgebaut werden könnte.
Einige der Beiträge und laufenden Diskussionen aus dem Fediverse:
PS. Ich möchte auch erwähnen, dass ich im November letzten Jahres von Daniël Klabbers, einem Kernentwickler von Flarum, angesprochen wurde, der mir sagte, dass sie an einer ActivityPub-Erweiterung arbeiten. Ich weiß nicht, wie der Stand der Dinge ist, aber es wäre gut, wenn alle Projekte im Bereich Foren zusammenarbeiten würden, um so viel Interoperabilität wie möglich in diesem Bereich zu erreichen.
In Bezug auf diese Interoperabilität möchte ich auch auf den Fediverse Enhancement Proposal-Prozess, das FEP auf Codeberg, hinweisen:
Hier hat z.B. Lemmy kürzlich ein FEP für ActivityPub-Gruppen finalisiert. Diskussionen finden auf dem SocialHub statt unter:
(Der FEP-Prozess gewinnt mit dem Wachstum des Fediverse an Fahrt und ist derzeit der beste Ort, um Protokollmechanismen zu standardisieren)
Danke @aschrijver, sehr nützlich! Ich werde mich persönlich ganz auf die oben spezifizierte MVP-Implementierung konzentrieren und eng mit CDCK zusammenarbeiten. Um es mit den prägnanten Worten von @mcdanlj zu sagen: Es ist entscheidend, dass diese Bemühungen nicht versuchen, „den Elefanten zu verschlucken“. Wir sind gespannt auf konstruktives Feedback zur Spezifikation, insbesondere zur technischen Seite.
Ich möchte jedoch hinzufügen, dass zwei weitere Mitglieder von Pavilion@nmeyne (ein Veteran der SSI-Community; insbesondere verifizierbare Anmeldeinformationen) und @merefield ebenfalls in diesem Bereich tätig sind und an einigen der von Ihnen aufgeworfenen breiteren Fragen interessiert sind.
Zur Veranschaulichung von echten Missverständnissen aufgrund einer Illusion von Treue: Eines der Probleme, auf die wir auf den Maker Forums gestoßen sind, wo wir viele Google±Communities importiert haben, als Google+ verschwand, ist, dass der Import ausreichend originalgetreu war, dass Neulinge auf der Website nicht erkennen, dass sie versuchen, mit anderen Benutzern zu interagieren, die noch nicht von Google+ auf der Website angekommen sind. Daher haben wir eine Standardantwort, um sie darüber zu informieren, dass die Person, mit der sie zu sprechen versuchen, nicht da ist, um ihnen zu antworten.
Vielen Dank für die Details zu der Idee der „ganzen Themenverlängerung“.
Falls dies später hinzugefügt wird… fwiw, gefällt mir der Ansatz von Pterotype für WordPress sehr gut, bei dem alle föderierten Kommentare direkt zur Moderation / Gruppenfreigabe weitergeleitet werden, bevor sie als Antwort auf das ursprüngliche Forenthema zurückgepostet werden.
Im Fall eines Forums könnte dies eine Aufgabe sein, die besser für TL4 / TL3-Typen als für Mitarbeiter geeignet ist.
Persönlich fand ich, dass dies besonders hilfreich ist, um zu verhindern, dass themenfremde / Social-Media-ähnliche Antworten das ursprüngliche Diskussionsthema überlagern.
Ja, die Nutzung der Überprüfungswarteschlange ist etwas, das wir für eingehende Inhalte besprochen haben. Wie Sie bemerken, ist dies etwas, das berücksichtigt werden muss, wenn und wann wir dort ankommen (nicht in der ersten Version).
Nur eine Anmerkung: Die administrativen Angelegenheiten bezüglich dieser Arbeit sind geklärt, sodass ich nächste Woche mit der Arbeit an der Spezifikation beginne. Weiteres technisches Feedback oder Anmerkungen zur Spezifikation sind willkommen.
Es wird einige Monate dauern, bis dies Früchte trägt, also haben Sie Geduld.
Wenn ein Beitrag in Discourse gelöscht wird, kann dann eine Delete-Aktion an Follower gesendet werden?
Auf Maker Forums haben wir genügend „Google-Punkte“, um viele SEO-Spammer zu bekommen. Wir haben relativ lockere Berechtigungen für neue Benutzer, da eine häufige Form der neuen Nutzung darin besteht, dass eine frustrierte Person Hilfe sucht, die für die Website relevant ist, und dies hilft uns, ihnen schneller zu helfen. Dies bedeutet jedoch, dass Spammer dazu neigen, einen Spam-Beitrag zu veröffentlichen, der dann relativ schnell als Spam markiert, aus der Liste entfernt und dann gelöscht wird.
Ich würde es begrüßen, wenn diese föderierten Beiträge gelöscht und die Löschung über Delete veröffentlicht würde, damit wir den Spam aus den föderierten Caches bereinigen. Ist das möglicherweise im Geltungsbereich?
Es könnte in diesem Fall hilfreich sein, wenn es eine Verzögerung bei der Föderation gäbe, von einigen Stunden, um Spam zu bekämpfen, bevor die Föderation stattfindet. (Vielleicht die Verzögerung nur auf die ersten Beiträge von relativ neuen Benutzern anwenden?)
Ich gehe davon aus, dass wir dies für die von Ihnen genannten Gründe im MVP tun werden. Ich werde dies zu gegebener Zeit weiter mit den Discourse-Leuten besprechen.
Nützlicher Vorschlag. Die Föderation wird definitiv asynchron erfolgen. Wie die Verzögerung festgelegt und gehandhabt wird, müssen wir im MVP in irgendeiner Form angehen.
Spezifische Vorschläge wie dieser für das MVP, insbesondere basierend auf früheren Anwendungsfällen oder technischem Fachwissen, sind sehr willkommen.
Wenn es nicht wesentlich mehr Arbeit im Voraus bedeutet, wäre es auch wertvoll, Post-Bearbeitungen als Update-Aktivitäten zu föderieren. Wenn es sich um eine der Dinge handelt, die nach dem MVP beigetragen werden können, dann wäre ein Design, das dies später vernünftigerweise ermöglicht, großartig.
Wenn es Ihnen hilft, würde ich die Verzögerung auf meiner/meinen Instanz(en) niedrig einstellen. Ich würde nicht vorhaben, sie zu verwenden, um Spam-Posts zu vermeiden, da dies vernünftigerweise ein Signal wäre, das einen Moderator von seinem Fediverse-Feed in unser Discourse holt, um Maßnahmen zu ergreifen. Ich habe chat_integration_delay_seconds auf 20 für schnelle Tippfehler-Bearbeitungen eingestellt und würde erwarten, hier etwas Ähnliches zu tun. Zumindest legt diese Einstellung einen Präzedenzfall für eine solche Verzögerung fest.
Ein kurzes Update! Wir sind einen Monat in der Entwicklung und grob gesagt, haben wir jetzt Folgendes funktionsfähig:
Personen können Kategorien mit aktiviertem ActivityPub folgen
Der erste Beitrag von Themen in ActivityPub-fähigen Kategorien wird an Follower föderiert
Es gibt auch eine Reihe kleinerer Teile, aber es lohnt sich nicht, sie in diesem Stadium zu erwähnen. Es wird noch mindestens einen weiteren Monat Entwicklung geben, bevor wir mit internen Tests beginnen.
Wir brauchen Freiheit in jedem einzelnen Aspekt, den wir mit oder ohne Genehmigung zentralisierter Dienste aufbauen können.
Das ist unaufhaltsam und frei verkäuflich für jeden einzelnen CEO, CTO oder wie auch immer diese gruseligen Namen lauten mögen : )
Und ein großes Dankeschön an jeden beteiligten Entwickler und die Fortschritte, die sie gemacht haben. Ich werde es testen, wenn es öffentlich ist, und meine Gedanken teilen.
