Ein häufiges Problem, mit dem viele Discourse-Nutzer konfrontiert sind, ist die Unmöglichkeit, eine Zusammenfassung aller Interessengruppen anzuzeigen, denen sie folgen. Es gibt keine einfache Möglichkeit, Inhalte von mehreren Discourse-Instanzen in Form eines zentralen und sozialen Benutzerfeeds zu konsumieren. Zentralisierte Plattformen wie Reddit umgehen dies, indem sie eine einzige Anmeldung für alle Communities und einen aggregierten Feed aller Communities in einem einzigen Stream auf der reddit.com-Startseite bieten. Genau diese letztere Funktion möchten wir in Discourse mithilfe des ActivityPub-Protokolls nachbilden.
Zum Beispiel besucht Person A mehrere Discourse-Instanzen: eine für Politik, zwei für Hobbys, eine für ihr lokales Nachbarschaftsforum, hat aber keine Möglichkeit, alle relevanten Inhalte in einem einzigen Feed zu konsumieren. Im Vergleich dazu erscheinen die relevantesten Beiträge bereits in deinem Feed, wenn du mehreren Facebook-Gruppen oder Reddit-Subs beigetreten bist.
Spezifikation (v1)
Wir könnten einen MVP (Minimum Viable Product) prototypisieren, indem wir folgende Funktionen über ein Discourse-Plugin aktivieren:
Generierung eines ActivityPub-Feeds auf Anfrage (für jede Seite, die bereits einen RSS-Feed hat)
Ähnlich wie beim Hinzufügen von .rss zur URL ermöglicht dies das Abrufen von Inhalten über das AP-Protokoll, wenn der richtige Endpunkt angefordert wird.
Wir könnten dies sogar für private Inhalte aktivieren, indem wir Benutzer-API-Schlüssel an die URL anhängen.
Forum-Administratoren können ActivityPub (ausgehend) pro Kategorie aktivieren oder es standardmäßig aktivieren? (Ich glaube, @Falco hatte dazu einige Gedanken)
Einen Weg finden, diesen Inhalt in einem Discourse-Forum / Mastodon-Feed zu konsumieren (eingehend)
Nächste Schritte
Wir müssen definitiv klein anfangen, also müssen wir zunächst eine kleine, machbare Menge an Funktionen festlegen, die in die erste Iteration einfließen. Ich habe mich durch das ActivityPub-Protokoll gearbeitet, bin aber mit den inneren Abläufen noch nicht sehr vertraut. Daher lade ich andere, die sich sehr dafür interessiert haben, zur Diskussion ein (@Falco, @hellekin, @merefield), um uns bei der Erstellung einer machbaren Spezifikation für die erste Iteration zu unterstützen und Änderungen an der obigen Spezifikation vorzuschlagen.
Ich würde zunächst sagen: Sollten wir uns nicht vorerst auf das Was und nicht auf das Wie konzentrieren? Die technische Architektur kommt später? Der Grund dafür ist, dass eine zu frühe Festlegung die Funktionalität einschränken könnte.
Ich würde gerne für Version 1. eine „Entdeckung der Entdeckungen“-Liste sehen, beginnend mit:
Eine „Neueste“-Liste, die eine Vorschau jedes neuesten Themas aus den enthaltenen Quellen anzeigt (eine einfache Vereinigung der Neuesten-Listen aller Quellen).
Eine „Beobachtete“-Liste, die eine Vorschau jedes Themas anzeigt, bei dem Sie Aktivitäten ausgewählt haben, zu denen Sie benachrichtigt werden möchten. (Dies leitet sich von der bestehenden mobilen App ab – sie erweitert die Benachrichtigungen über neue Aktivitäten bei beobachteten Themen auf die eigentlichen Vorschauen dieser Themen.)
Ich muss sagen, dass der ursprüngliche Vorschlag mit der Facebook-Analogie meine Vorstellungskraft übersteigt: Ich habe keine Ahnung, was Facebook macht, und verstehe nicht, wie das in irgendeiner Weise mit Discourse zusammenhängt.
Mein Verständnis von ActivityPub-Unterstützung für Discourse ist, dass es helfen kann, Themen zu federieren oder sogar eine Kategorie zwischen Discourse-Instanzen zu teilen. Beispielsweise könnte ein Ankündigungsthema auf discourse.joinmastodon.org in die verwandte Kategorie #software:mastodon auf socialhub.activitypub.rocks federiert werden: Dort könnten lokale Nutzer liken, antworten, zitieren usw., als wäre es ein lokales Thema, wobei das Originalthema jedoch auf der Instanz von joinmastodon verbleibt.
Ein weiterer Aspekt ist, dass, wenn jemand ein Konto auf beiden Instanzen hat, eine Möglichkeit bestehen sollte, diese Konten zu verknüpfen, d. h., eine bestimmte Discourse-Instanz als primären Identitätsanbieter zu nutzen. Ich verstehe, dass dies nicht im Fokus der ersten Iteration steht, aber es ist gut, es im Hinterkopf zu behalten, da wir am Ende eine „Anmeldung mit [füge hier deine bevorzugte ActivityPub-Implementierung ein]
Alle aktuellen ActivityPub-Implementierungen erwarten, dass Beiträge von stabilen Akteuren veröffentlicht werden. Daher benötigst du möglicherweise eine der folgenden Optionen:
Ein Systemkonto, das alle Beiträge veröffentlicht
Ein Konto pro folgbarem Feed
Ein Konto pro folgbarem Feed, das Announces von Beiträgen erstellt, die vermeintlich von einem Konto pro Discourse-Benutzer verfasst wurden
Die erste Option ist wahrscheinlich am einfachsten umzusetzen; die dritte bietet die beste Übereinstimmung der Datenmodelle.
Es gibt auch die Frage, ob wir den vollständigen Themeninhalt veröffentlichen wollen, nur die ersten Beiträge eines Themas oder etwas Ähnliches wie die StackExchange-Twitter-Feeds, bei denen separate Beiträge erstellt werden, um Beiträge von der Seite /top zu bewerben. Oder das könnte einfach so funktionieren, dass der Feed für „Top-Beiträge
Das glaube ich nicht: Remote-Benutzer könnten weiterhin gestaffelt werden, es sei denn, sie verknüpfen ihr Remote-Konto mit einem lokalen Konto. In diesem Fall würde der Antispam-Schutz auf dieses Konto angewendet werden.
Ich habe mir die Kommentare nur kurz angesehen, das muss ich gestehen. Ich schlage vor, dass jede Kategorie ein eigener Akteur (mit dem Typ „Group“) ist. Dann können sich Personen von außen einfach für bestimmte Kategorien anmelden. Beiträge in diesen Kategorien können dann dadurch realisiert werden, dass das „Group“-Konto die Benutzerbeiträge bekannt gibt. So haben wir sowohl die Kategorie als auch den Autor. Das machen wir auch mit unserer eigenen Software. Bei Verwendung von JSON-LD-Signaturen wäre dies auch für nicht-öffentliche Kategorien sicher.
Die Frage ist, was mit Kommentaren von außen zu tun ist. Ich schlage vor, dass die Gruppenkonten als „manuell genehmigen“ definiert werden. Dann könnte man einen Validierungsprozess hinzufügen, um willkürliches Spam zu vermeiden. Diese validierten Konten sollten dann in der Lage sein, auf diese Beiträge zu kommentieren.
Dies würde es Menschen aus (fast) dem gesamten Fediverse sofort ermöglichen, sich mit Discourse-Systemen zu verbinden und zu interagieren.
Jede Kategorie-Gruppen-Aktor einen Besitzer haben kann, der die Befugnis hat, die Kategorie zu verwalten: Veröffentlichungsberechtigungen steuern, Benutzer sperren oder entfernen, Sichtbarkeit festlegen (öffentlich oder privat) …
Lokale Benutzer Kategorien auf ihrer Instanz erstellen können, sofern das Instanz-Team die Erstellung ihrer Kategorien genehmigt.
Wenn ein Kategorienbesitzer seine Position nicht angemessen ausfüllt, das Site-Team ihn austauschen kann.
So funktionieren viele zentralisierte Foren und Communities. Was es zu verbessern gilt, ist die Föderierung.
Dennoch gibt es noch Probleme:
Sollten Actor-ids veränderbar sein? Discourse-Benutzernamen können in den Site-Einstellungen als änderbar festgelegt werden. Ich bezweifle jedoch, ob andere AP-Software dies handhaben kann. Is Object's `id` immutable? - ActivityPub - SocialHub
(Mehr wird noch erwähnt)
Kommt jemand vom Discourse-Team nächste Woche zum SocialHub auf der OFFDEM? Es wäre eine großartige Gelegenheit, sich mit anderen AP-Implementierern zu treffen und auszutauschen.
Auf der Feneas ActivityPub-Beobachtungsliste gibt es neben Mastodon drei weitere in Ruby implementierte Projekte, die als Referenz dienen könnten.
@heluecht und @misaka4e21 haben die Unterstützung des Group-Akteurs erwähnt. Im SocialHub gibt es eine laufende Diskussion über Möglichkeiten, dies mehr oder weniger standardisiert umzusetzen.
5 „Gefällt mir“
sl007
(Sebastian Lasse | @sl007@mastodon.social)
14
Herzlichen Glückwunsch zu den EU-Geldern!
Gibt es einen Fahrplan?
Kommt jemand vom Discourse-Team zur ActivityPub-Konferenz?
Das wäre eine großartige Gelegenheit, sich mit anderen AP-Implementierern zu treffen und abzustimmen. https://conf.activitypub.rocks
Hoffentlich werden wir nächste Sonntag während der Birds-of-a-Feather-Sitzung über die Implementierung von ActivityPub in Discourse im Rahmen der APConf2020 sprechen. Siehe das entsprechende Thema im SocialHub:
@rishabh, es wäre toll, wenn du dabei sein könntest – zumindest im Thema, falls du am Sonntag nicht persönlich kommen kannst. Wir wissen den genauen Zeitpunkt noch nicht, aber es findet am Sonntagmorgen statt. Ich aktualisiere diesen Beitrag, sobald ich mehr weiß.
Entschuldige, dass ich es nicht geschafft habe. Ich sollte dich informieren, dass wir keine Bewerbung für die NGI0-Förderung eingereicht haben und derzeit niemand an diesem Thema arbeitet. Ich bin auch nicht die beste Person, um dies voranzutreiben, da ich mit dem Protokoll nicht vertraut bin. Ich werde jedoch @Falco hier anpingen, um zu sehen, ob er dazu Gedanken hat oder Interesse daran, dies weiterzuführen.
Nun, zu der Zeit hat ein Mitglied Ihres Teams dies getan – auch wenn er nicht mehr dabei ist – und Sie wurden ausgewählt. Also musste jemand das genehmigen. Ich weiß also nicht, auf welches „wir
[quote=“hellekin, Beitrag: 18, Thema: 132624”]
Nun, damals hat eines deiner Teammitglieder das getan – auch wenn er nicht mehr dabei ist, und ihr ausgewählt wurdet – also musste jemand das genehmigen, also weiß ich nicht, auf welches „wir
1 „Gefällt mir“
sl007
(Sebastian Lasse | @sl007@mastodon.social)
20
Interessant.
Dieses Projekt wurde durch den NGI0 Discovery Fund finanziert, einen von NLnet mit finanzieller Unterstützung des Programms „Next Generation Internet
Oh, ich wusste nicht, dass diese Seite existiert. Ich werde eine E-Mail an unseren Ansprechpartner bei NLnet schreiben, ihn daran erinnern, falls er vergessen hat, sie zu entfernen, und hier ein Update veröffentlichen.
