Bei mir ist es dasselbe. Ich kann den Besitzer eines Threads nicht ändern. Obwohl die Kategorie NICHT föderiert ist.
Das sind Warnungen, keine Fehler. Sie bedeuten nicht unbedingt, dass etwas schief läuft, sondern geben Ihnen mehr Informationen darüber, was vor sich geht. Es kann eine Reihe von Gründen geben, warum Inhalte aus dem Fediverse nicht verarbeitet werden, von denen viele mit der Person zusammenhängen, die die Inhalte sendet. Wenn Sie nicht möchten, dass sie in Ihren Protokollen angezeigt werden, deaktivieren Sie die ausführliche Protokollierung für das ActivityPub-Plugin (activity pub verbose logging).
Befindet sich das Thema in einer ActivityPub-Kategorie oder hat es ein ActivityPub-Tag?
Wurde das Thema in einer ActivityPub-Kategorie erstellt oder mit einem ActivityPub-Tag versehen?
Bitte beachten Sie, dass das Ändern des Besitzers von Themen für ActivityPub-Themen absichtlich deaktiviert ist. Warum dies der Fall ist, entnehmen Sie bitte dem obigen Link:
Es ist eine Kategorie mit Activitypub, aber wir sprechen über den Besitzer des Threads, der nicht mit Activitypub zu tun hat, da es sich um ein anderes Konto handelt.
Ich denke, es sollte trotzdem eine Option geben, den Besitzer zu wechseln, sonst ergibt es keinen Sinn, dass Discourse das Modal zum Wechseln des Besitzers hat.
Außerdem ist es für uns perfekt, es zu ändern, ohne Updates an Activitypub zu senden.
1 „Gefällt mir“
Ich verstehe, dass die Leute die Möglichkeit haben wollen, den Besitz von Beiträgen zu ändern. Das Problem, das in dieser Hinsicht angegangen werden muss, ist das, das ich oben dargelegt habe, insbesondere dies:
Die Inhalte, die auf Ihrem Discourse erscheinen, stammen von einem Dienst, bei dem Sie kein Administrator sind und über den Sie – abgesehen von ActivityPub – keinerlei Kontrolle hätten. Die Möglichkeit, den Autor dieser Inhalte einfach zu ändern, ohne dies angemessen zu berücksichtigen, wäre nicht ratsam.
Was Inhalte betrifft, die von Benutzern Ihres Discourse in einem über ActivityPub veröffentlichten Thema verfasst wurden, überlegen Sie, was passieren soll, wenn nach der Änderung des Beitragsautors Aktualisierungen an den Inhalten vorgenommen werden. Sollen wir:
- ActivityPub-Updates stoppen? Oder
- sie vom „alten“ Actor (Benutzer) veröffentlichen? Oder
- sie vom „neuen“ Actor (Benutzer) veröffentlichen?
Das Veröffentlichen von Update-Aktivitäten für ein bestehendes Objekt mit einem neuen Actor (d. h. 3) funktioniert mit Discourse (wie ich versucht habe, dies zu ermöglichen), aber es funktioniert nicht mit anderen ActivityPub-Diensten. Tatsächlich habe ich aus diesem Grund im ActivityPub-Ökosystem bereits auf diesen Punkt gedrängt. Sehen Sie hier:
Und ich habe eine offene PR für Mastodon, um 3 zu ermöglichen
Um nur eines der Probleme hier als Beispiel zu nennen: Stellen Sie sich vor, Sie veröffentlichen ActivityPub-Inhalte mit Ihrem Konto (und Ihrem Namen und Bild). Einer Ihrer „Konkurrenten“ folgt Ihren Inhalten. Auf seinem Server ändert er dann den Besitz aller Beiträge mit Ihren Inhalten, sodass sie von ihm (mit seinem Namen und seinem Bild) statt von Ihnen stammen. Das könnte Sie, einigermaßen verständlicherweise, verärgern. Ja, natürlich ist dies ohnehin mit benutzerdefiniertem Code möglich, aber die Frage ist, ob Sie dies in die Standardfunktionen des Plugins integrieren möchten.
Als ich über Nacht darüber nachdachte, könnte ein Ansatz, der dies etwas abmildern könnte, darin bestehen, den veröffentlichnden Actor in der ActivityPub-Statusanzeige anzuzeigen:
Ich bin offen für andere Ideen in diese Richtung.
Stimmt, ich denke, ich werde das Modal für ActivityPub-Themen ganz entfernen, bis wir die zugrunde liegende Frage hier geklärt haben.
2 „Gefällt mir“
Ich verstehe das Problem. In unserem Fall verwenden wir Activitypub mit einem Konto für jede Kategorie und veröffentlichen diese Aktualisierung. Daher ist es für uns bei Activitypub aus verschiedenen Gründen nicht so wichtig, wer der Besitzer des Threads ist. Aus diesem Grund sage ich, dass wir es trotzdem tun können.
ActivityPub dreht sich nicht nur darum, wie Sie Ihr Forum nutzen, sondern auch darum, wie Ihr Forum mit dem Rest des Fediverse interagiert. Darüber hinaus müssen wir bei der Entwicklung von etwas für das Plugin auch andere Anwendungsfälle berücksichtigen.
Ich möchte nicht den Eindruck erwecken, dass die Änderung des Beitragsbesitzers kein Thema ist, das aktiv in Erwägung gezogen wird oder das in einem zukünftigen Update nicht zugelassen wird. Ich bin an allen Ideen interessiert, die die zugrunde liegenden Probleme lösen, von denen ich einige oben dargelegt habe.
Als Reaktion auf dieses Beispiel wäre es sinnvoll, die Änderung des Besitzes von Beiträgen, die über Föderation empfangen wurden, zu verbieten, während Administratoren der Besitz von Beiträgen, die innerhalb dieser Discourse-Instanz erstellt wurden, geändert werden kann, unabhängig davon, ob sie föderiert sind oder nicht.
Ein Administrator kann einen Benutzer vortäuschen. Daher ist ein Administrator in der Lage, innerhalb der Plattform mit den vorhandenen Möglichkeiten Inhalte zu erstellen, die sich als jeder Benutzer auf der Plattform ausgeben. Ich hoffe, dass Administratoren diese Macht nicht missbrauchen; ich tue es nicht. Diese Macht ist jedoch in ihrer Auswirkung ähnlich wie die Fähigkeit, den Besitz eines Beitrags zu ändern, ob föderiert oder nicht. Im Allgemeinen gilt „ein Administrator kann etwas Bösartiges tun“ bereits auf vielfältige Weise.
Ich stimme zu (zumindest soweit ich es verstehe 
), dass die Änderung des Besitzes eines Beitrags, der durch Föderation erstellt wurde (also kein Thema-Beitrag?), nicht viel Sinn ergibt. Im Gegensatz zur Änderung des Besitzes von Beiträgen, die auf der Website erstellt wurden, erinnere ich mich nicht, einen Anwendungsfall formuliert zu haben.
Dies gefällt mir nicht nur unter dem Gesichtspunkt der Robustheit gegen diese Art von Angriff, sondern auch, um die Föderation sichtbarer zu machen und es einem Website-Besucher zu erleichtern, Schauspieler zu finden, denen er folgen kann. Wie würde das für einen Fall aussehen, in dem es einen Kategorie-Actor (und vielleicht eines Tages einen Website-Actor?) und einen Personen-Actor gibt? Würden Sie eine Liste haben?
- Veröffentlicht von
[@category@site](link) - Veröffentlicht von
[@person@site](link)
1 „Gefällt mir“
Vielen Dank für Ihre hilfreiche Analyse.
Einverstanden.
Diese Analyse gilt nur für nicht föderierte Beiträge. Die Frage ist nicht, ob die Änderung eines Beitragsinhabers für Discourse selbst sinnvoll ist. Die Frage ist, welche Auswirkungen die Änderung des Eigentümers auf föderierte Inhalte hat. Wenn Sie den Eigentümer eines lokalen Beitrags ändern, der föderiert wurde, müssen Sie sich mit dieser Frage befassen:
Ich möchte zunächst darauf hinweisen, dass sowohl 1 als auch 2 erhebliche Probleme aufweisen, die ich bei Bedarf erläutern kann. Die Antwort ist möglicherweise die, die das Plugin bereits unterstützt, nämlich „3“. Wenn wir diesen Weg jedoch einschlagen, wird Folgendes passieren (vorausgesetzt, mein aktueller PR für Mastodon wird nicht zusammengeführt):
- Thema wird föderiert.
- Beiträge aus dem Thema erscheinen auf Mastodon.
- Website-Administrator ändert den Beitragsinhaber.
- Neuer Beitragsinhaber nimmt verschiedene Änderungen am Beitrag vor.
- Änderungen erreichen Mastodon (oder eine andere ActivityPub-Plattform) nicht.
Und daraus folgend:
- Jemand wird hierher kommen und sagen: „Meine Änderungen werden nicht föderiert.“ Der Grund dafür wird nicht sofort ersichtlich sein, da sie aus Sicht von Discourse föderiert werden.
Der springende Punkt ist, dass wir, wenn wir diesen Ansatz verfolgen, die erste Plattform im Fediverse (soweit ich weiß) wären, die dies tut. Der einzige Knotenpunkt in einem vernetzten System von Knotenpunkten zu sein, der etwas tut, ist keine offensichtlich wünschenswerte Sache. Wir können in dieser Hinsicht eine Änderung anstoßen, aber wir müssen uns bewusst sein, dass wir dies versuchen würden.
Das gesagt, ich habe 3 bereits implementiert, und ich vermute, dass dies die endgültige Antwort sein wird, die es mir ermöglicht, diese Einschränkung aufzuheben. Ich hoffe immer noch, dass jemand einen etwas differenzierteren Ansatz finden kann oder etwas, an das ich noch nicht gedacht habe.
Nur der attributedTo-Akteur des Objekts würde aufgelistet, sodass es nur einen gäbe.
1 „Gefällt mir“
Ich sehe die Hässlichkeit. Der Gedankengang, der mich dorthin gebracht hat, ist ungefähr so:
Ich könnte mir naiv etwas wie Nr. 3 mit nur einem kleinen Teil von Nr. 2 vorstellen – um auch ein generiertes Update vom alten Benutzer zu föderieren, das der letzten von ihm veröffentlichten Version oben oder unten einen systemgenerierten Text hinzufügt, der vage lautet: „Für zukünftige Updates folgen Sie @newuser@site“.
Dann wäre es (wieder naiv) sinnvoll, eine neue ID für den aktualisierten Beitrag unter dem neuen attributedTo zuzuweisen, die für die Updates des neuen Besitzers verwendet wird.
Ein offensichtlicher Randfall wäre die Rückübertragung des Besitzes an den ursprünglichen Eigentümer – wird zur alten Beitrags-ID zurückgekehrt oder eine weitere ID zugewiesen? Ich würde denken, zurückkehren, in welchem Fall die föderierte Beitrags-ID tatsächlich ein Schlüssel zu einem (Benutzer, Discourse-Beitrag)-Tupel sein müsste. Ich würde erwarten, dass dies eine Migration zur Unterstützung mit Abwärtskompatibilität erfordert.
All das als Gedankenexperiment lässt mich klarer erkennen, warum Sie nicht eilig damit wären, Ihren vorgeschlagenen Wechsel zu Mastodon zu überdenken! 
Ausschließlich Ihres Mastodon-PRs, der akzeptiert wird, könnte ich mir vorstellen, einzelne Beiträge als unföderiert zu markieren, die als Löschung föderiert werden, wenn sie zuvor föderiert wurden, und/oder die mit installiertem Plugin, aber vor der Aktivierung der Föderation erfolgen könnten, und dann die Besitzänderung nur für unföderierte Beiträge zu ermöglichen. Alle Beiträge, bei denen ich den Besitz ändern möchte, sind Beiträge, die meiner Meinung nach nicht wertvoll zu föderieren sind.
Ich könnte mir vorstellen, dass dies auch dann wertvoll wäre, wenn Ihr Mastodon-PR akzeptiert wird und die Besitzänderung unterstützt wird. Ich bin mir nicht sicher, ob es irgendeinen Sinn ergibt, die Kategorie-Themenbeiträge zu föderieren. Zumindest glaube ich, würde ich alle von ihnen von der Föderation auf meiner Website ausschließen, selbst wenn die Besitzänderung unterstützt würde, wenn ich die Möglichkeit hätte, sie auszuschließen.
Ein interessantes Gedankenexperiment, das jedoch aus mehreren Gründen nicht funktionieren würde.
- Sie folgen in Discourse ActivityPub keinen einzelnen Benutzern.
- Sie können die ID eines vorhandenen ActivityPub-Objekts nicht ändern (Sie müssten ein neues Objekt erstellen).
- Wie Sie sagen, wenn sich der Besitz erneut oder mehrmals ändert, hätten Sie am Ende mehrere Objekte für einen Beitrag, was unüberschaubar wäre.
Eine Sache, die ich jetzt in dieser Richtung tun kann, ist, die Einschränkung darauf zu ändern, ob der erste Beitrag in einem lokalen Thema veröffentlicht wird. Das wird bei einigen Themen helfen, wie Sie sagen.
1 „Gefällt mir“
Mein Missverständnis; Ich dachte, Sie hätten auch die Möglichkeit dazu geschaffen, sowie Kategorie-Akteure. (Keine Funktionsanfrage, nur ein Missverständnis.)
Das war es, was ich zu beschreiben versucht habe, und offensichtlich gescheitert. Es war ohnehin als eine Art reductio ad absurdum gedacht. 
Das wäre wunderbar! 
1 „Gefällt mir“
Hallo, gibt es eine Einschränkung für Lemmy?
Ich kann @batepapo@lemmy.eco.br zum Beispiel nicht folgen.
Tatsächlich kann ich folgen. Die Schaltfläche “Entfolgen” erscheint sogar unter dem Profil, aber wenn ich die Seite aktualisiere, verschwindet alles.
1 „Gefällt mir“
Tolle Arbeit! Ich habe eine Frage bezüglich der Verzögerung bei der Zustellung von ActivityPub-Nachrichten in Minuten. Gibt es eine Möglichkeit, die Funktion zu deaktivieren, damit der Beitrag sofort sichtbar ist?
Einstellung 1 Minute ist fast sofort, aber ich möchte auch Echtzeit posten.
1 „Gefällt mir“
@David_Ghost lies das
2 „Gefällt mir“
Das ist auch das Erste, was mir aufgefallen ist. Was wäre der Nachteil, den Titel eines neuen Themas in den über ActivityPub verteilten Beitrag aufzunehmen?
[Discourse-Thementitel]
[leere Zeile]
[Discourse-Thementext, wie jetzt veröffentlicht]
Die Lemmy-Leute haben daran gearbeitet, die Discourse-Kompatibilität hinzuzufügen. Es steht auf meiner Agenda, das zu überprüfen.
Das bedeutet, dass Discourse ein „Follow“ sendet, aber kein „Accept“ von Lemmy zurückbekommt.
Derzeit können Sie dies nur mit einer Umgebungsvariable tun (z. B. in Ihrer app.yml-Datei festlegen)
DISCOURSE_ACTIVITY_PUB_DELIVERY_DELAY=0
Der Titel eines Themas wird bereits veröffentlicht. Es ist der name der Sammlung, die dem Thema zugeordnet ist.
So erfolgt die Verbundkommunikation von Discourse zu Discourse oder von Discourse zu NodeBB oder von Discourse zu jeder Forum-ähnlichen Plattform, einschließlich der Thementitel. Mastodon verarbeitet keine Titel. Wenn wir den Thementitel in den Inhalt der Notiz aufnehmen würden, wie Sie vorschlagen, würde dies Probleme verursachen, z. B. wenn Inhalte auf Plattformen verbreitet werden, die Titel unterstützen.
Grundsätzlich besteht die von Ihnen beschriebene Einschränkung darin, dass Mastodon eine Micro-Blogging-Plattform ist. Wir haben bereits Funktionalität hinzugefügt, um dem Rechnung zu tragen, d. h. die [note][/note]-Markup, damit Sie den Inhalt, den Sie verbreiten, gezielt auswählen können. Wenn Sie eine echte Forum-ähnliche Verbundkommunikation wünschen, empfehle ich die Verbundkommunikation mit anderen Discourse-Instanzen.
Ja, es gibt viele Mastodon-Instanzen. Aber es gibt auch viele Discourse-Instanzen. Wenn eine Discourse-Instanz, mit der Sie kommunizieren möchten, noch nicht dafür eingerichtet ist, helfe ich ihnen gerne bei der Einrichtung.
5 „Gefällt mir“
Ist es möglich, Akteure zu löschen?
Und wäre es möglich, mehrere Kategorien einzurichten, damit er alles postet, was neu in Discourse ist?
Andernfalls müsste jemand xx Handles auf Mastodon verfolgen, um alle Inhalte aus allen Kategorien zu erhalten.
Sie können einen Akteur deaktivieren, was alles deaktiviert, was mit diesem Akteur zusammenhängt.
Wenn Sie die Kategorie oder den Tag löschen, mit dem der Akteur verknüpft ist, wird der Akteur gelöscht. Das Löschen eines Akteurs isoliert ist derzeit nicht möglich. Ich würde empfehlen, den Akteur einfach zu deaktivieren.
Dies könnte in Zukunft (mittel- bis langfristig) möglich sein, wenn wir einen “Anwendungs”-Akteur für ein ganzes Discourse hinzufügen. Die Föderation von allem in einem Discourse über einen einzigen Akteur wird wahrscheinlich immer ein Nischenanwendungsfall sein.
1 „Gefällt mir“
Hm, okay. Vielleicht verstehe ich die Möglichkeiten anders…
Gestern habe ich es eingerichtet und es hat gut funktioniert. Ich habe die Beiträge auf Discourse gelöscht, weil ich es nur getestet habe, aber die Beiträge sind immer noch online auf Mastodon. Deshalb dachte ich, ich könnte das Konto löschen, um auch die Inhalte von Mastodon zu löschen.
Wenn ich es nur deaktiviere, sind die Inhalte immer noch online auf Mastodon.
Und wenn ich es nicht löschen kann, kann ich diesen Handle in Zukunft nicht mit anderen Kategorien verwenden. Vielleicht möchte ich in Zukunft einige Kategorien ändern, aber ich kann ihn nicht mit diesem Handle verwenden, der xx Follower hat. Also muss ich einen neuen Handle erstellen und jeder muss ihm wieder folgen. Ich sehe keine Vorteile darin, einen Handle, den ich nicht mehr brauche, nur zu deaktivieren.
Und: Wenn ich einen Handle deaktiviere, ist der andere auch deaktiviert. Kann ich also nur mehrere Handles gleichzeitig betreiben oder gar keine?
Aber das ist es, was ich will, oder verstehe ich das falsch? Ich möchte Personen in einem sozialen Netzwerk über die Diskussionen in meinem gesamten Discourse informieren und nicht nur über ein Tag oder eine Kategorie. Wenn ich einen “Nachrichten”-Bereich betreibe, kann ich das verstehen, aber ich möchte, dass jeder an den Diskussionen teilnimmt, also muss ich alles posten und nicht nur eine Kategorie.