It has nothing to actually do with Discourse so you’ll want to ask the feed2toot project. Good luck.
Thanks James for the information
Keith
Matrix commenting might be interest, since it is able to federate / “bridge” with other chat systems. Not ActivityPub based, but it is both decentralized and currently supported to x-post to Matrix via Chat Integration plugin.
„Warum Föderationsprotokolle nicht funktionieren“
„Der Wert der Freiheit“
Ich finde das nicht sehr überzeugend. Es läuft auf Folgendes hinaus:
- XMPP ist ein Chaos
- Föderation löst keine Datenschutzbedenken bezüglich Metadaten
- Die Behauptung „Das Adressbuch des Geräts ist jetzt das soziale Netzwerk“.
Das erste kann wahr sein, ohne allgemein zu sein, und der Artikel versucht nicht einmal, ein allgemeines Argument zu machen, über „Schauen Sie sich die GitHub-Issue-Vorlagen an“, was … eher wie eine Beschwerde darüber ist, wie das implementiert ist, als ein sinnvoller Punkt.
Das zweite scheint vollkommen richtig zu sein, aber auch nicht der einzige Grund für die Föderation, und für mich scheint es kein Blocker zu sein – perfekt ist des Guten Feind usw.
Und das dritte Ding … Ich glaube nicht, dass das wahr ist, außer in einem engen Sinne, und in diesem Sinne ist es nicht wirklich das, was ich will. Ja, ich kann 20+ Messaging-Apps in einem Ordner auf meinem Handy haben und sie teilen sich meistens ein Adressbuch … aber das ist für mich kein „Problem gelöst!“!
aus dem Ende von Matthews (Matrix) Antwort an Moxie (Signal)
Es stimmt, dass Moxies Ansatz eine Möglichkeit ist, wenn man eine Messaging-App schreibt, die auf Kosten der Privatsphäre optimiert ist. Dies führt jedoch zu einer pervers geschlossenen Welt – einem geschlossenen Netzwerk, in dem inoffizielle Clients verboten sind, auf dem keine Plattform aufgebaut werden kann, keine offenen Standards existieren und man letztendlich alle Eier in einen Korb legt und darauf vertraut, dass Signal seine Werte beibehält, aufsteht und irgendwie Kompromissen und Zensur ausweicht – obwohl es wahrscheinlich das mit Abstand wertvollste Angriffsziel im Netz ist.
Ganz einfach, das ist keine Welt, in der ich leben möchte.
Wir verdanken den gesamten Erfolg des Internets (ganz zu schweigen vom Web) Offenheit, Interoperabilität und Dezentralisierung. Zu erklären, dass Offenheit, Interoperabilität und Dezentralisierung „zu schwierig“ und die Mühe bei der Entwicklung einer Messaging-Lösung nicht wert sind, bedeutet, das gesamte Potenzial der Lebendigkeit, Kreativität und Innovation zu verschenken, die aus einem offenen Netzwerk entstehen. Sicher, man erhält vielleicht eine super-private Messaging-App – aber eine, die beunruhigend nach einem abgeschotteten Garten wie Facebooks Internet.org-Initiative, einem AOL-Stichwort oder Googles AMP riecht.
Daher nehmen wir Moxies Herausforderung gerne an, ihn zu widerlegen – um zu zeigen, dass es sowohl möglich als auch zwingend erforderlich ist, eine offene, dezentrale Messaging-Plattform zu schaffen, die (wenn man seriöse Apps und Server verwendet) genauso sicher und Metadaten-schützend wie Signal sein kann … und sogar noch mehr, da man seinen Server offline betreiben kann und sich nicht mit einer Telefonnummer registrieren muss und in Zukunft möglicherweise nicht einmal mehr einen Server benötigt.
Außerdem stammt Moxies Beitrag aus dem Jahr 2016, nur zwei Jahre nach der Einführung des Matrix-Protokolls und zwei Jahre vor der Veröffentlichung von ActivityPub.
Es ist zwar schön, dass ich meine eigene E-Mail hosten kann, aber das ist auch der Grund, warum meine E-Mail nicht Ende-zu-Ende-verschlüsselt ist und wahrscheinlich auch nie sein wird.
Seitdem ist Delta.chat erschienen, das auf E-Mail-Protokollen und Autocrypt aufbaut, was diese Aussage zweifellos falsch macht: E-Mail ist E2EE – und das war sie auch schon vorher mit OpenPGP, aber Autocrypt macht es den Leuten tatsächlich viel einfacher, Ende-zu-Ende-Verschlüsselung zu nutzen.
Es wäre für Discourse absolut machbar, Autocrypt zu implementieren, und würde sicherlich dazu beitragen, das Beste aus beiden Welten zu erreichen – zentralisiert und föderiert. Aber natürlich, wenn Discourse gestufte Benutzer als Einstiegspunkt für die Föderation zwischen Discourse-Instanzen überhaupt einführen würde, wäre es viel sinnvoller, über Föderation zu diskutieren. Moxies Interesse galt damals der Rechtfertigung, warum er es den Leuten nicht erlauben würde, ihre eigenen Signal-Server bereitzustellen. Und ja, es gibt viele Protokolle in Arbeit, um alle möglichen Probleme zu lösen, einschließlich der Aktualisierung von Clients.
Das liest sich wie eine separate Funktionsanfrage
Würden Sie bitte ein weiteres Thema erstellen, das dies beschreibt, oder gibt es bereits eines dazu?
Ich glaube, ich habe das schon vor einiger Zeit in einer ähnlichen Diskussion vorgeschlagen. Lassen Sie mich das finden…
- ActivityPub Support: Phase 1 RFC - #7 by hellekin
- ActivityPub Support: Phase 1 RFC - #45 by hellekin
Fühlen Sie sich frei, den Vorschlag in einem neuen Feature-Thema zusammenzufassen.
Wir müssen USENET neu erfinden…
Hier ist ein weiterer Artikel von Mathew über Matrix, eine föderierte Plattform. Wichtigstes Zitat:
Es ist, als hätte USENET ein Kind mit dem Web bekommen!
![]()
In einer Föderationsdiskussion über E2E zu sprechen, ergibt überhaupt keinen Sinn. Kann jemand diese Antworten bitte in ein neues Thema verschieben?
Vielleicht ist das Lemmy-Protokoll ein guter Anfang.
Sie haben bereits den E-Mail-Listenmodus, und er funktioniert ähnlich (außer dass er über Fedi läuft).
Es gibt eine Zoom-Veranstaltung 2022-04-28T20:00:00Z
In der heutigen Social-Media-Welt haben wir gesehen, wie Plattformen angesichts der Geißeln von Fehlinformationen und Trolling außer Kontrolle geraten sind. In autoritären Regimen werden ganze Plattformen leicht blockiert. Und ja, ein Milliardär kann eine Plattform kaufen und die Regeln ändern.
Wären dezentrale (oder P-2-P) soziale Medien, bei denen es keine zentrale Kontrollinstanz gibt, besser? Wie nimmt man schädliche Beiträge herunter, wenn es keine zentrale Kommandozentrale gibt? Die Gründer einiger der Top-Plattformen für dezentrale soziale Medien, von Matrix über Manyverse bis hin zur neuen Bluesky-Initiative, führen Sie durch die Möglichkeiten. Mit Demonstrationen, wie diese Peer-to-Peer-Alternativen zu Facebook, Slack und Twitter genutzt werden können.
Über unsere Sprecher:
Jay Graber ist CEO von Bluesky, der von Jack Dorsey und Twitter finanzierten Initiative, „um die groß angelegte Einführung von Technologien für eine offene und dezentrale öffentliche Konversation zu entwickeln und voranzutreiben“.
Matthew Hodgson ist Mitbegründer von https://matrix.org/. Matrix ist ein offenes Netzwerk für sichere, dezentrale Kommunikation mit mehr als 40 Millionen Nutzern.
Andre Staltz ist der Schöpfer von Manyverse, einem kostenlosen Open-Source-“sozialen Netzwerk ohne die schlechten Dinge”, das auf dem Peer-to-Peer-SSB-Protokoll aufbaut.
Diese Veranstaltung ist Teil einer Reihe von Workshops, die vom Metropolitan New York Library Council, dem Internet Archive, DWeb und Library Futures präsentiert werden. Erfahren Sie mehr hier: https://metro.org/decentralizedweb
Bitte lesen Sie unseren Verhaltenskodex, unsere Erklärung zu Standpunkten und Details zu Dolmetscherdiensten hier: https://metro.org/code-of-conduct
Das. Möglicherweise auch die Integration von entfernten „Gefällt mir“-Aktionen.
Ich habe bemerkt, dass das Fediverse merklich aktiver und bevölkerungsreicher geworden ist, seit Elon Musk mit seinem Übernahmeangebot für Twitter begonnen hat.
Auf den Discourse-Instanzen, die ich betreibe (derzeit drei davon), würde ich gerne Mastodon (in meinem Fall) nutzen können, um sie zu verfolgen und einem breiteren Publikum zu „boosten“, um die Informationen auf meinen Instanzen für eine Menge anderer zugänglicher und sichtbarer zu machen, denen das wichtig sein könnte. Alle meine Instanzen dienen der Erweiterung des öffentlichen Wissens zu verschiedenen Themen, und eine umfassende Sharing-Unterstützung durch ActivityPub-Integration wäre hilfreich, um dieses Ziel zu erreichen.
Die Konvertierung von RSS in ActivityPub würde nicht viel helfen.
Wenn dies mein Projekt wäre, würde es in Phasen erfolgen und einfach beginnen:
- Nur Veröffentlichung: Kategorien als Akteure, einschließlich Antwortbeiträgen zu Themen, die ordnungsgemäß mit
inReplyToverknüpft sind. Diese werden an Follower pro Beitrag gesendet, gleichzeitig mit der Weiterleitung von Beiträgen an Chat-Integrationen. Dies würde erfordern, dass (zumindest einige) Kategorien als Akteure veröffentlicht werden und Follower für jeden Akteur gespeichert werden. Diese Kategorie-Akteure würden nicht folgen oder mögen. Es würde kein authentifizierter Zugriff verwendet. Es würde Aktivitäten wie „Gefällt mir“, „Blockieren“ und „Rückgängig machen“ berücksichtigen. Vielleicht auch ein Akteur für den gesamten Server, um alle Aktivitäten auf dem Server leicht verfolgen zu können. - Minimale bidirektionale Kommunikation: Akzeptieren Sie optional entfernte „Gefällt mir“-Aktionen.
- Mehr bidirektionale Kommunikation: Interagieren Sie mit „Ankündigungs“-Aktionen (d. h. Teilen, Reposten, Boosten), entweder indem Sie sie als „Gefällt mir“-Angaben hinzufügen oder sie separat anzeigen.
- Benutzerinteraktion: Optional Webfinger-Unterstützung für Benutzer, um Benutzer als Akteure verfolgen zu können, um alle ihre Beiträge zu sehen. Weiterhin optional, begrenzt nach Gruppe (ich möchte es vielleicht auf TL2 beschränken), die Möglichkeit, mit externen ActivityPub-Akteuren in PMs zu interagieren. Dies könnte möglicherweise die Sammlung der vom Benutzer gelikten Beiträge (zumindest öffentliche) in der Sammlung
likedimplementieren. - Textuelle bidirektionale Kommunikation: Akzeptieren Sie optional Nicht-Mitglieder-Antworten über ActivityPub als Kommentare – aber das ist knifflig, da es diese naiv als neuen Beitrag zurückspiegeln würde, sodass Follower sie zweimal sehen würden. Wahrscheinlich müssten Beiträge mit ihrem externen Verweis gekennzeichnet und nicht an die Posteingänge der Follower gesendet werden.
Ich würde ausdrücklich nicht die Unterstützung für das „Folgen“ von ActivityPub-Akteuren innerhalb von Discourse wünschen; Discourse in ein (z. B.) Mastodon-Klon zu verwandeln, scheint rundum eine Verschwendung zu sein. In der Sprache der ActivityPub-Spezifikation wäre es kein „ActivityPub-konformer föderierter Server“, und das ist in Ordnung. Auch der Client-Teil des Protokolls hat in diesem Plan keinen Platz.
Habe diese Diskussion über ActivityPub-Implementierungen in Rails gefunden. Es könnte sich lohnen, die Diskussion dort fortzusetzen. ![]()
Haben Sie Vorschläge, wie ich 4 Foren föderieren könnte? Sie sind ziemlich groß (100.000, 20.000, 50.000, 20.000 Mitglieder). Insgesamt 200.000.
Sie können keine Föderation einrichten. Sie könnten eine benutzerdefinierte SSO- oder LDAP-Authentifizierung einrichten, die alle Benutzer für den Zugriff auf jedes Forum mit gemeinsamen Anmeldeinformationen gemeinsam nutzen können.
Sie können auch versuchen, ein Plugin zu erstellen, um sie zu integrieren.