Nur eine kurze Notiz, dass wir uns gerade in diesem Schritt befinden
Das sieht großartig aus!
Ich habe kürzlich einen Discourse-Server für unsere CoSocial Co-op eingerichtet, der einen Mastodon-Server betreibt. Ich habe schließlich das OAuth2-Plugin eingerichtet, sodass wir nur Logins von unserem Mastodon-Server akzeptieren → https://members.cosocial.ca (ziemlich neue, einfache Installation, nur „Nachweis von OAuth“).
Meine Frage / Funktionsanfrage ist, dass es möglich sein sollte, Mastodon-Akteure in Discourse-Konten zu stufen/zusammenzuführen, sodass, wenn Konten auf Mastodon antworten, sie mit dem zugehörigen Discourse-Konto verknüpft / besessen werden können.
Wie Lemmy das nicht macht
Ich habe dokumentiert, wie Lemmy das nicht macht – man kann über Mastodon interagieren, und es wird ein Konto in Lemmy für dieses Mastodon-Konto erstellt, aber man kann sich nicht tatsächlich anmelden und Lemmy-Funktionen als Erstnutzer mit seinem Mastodon-Konto nutzen.
Das steht auf der Agenda…
Und bereits in der Warteschlange zur Überprüfung
Großartig. Es klingt so, als ob meine Discourse OAuth-Plugin-Benutzer sich erneut „bestätigen“ müssten, um mit diesem AP-Plugin zu interagieren.
Ich denke, das ist in diesem Stadium vollkommen in Ordnung, ich möchte nur den OAuth-Server als weiteren Blickwinkel hervorheben, solange er nicht kollidiert. Das „nice to have“ wäre: „Wenn OAuth mit Mastodon-Server, dann AP-Akteur-Identität automatisch verknüpfen“. Völlig zukunftsorientiert und auch einzigartig für diese Art von Einrichtung!
(Und Entschuldigung, dass ich die Seite nicht aufgerufen habe, um mir diesen Teil anzusehen! Großartig!)
Der PR, der diese Funktionen hinzufügt, wurde nun zusammengeführt.
Wie Angus oben bemerkt hat, ist als Nächstes die Benutzerverifizierung über OAuth-Token an der Reihe.
Die Probleme, die ich zuvor mit reinem Markdown gesehen habe, scheinen auch Meta zu betreffen. Ich folge @feature@meta.discourse.org und vor einigen Stunden wurde dieser Beitrag erstellt, der von diesem Akteur föderiert wurde:
Dies erschien mir in Mastodon fehlerhaft so:
In Elk sieht es so aus; ein wenig besser:
Ich habe gerade @feature@meta.discourse.org in meinem reinen Mastodon-Konto zu folgen begonnen, um dies zu testen, aber das ist natürlich zu spät, um diesen speziellen Beitrag dort zu sehen. ![]()
Daher war das eingebettete Markdown, das ich zuvor von meiner eigenen Installation gesehen habe, keine fehlerhafte Datenbank, oder wenn doch, dann war es ein Datenbankproblem, das mit Meta geteilt wurde und daher wahrscheinlich nicht mit meinen Tests zusammenhängt.
Ja, ich kann das reproduzieren, ich sehe ähnliche Ausgaben in einer Mastodon-Instanz und in Ivory (iOS-App).
Ich bin mir nicht sicher, ob das richtig funktioniert. Das Plugin ist aktiviert und ich habe ein Thema in einer Kategorie mit aktiviertem ActivityPub erstellt, aber ich sehe das Abzeichen nicht neben den Beiträgen (und mein Versuch, dem ActivityPub-Actor der Kategorie zu folgen, schien fehlzuschlagen, da es sich so verhält, als ob ein Server manuell genehmigte Follower von einem Benutzer benötigen würde).
Ich habe gerade bemerkt, dass das gleiche Problem auch bei Feature auf Meta aufgetreten zu sein scheint.
Es wäre großartig, das Endziel für Einschränkungen zu verstehen, ohne sich um den Zwischenzustand sorgen zu müssen.
Ich glaube zum Beispiel, ich habe in einem PR einen Hinweis gesehen, dass das Ändern von Besitzern von Beiträgen blockiert wird, wenn das Plugin aktiviert ist. Als Administrator muss ich diese Funktion gelegentlich nutzen (zum Beispiel, wenn ich den Moderator einer Kategorie ändere, mache ich den neuen primären Kategorie-Moderator zum Eigentümer der Kategorie für Sticky-Posts). Ich hoffe, dass dies am Ende als Löschung und erneutes Posten angezeigt wird, oder sogar einfach ignoriert wird, anstatt die Änderung des Eigentums zu blockieren.
Ich frage mich auch, wie Beiträge zwischen Kategorien verschoben werden. Das muss ich ziemlich häufig tun, besonders wenn neue Benutzer in der falschen Kategorie posten. Ich würde naiv erwarten, dass dies dazu führt, dass ein Kategorie-Akteur seinen Boost entfernt und der neue Kategorie-Akteur einen Boost hinzufügt, aber den zugrunde liegenden Beitrag nicht löscht, so dass, wenn jemand einen Beitrag gesehen und geboostet hätte, sein Boost nicht verschwinden würde, nur weil der Kategorie-Akteur-Boost verschwunden ist.
Generell wäre es sehr hilfreich zu wissen, was Ihrer Meinung nach nicht erlaubt sein wird, wenn dieses Plugin nach Abschluss der aktuell spezifizierten Feature-Entwicklung hinzugefügt wird, unabhängig davon, welche Einschränkungen derzeit gelten.
@hello-smile6 Ich sehe dasselbe mit dem heute aktualisierten Plugin:

