@hellekin Danke für den Bericht. Bei einem ActivityPub-Dienst wird es immer zu einer bestimmten Anzahl fehlgeschlagener Anfragen kommen, da Akteure im Fediverse kommen und gehen. Zum Beispiel sieht es so aus:
Die Ausführlichkeit der Logs dient der Fehlersuche. Wenn sie jedoch Ihre Logs überladen, können Sie sie über die Website-Einstellung activity pub verbose logging umschalten. Standardmäßig ist sie deaktiviert.
Wir werden uns gegebenenfalls in Phase zwei um Verbesserungen bei der Fehlerbehandlung kümmern, aber bisher scheinen die von Ihnen geposteten Snippets erwartungsgemäß zu sein, d.h. die Akteure sind tatsächlich nicht mehr im Fediverse vorhanden.
Derzeit verfolgt das Plugin Lieferfehler auf die gleiche Weise wie Mastodon: Wenn es 7 Tage lang zu Fehlern an einem Endpunkt kommt, wird dieser als “nicht verfügbar” markiert und es werden keine weiteren Anfragen mehr versucht.
In der Tat, aber der Statuscode ist 410, was bedeutet, dass das Konto möglicherweise verschoben wurde (wenn es einen Tombstone gibt – wird diese Bedingung geprüft?)
ich habe gerade ein brandneues selbstgehostetes Discourse mit Ihrem AP-Plugin unter https://federation.cafe eingerichtet und sehe einige 403-Fehler in den Discourse-Fehlerprotokollen (und die Beiträge werden nicht geteilt).
Ich frage mich, ob es vielleicht daran liegt, dass Bindestriche vorhanden sind?
[Discourse Activity Pub] GET request to https://bofh.social/internal/fetch failed: Expected([200, 201, 202, 301, 302, 307, 308]) <=> Actual(403 Forbidden)
Hallo @gme, danke, dass du das Plugin ausprobiert hast
Ein paar Dinge, die hier zunächst zu beachten sind:
Das MVP-Plugin wird gegen Mastodon getestet. Ich sehe, dass du dort Pleroma verwendest. Ich weiß, dass Pleroma ActivityPub-konform ist und mit Mastodon funktioniert. Wir haben uns jedoch noch nicht genau angesehen, welche Anpassungen (falls überhaupt) erforderlich sind, um die Unterstützung dafür zu gewährleisten. Aber ich bin trotzdem daran interessiert zu sehen, was hier vor sich geht.
Es sieht so aus, als ob die Anfragen aufgrund eines Authentifizierungsfehlers auf deinem Pleroma-Server fehlgeschlagen sind (das bedeutet ein 403-Fehler). Da ich diesen Endpunkt mit einer nicht authentifizierten cURL-Anfrage abrufen kann, vermute ich, dass die HTTP-Authentifizierung am Pleroma-Ende fehlschlägt.
Um Letzteres (d. h. 2) zu testen, könntest du dir deine Pleroma-Protokolle ansehen (du bist anscheinend auch der Administrator dieses Servers?), um zu sehen, ob du dort weitere Details dazu finden kannst?
Danke für das Feedback, @bmann. Könntest du den Anwendungsfall, den du hier im Sinn hast, näher erläutern? Wenn möglich mit einem Beispiel.
Dieses Thema ist der beste Ort, um über Entwicklungen auf dem Laufenden zu bleiben. Sobald wir einen Plan für Phase 2 festgelegt haben, werde ich ihn hier teilen. In der Zwischenzeit ist der beste Weg zu helfen, spezifische Anwendungsfälle zu teilen, die du mit dem Plugin verwendest oder verwenden möchtest.
Der Anwendungsfall ist die Verwendung von Discourse als vollständigeren AP-Knoten. Es gibt viele einfachere Möglichkeiten, Inhalte an AP zu posten (z. B. Kategorie-RSS-Feeds und Zapier oder Buffer) – aber die Entwicklung umfassenderer AP-Funktionen kann nur als Plugin/Integration erfolgen.
Article ist der ActivityStream-Typ, der für vollständige Artikel gedacht ist. Je nach Client-Oberfläche wird eine Vorschau angezeigt und dann ein Klick, um den gesamten Artikel inline anzuzeigen (ähnlich wie Inhaltswarnungen, aber mit “Weiterlesen”).
Note ist der Microblogging-Typ.
Durch vollständige Artikelbeiträge können Personen direkt in ihren AP-Clients lesen / boosten / antworten.
Und natürlich wäre es interessant, etwas über Ihre Roadmap zu erfahren, wenn Sie einen Microblogging-AP-Instanz-Ansatz verfolgen oder in Richtung eines föderierten Forums wie Lemmy oder Kbin gehen, insbesondere angesichts der jüngsten Reddit-Nachrichten.
@angus, @pmusaraj habt ihr den offenen Aufruf für Fördermittel von NGI Sargasso gesehen? Das ist eine ziemlich kurze Ankündigung, aber es könnte nützlich sein, um die Entwicklung dieses Plugins weiter voranzutreiben (es sei denn, ihr habt bereits andere Pläne).
Hallo Leute, ich freue mich, sagen zu können, dass die zweite Phase der Arbeiten an diesem Plugin genehmigt wurde. Daran haben wir bereits mit der Arbeit begonnen, mit dem Ziel, es in etwa 3,5 Monaten zu veröffentlichen.
Unterstützung der Bearbeitung von Notizen nach der Veröffentlichung
Sonderzeichen behandeln (vielleicht einen anderen Parser verwenden). Mehr dazu.
Unterstützung der Verwendung von Article anstelle von Note als Objekt für einen Beitrag.
Einstellung auf Kategorieebene
Unterstützung der Annahme von Aktivitäten als Antwort auf eine Notiz, die auf entfernten Servern erstellt wurde, und der Veröffentlichung von Aktivitäten als Antwort auf eine Notiz, die in Discourse erstellt wurde.
Veröffentlichung von Aktivitäten bezüglich Antworten, die in Discourse erstellt wurden
Zulassen, dass Discourse-Benutzer als Akteure fungieren
Erstellen von Notizobjekten für Discourse-Antworten (Beiträge)
Veröffentlichen zugehöriger Create/Delete/Update/Undo-Aktivitäten für ihre entsprechenden Discourse-Aktionen
Annahme von Aktivitäten bezüglich Antworten, die auf entfernten Servern erstellt wurden
Staging der Akteure von Aktivitäten von entfernten Servern als Discourse-Benutzer
Erstellen von Discourse-Antworten (Beiträgen) aus Notizobjekten
Konvertieren zugehöriger Create/Delete/Update/Undo-Aktivitäten in ihre entsprechenden Discourse-Aktionen
Hinzufügen einer Kategorieeinstellung zum Umschalten zwischen nur dem ersten Beitrag (aktuell) und “Vollständiges Thema”, das Antwortaktivitäten unterstützt.
Unterstützung für Discourse-Benutzer, ihre Identität auf Mastodon zu verifizieren, damit von ihren Toots erstellte Discourse-Beiträge mit ihrem Discourse-Benutzerkonto verknüpft werden.
Ermöglichen Sie einem Benutzer, den Mastodon OAuth Authorization Flow mit dem Mastodon-Server durchzuführen, auf dem sein Konto gespeichert ist. Dies wird über die Discourse-Kontoeinstellungen des Benutzers initiiert.
Verwenden Sie das Mastodon-Zugriffstoken des Discourse-Benutzers, um die AP-ID seines Mastodon-Kontos abzurufen und zu speichern und es mit seinem Discourse-Konto zu speichern.
Verknüpfen Sie alle Discourse-Aktivitäten, die mit AP-Aktivitäten von einem Akteur mit der AP-ID eines Discourse-Benutzers verbunden sind, mit diesem Discourse-Benutzer, unabhängig davon, ob sie vor oder nach der Identitätsprüfung des Benutzers durchgeführt wurden.
Es kann einige Zwischenversionen geben, aber ich kann diesbezüglich noch nichts versprechen. Ich werde Sie auf dem Laufenden halten, während wir Fortschritte machen.
Ich kann zu diesem Zeitpunkt keine Versprechungen machen, aber es könnte durchaus Zwischen-Updates für die Föderation und die Zielgruppenansprache (öffentliche Veröffentlichung) geben.
Das ist eine bekannte Einschränkung. Bis die Föderation von Bearbeitungen unterstützt wird, blockiert das Plugin Bearbeitungen an föderierten Inhalten, und es gibt keine Konfiguration, um dies zu deaktivieren.
Es tut mir leid, dass ich das missverstanden habe. @feature@meta.discourse.org und @announcements@meta.discourse.org werden zumindest von hier aus föderiert, und diese Wahl ist der Hauptgrund, warum ich dies für Maker Forums nicht aktiviert habe …
Ja, das ist der erste Punkt in Phase 2, an dem ich gearbeitet habe. Tatsächlich gibt es dafür bereits einen PR, sodass Sie diesbezüglich bald Erleichterung erfahren werden.