Ich sehe keine Konfiguration dafür, daher gehe ich von einem Fehler aus.
Danke für den weiteren Bericht. Ich untersuche das.
Danke für den Bericht, wir untersuchen das.
Ich verstehe, woher Sie kommen, aber
-
Während das Plugin aktiv entwickelt wird, wäre es unproduktiv, Dinge auf diese Weise zu erklären, da sich die Erklärung ändern kann.
-
Es gibt eine ganze Reihe verschiedener Szenarien und Randfälle, mit denen das Plugin bereits umgeht. Wenn ich jeden einzelnen erzählerisch in diesem Stadium erklären würde, würde das zu lange dauern (d. h. effektiv diesen langen Beitrag mehrmals machen). Es gibt bereits über 400 verschiedene Spezifikationen für das Plugin.
-
Dennoch werden Einschränkungen oft erzählerisch in den Kommentaren zu den PRs und Commits erklärt, die Sie meiner Meinung nach bereits lesen.
Dies wurde im PR ausführlich diskutiert
Ich habe das Ändern von Beitragseigentümern und das Erstellen von Beitrags-Wikis, auch für Administratoren, in AP-Themen eingeschränkt. Dies liegt daran, dass entfernte AP-Beiträge die Treue zum Original beibehalten müssen und beide Aktionen diese Treue potenziell brechen können.
Es mag eine Möglichkeit geben, die Föderation sowohl mit Wikis als auch mit dem Ändern von Beitragseigentümern zu ermöglichen. Ich schlage jedoch vor, dies als “Funktion” in einem zukünftigen PR hinzuzufügen, da dies die Multiplikation oder Änderung des Akteurs, der einem Objekt zugeordnet ist, das über mehrere Plattformen hinweg föderiert wird, beinhalten muss. Ich denke, wir werden das Ändern von Beitragseigentümern von importierten AP-Beiträgen (Notizen) niemals zulassen können, da die Akteur/Objekt-Zuordnung nicht Discourse gehört, sondern dem Ort, an dem der Inhalt verfasst wurde. Um eine illustrative Analogie zu geben: In diesem Kontext ist die Löschung eines Beitrags, der mit einer importierten Notiz verbunden ist, weniger eine “Löschung” an sich als vielmehr die Entscheidung, eine Notiz nicht anzuzeigen.
Es gibt eine ganze Reihe verschiedener Szenarien, die das Verschieben von Beiträgen betreffen. Ich werde mich vorerst um das von Ihnen erwähnte spezifische Szenario kümmern, nämlich das Verschieben eines Beitrags zwischen zwei verschiedenen ActivityPub-fähigen Kategorien.
Sie gehen davon aus, dass ein Beitrag nur dann zwischen Kategorien verschoben wird, wenn der Beitrag ursprünglich in der falschen Kategorie gepostet wurde und die Verschiebung kurz nach der Erstellung des Beitrags erfolgt. Was ist, wenn Sie 4 Monate nach der Erstellung eines Beitrags diesen in eine andere Kategorie verschieben, weil Sie eine bestimmte Sammlung von Beiträgen in einem neuen Thema in einer anderen Kategorie konsolidieren möchten? Wäre es in diesem Szenario sinnvoll, ein “Rückgängig” für den ursprünglichen Boost zu senden?
Dies hängt davon ab, ob wir über die Konfiguration des ersten Beitrags oder die Konfiguration des vollständigen Themas sprechen. Für ersteres werden wir eine Schaltfläche für den ersten Beitrag hinzufügen, die manuell veröffentlicht wird, um speziell das Szenario der Kategorieverschiebung zu behandeln. Für letzteres kann das automatische Hinzufügen eines Boosts sinnvoll sein, darüber werde ich noch nachdenken.
Ich verstehe, woher Sie kommen, aber ich habe bereits eine ganze Menge Details über den Endzustand in der Spezifikation für Phase 2 oben mitgeteilt. Über diese Spezifikation hinaus und um es so sanft wie möglich auszudrücken: Es gibt viel zu viele Anwendungsfälle und Szenarien, als dass ich sie alle ausführlich mit Ihnen und dann auch mit dem Discourse.org-Team besprechen könnte, während ich daran arbeite ![]()
Ich werde den OP mit einem allgemeinen Überblick über das erwartete Verhalten aktualisieren, sobald Phase 2 abgeschlossen ist.
Ich kann dieses Problem nicht reproduzieren. Ich bin gerade feature@meta.discourse.org von einem Test-Mastodon-Konto gefolgt und habe weder in Mastodon noch in Discourse einen Fehler gesehen.
Es könnte mit der Instanz zusammenhängen, von der ich es übernommen habe. Macht diese Instanz etwas Ungewöhnliches?
Oh je, in meinem Versuch, eine klare Frage zu stellen, klang es, als würde ich viel Arbeit verlangen. Ich entschuldige mich für die missverständliche Kommunikation. Ich schätze die durchdachte Antwort.
Das war es, was ich fragen wollte, nicht fortlaufende detaillierte Updates in diesem Thread. Mein “nach” in “nachdem die derzeit spezifizierte Feature-Entwicklung abgeschlossen ist” sollte sich darauf beziehen, wann die Klärung wertvoll wäre, nicht darauf, dass ich jetzt den zukünftigen Zustand beschreiben möchte. Meine Frage war mehrdeutig formuliert. Entschuldigung dafür!
Das ist es, was ich wirklich verstehen wollte: Ist das Endziel, ganz allgemein gesprochen, Discourse auf das zu beschränken, was das kanonische ActivityPub unterstützt, oder ist es, von einer uneingeschränkten nativen Discourse-Erfahrung auf Best-Effort-Basis in das Fediverse zu föderieren? Meine bisherigen Erfahrungen mit Discourse-Integrationen hatten mich dazu veranlasst, Best-Effort zu erwarten; jetzt verstehe ich, dass es Ihr Plan ist, stattdessen Treue anzustreben, auf Kosten der Discourse-Funktionalität, und das nicht nur als vorübergehende Maßnahme während der Entwicklung.
Ich gehe nicht davon aus. Warum sollte ein Unterschied von vier Monaten hier eine Rolle spielen? Er ist neu in einer föderierten Kategorie, warum sollte das nicht dazu führen, dass die föderierende Kategorie ihn boostet? Ich zumindest hätte naiv erwartet, dass das passiert. Ich sehe oft Leute, die Beiträge boosten, die viele Monate alt sind, daher kenne ich keinen besonderen Grund, warum das hier anders sein sollte.
Und ja, ich denke, es wäre sinnvoll, ein Rückgängig für den ursprünglichen Boost zu senden. Das scheint üblich zu sein. (Tatsächlich scheint ein Rückgängig für einen Boost und dann ein neuer Boost ein typischer Mechanismus zu sein, um Inhalte zu “pushen”; unabhängig von diesem Zweck, aber es veranschaulicht, dass Rückgängig für Boost häufig verwendet wird und daher keine Probleme für andere ActivityPub-Implementierungen verursachen sollte.)
Ich sehe dasselbe gerade für feature@meta.discourse.org von mastodon.cloud, das meiner Meinung nach reines Vanilla Mastodon verwendet.
Persönlich denke ich nicht darüber nach. Discourse.org wird hier die allgemeine Agenda festlegen, aber ganz allgemein werden Entscheidungen auf der Grundlage getroffen, wie es funktioniert und was praktikabel ist. Wenn es eine sinnvolle und nachhaltige Möglichkeit gibt, Autorenänderungen an allen Beiträgen zuzulassen, unabhängig von der Herkunft, dann ist das großartig.
Wenn wir uns nur auf die Rückgängigmachung des ursprünglichen Boosts konzentrieren, scheint dieses spezielle Undo keinen Zweck zu erfüllen? Es ist in einigen Szenarien auch durchaus überraschend, wie mein Beispiel gezeigt hat. Die Absicht der Kategorieverschiebung könnte nicht darin bestehen, die ursprüngliche “Entdeckbarkeit” des Inhalts rückgängig zu machen (Undo). Es könnte darin bestehen, die Organisation des Inhalts aus einem anderen Grund im Nachhinein zu ändern.
Anders ausgedrückt: Die Anwendung einer automatischen Rückgängigmachung des ursprünglichen Announce bei einer Kategorieänderung in Discourse funktioniert in einigen Szenarien, in anderen jedoch nicht. Und selbst in Szenarien, in denen es sinnvoller erscheint, verursacht der ursprüngliche Announce keinen wirklichen Schaden. Daher erscheint es im Sinne des geringsten Schadens und der geringsten Überraschung sinnvoller, den ursprünglichen Announce einfach beizubehalten. Entschuldigen Sie, wenn ich etwas übersehe.
Wenn man es aus einem anderen Blickwinkel betrachtet, denke ich nicht, dass es richtig ist, Announce-Aktivitäten eines Kategorie-Akteurs als gleichbedeutend mit der taxonomischen Rolle von Kategorien selbst zu betrachten. Ein Announce ist die Art und Weise, wie ein Kategorie-Akteur Inhalte mit seinen Followern teilt, aber es ist keine Taxonomie selbst. Es ist eine Möglichkeit, wie Inhalte im Fediverse entdeckt werden. Ich glaube nicht, dass es eine 1:1-Beziehung zwischen Kategorien und den Announce-Aktivitäten von Kategorie-Akteuren geben muss.
Ah. Dann ist das wirklich eine Frage für das Team. ![]()
Das ergibt auch Sinn. Ich stimme zu, es hat keinen großen Wert, den Boost rückgängig zu machen.
Es handelt sich also um ein flankengetriggertes Signal; es würde bedeuten: „Ein Beitrag ist gerade in diese Kategorie eingetreten, entweder durch Erstellung oder durch Verschiebung in die Kategorie.“ Das ist konzeptionell einfach.
Ich würde dann daran denken, die Autorschaft eines Beitrags auf ähnliche Weise zu ändern. Es wäre der neue Akteur, der eine neue Aktivität für den Beitrag des neuen Autors erstellt, und es gibt keinen besonderen Grund, etwas mit der alten Aktivität zu tun, die unter dem alten Autor erstellt wurde, da der alte Autor keine Bearbeitungen vornehmen würde und nicht für diese neuen Änderungen gutgeschrieben werden sollte. Sie haben ihren Beitrag auf Discourse nicht tatsächlich gelöscht, daher würde das Löschen der ursprünglichen Autorschaft nicht unbedingt eine grundlegende Wahrheit widerspiegeln. Aber das, was zuvor vom Akteur des alten Autors gepostet worden war, wäre das, was er geschrieben hatte, und es gäbe keinen Grund, diese Beiträge zu löschen. Und wenn jemand dem Link zurück zu Discourse folgen würde, würde er den aktuellen Inhalt und die Autorschaft sehen, mit (bei ausreichenden Berechtigungen) der Möglichkeit, die Bearbeitungshistorie einzusehen.
Die gleiche Logik gilt für Wikis. Sie erscheinen auf Discourse unter einer einzigen Autorschaft, erlauben aber anderen, zu schreiben. Änderungen durch andere Autoren werden nicht allgemein zugeschrieben (es sei denn, Sie haben ausreichende Berechtigungen, die Historie einzusehen). Es ist nicht wirklich bedeutsam, ob diese Zuschreibung durch einen Avatar in der Webansicht innerhalb von Discourse oder einen ActivityPub-Akteur, der mit einer Aktivität verbunden ist, angezeigt wird; das Endergebnis ist eine Zuschreibung, die dem menschlichen Leser am Ende einer Rendering-Pipeline oder einer anderen präsentiert wird.
Hm, ich bin mir nicht sicher, ob ich zustimme. Das Endergebnis wird sein, dass zwei identische Notizen im Fediverse von verschiedenen Akteuren verfasst werden, die beide auf mehreren Plattformen sichtbar sein werden. Für eine neue Person, die zum ersten Mal auf diesen Inhalt stößt, werden dieselben Inhalte von verschiedenen Personen verfasst. Umgekehrt, wenn Sie einen Autor in Discourse ändern, schreiben Sie im Wesentlichen die Geschichte neu. Für eine neue Person, die zum ersten Mal auf den Inhalt stößt, sehen Sie nur den neuen Autor. Es gibt einen Unterschied, finden Sie nicht?
Ich bin mir nicht sicher, ob ich das vollständig verstehe. Sagen Sie, dass alle Bearbeitungen des Wiki-Beitrags von jedem Benutzer einfach als Standard-Update-Aktivitäten behandelt werden sollten, die dem ursprünglichen Akteur (d. h. der Person, die ihn gepostet hat) zugeschrieben werden?
Beachten Sie, dass dies der Gegenstand dieses PR ist, begleitet von erklärenden Notizen.

