#friendica

Details, Details, Details...

#GoToSocial liefert mir in der #HTTP-#Signatur eine "algorithm"-Angabe "hs2019"... das mag ich mit #Mammuthus aktuell nicht, möchte da gern ein "rsa-sha256"...

Also mal schauen...

Interessanterweise hatte man bei #Friendica wohl vor einiger Zeit genau das gleiche Thema am Wickel... ;-)

#ActivityPub #Fediverse

#Fediverse-Client #Relatica

Relatica ist ein Fediverse-Client für die Fediverse-Plattform #Friendica. Laut Angaben im Applikationsrepository werden mehrere Betriebssysteme unterstützt: #Android, #iOS, #Windows, #macOS, #Linux.

Website des Projekts (Code-Repository):
https://gitlab.com/mysocialportal/relatica

(Medien: 1)

ActivityPub und Mastodon-Umfragen

#ActivityPub ist ein gern genutztes #Kommunikationsprotokoll im #Fediverse, mit dem sich Instanzen untereinander unterhalten und austauschen. Die fediversale Plattform #Mastodon unterstützt Umfragen.

So weit, so gut. Nur, die Art und Weise, wie Mastodon Umfragen umsetzt, paßt nicht 100%ig zu der in ActivityPub bzw. im #Activity #Vocabulary definierten Form.

Demnach wäre eine #Frage (engl. #Question) nämlich eigentlich eine Aktivität und kein Objekt. Mastodon behandelt eine Frage allerdings als Objekt. Dies kann zu Verständigungsproblemen zwischen verschiedenen Instanztypen im Fediverse führen.

Mastodon-Instanzen untereinander verstehen sich. Auch #Mammuthus versteht sich auf Umfragen im Mastodon-Stil. Bei weiteren Fediverse-Plattformen (wie etwa #Friendica, #Pixelfed, #Firefish, etc.) wäre dies im Einzelfall zu klären.

Zum weiteren Einstieg ins Thema (für technisch Interessierte):
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-question
https://docs.joinmastodon.org/spec/activitypub/#Question

Dem geneigten Lesenden mag aufgefallen sein, daß das #W3C das "Activity Vocabulary" auf Mai 2017 datiert, "ActivityPub" allerdings auf Januar 2018. Und letzteres keinen expliziten Bezug zu einer "Question" nimmt.

#Activity#Vocabulary #Poll #Umfrage #Umfragen

(Medien: 2)

Das Fediverse im Stadt-Modell erläutert

Im #Fediverse ist die Rede von Instanzen, die zusammen kommunizieren und gemeinsam das föderierte Universum bilden. Da kommen technische Begriffe ins Spiel wie Server, Software, Protokoll usw. usf. - und Produkte wie #Mastodon, #Friendica, #Pixelfed und viele mehr sowie Protokolle wie #ActivityPub... und viele Details mehr.

Wie kann man sich das vorstellen, wenn wir mal davon ausgehen würden, daß Instanzen Städte auf einem Planeten sind?

Nehmen wir also mal an, eine #Instanz bzw. ein #Server bzw. ein #Knotenpunkt im #Fediversum wäre eine Stadt auf einem Planeten. Inklusive Bevölkerung. Diese Stadt kann auf einem Eigenbau basieren oder sie nutzt einen Bauplan für eine spezielle Art von Stadt. Dieser Bauplan wäre dann eine Serversoftware wie Mastodon oder #Firefish oder eine andere.

Leute können sich in einer bereits gebauten Stadt ansiedeln oder eine eigene Stadt aufbauen. Da viele Baupläne für speziell ausgerichtete Städte frei verfügbar existieren (Open Source!), kann diese neue Gemeinschaft auf Basis eines solchen Bauplans eine neue Stadt errichten. Oder etwas eigenes bauen, weil... und hier kommen wir zum nächsten Punkt.

Die Städte auf diesem Planeten sind durch Wege verbunden. Diese Wege sind genormt, damit die Städte sich untereinander austauschen können und die jeweiligen Stadtverwaltungen wissen, wie sie mit Informationen und Botschaften, die über diese Wege übermittelt werden, umgehen und nicht wie ein Ochs' vorm Berg dastehen. Viele Wege nutzen die Norm "ActivityPub". Dies erlaubt dann auch komplett neue Typen von Städten, sofern diese über standardisierte Wege an vorhandene Städe angeschlossen werden.

Soweit so klar?

Instanzen entsprechen Städten, die #User der Instanzen der jeweiligen Stadtbevölkerung, die #Administration einer Instanz entspricht der Stadtverwaltung einer Stadt, unterschiedliche Arten von #Serversoftware bzw. Baupläne regeln die Art des Stadtaufbaus und Protokolle entsprechen genormten Wegen zwischen Städten.

Was passiert nun, wenn ein Bewohner in Stadt A einer Bewohnerin in Stadt B folgen will? Im Hintergrund wird die Stadtverwaltung von Stadt A tätig und schickt über den Weg (zwischen den Städten) eine Botschaft zu Stadt B. Dort nimmt die Stadtverwaltung von Stadt B den Folgewunsch entgegen und bearbeitet ihn. Akzeptiert die Bewohnerin von Stadt B Folgeanfragen ohne manuelle Überprüfung ihrerseits, kann ihre Stadtverwaltung gleich im Hintergrund eine Bestätigungsbotschaft über den Weg zu Stadt A zurückschicken. Die Stadtverwaltungen der Städte A und B kennen nun die Folgebeziehung zwischen den beiden Bewohnenden und können gewissermaßen einen Vermerk im Stadtarchiv vornehmen. Wenn nun die Bewohnerin in Stadt B einen neuen Beitrag verfaßt, weiß ihre Stadtverwaltung, daß sie eine Botschaft mit diesem Beitrag über die Wegeverbindung zu Stadt A schicken muß, weil dort ein Bewohner Interesse angemeldet hat bzw. folgt. Die Stadtverwaltung von Stadt A weiß auch Bescheid und kann den Beitrag aus Stadt B für ihren Bewohner präsentieren.

Immer noch klar?

Macht dieses Städtegleichnis den Aufbau des föderierten Universums nun verständlicher, ändert es nichts oder wird es noch komplizierter? ;-)

Achso, die Fediverse-Adresse entspricht gewissermaßen dem Namen und der Anschrift der jeweiligen Bewohnenden der Städte. Die Adresse beinhaltet den Namen und die Stadt. Innerhalb einer Stadt reicht der Name aus, aber bei Botschaften zwischen Städten muß Namen und Stadt genannt werden. Und ja, das ist einer Telefonnummer mit Vorwahl nicht unähnlich.

Völlig verwirrt? Oder bestens ins Bild gesetzt?

Viel Spaß im Fediverse!

#Fediverse-#Statistik-Sammler fediverse.party

Innerhalb eines föderierten Systems - ja, genau, in diesem Fall ist natürlich vom föderierten #Universum, dem #Fediverse, die Rede - ist es naturgemäß schwierig, einen vollständigen Überblick über Größe, Nutzerstatistiken und technische Details zu erhalten.

Mehrere Projekte sind im #Fediversum unterwegs und sammeln Daten von den einzelnen Instanzen.

Dazu zählt auch die "fediverse.party".

https://fediverse.party/

Das Projekt stellt verschiedene fediversale Serversoftware vor (#Misskey, #Hubzilla, #PeerTube, #Pixelfed, #Friendica, #Lemmy, #Mastodon, #Pleroma, #diaspora, #Funkwhale) und faßt hier gesammelte Statistiken zusammen.

Ein fediversaler Gesamtüberlick aus "fediverse.party"-Sicht findet sich hier:

https://fediverse.party/en/fediverse/

Das Code-Repository findet sich hier:

https://codeberg.org/fediverse/fediparty

Die Entwickler sind @lightone@mastodon.xyz, @minoru@functional.cafe, @smallcircles@social.coop (vormals mastodon.social/@humanetech) und @strypey@mastodon.nzoss.nz

Wohlgemerkt, es handelt sich um eine Sicht auf Basis der zur Verfügung stehenden Daten des Statistiksammlers. Andere erhobene Statistiken mögen davon abweichen.

#fediverseparty

(Medien: 1)

#Fediverse-#Statistik-Sammler Fediverse Observer

Innerhalb eines föderierten Systems - ja, genau, in diesem Fall ist natürlich vom föderierten #Universum, dem #Fediverse, die Rede - ist es naturgemäß schwierig, einen vollständigen Überblick über Größe, Nutzerstatistiken und technische Details zu erhalten.

Mehrere Projekte sind im #Fediversum unterwegs und sammeln Daten von den einzelnen Instanzen.

Dazu zählt auch der "Fediverse Observer".

https://fediverse.observer/

Eine Liste von Instanzen ist hier zu finden:

https://fediverse.observer/list

Mit Stand März 2024 werden 21.478 Einträge angegeben.

Die eingesetzte #Software #Poduptime ist hier zu finden

https://gitlab.com/diasporg/poduptime

und beschreibt sich selbst als "Poduptime is #PHP software to observe stats and data on servers that support nodeinfo over the fediverse from projects like #Mastodon, #Diaspora, #Friendica, #Pixelfed..."

Wohlgemerkt, es handelt sich um eine Sicht auf Basis der zur Verfügung stehenden Daten des Statistiksammlers. Andere erhobene Statistiken mögen davon abweichen.

#FediverseObserver

(Medien: 1)

Als föderiertes System besitzt das #Fediverse weder zentrale Steuerung noch einheitliche Regeln. Diese liegen in der Hand der einzelnen Knotenpunkte, der Server oder für Eingeweihte, der Instanzen.

Wenn Du selbst eine Instanz nur für Dich betreibst, bist Du natürlich auch Chef über alles... und kannst frei entscheiden. Wenn Du für weitere Mitmenschen Konten anbietest, entscheidest Du vielleicht im Team.

Auch wenn Du selbst nur Interesse an der Nutzung eines Kontos hast, schaue auf die Nutzungsbedingungen und Regeln der Instanz, bevor Du Dich registrierst, ob Du Dich mit dem gewünschten Verhalten auf dieser Instanz anfreunden kannst.

Wenn eine Instanz #Mastodon als Serversoftware einsetzt, finden sich die Serverregeln gern unter der /about-URL.

Im Beispiel für die norddeutsche Instanz norden.social:
https://norden.social/about

Unter dem Punkt "Serverregeln" sind genau diese zu finden. Bei norden.social zum Beispiel unter Punkt 1: "Sei kein Arschloch." - nordisch direkt.

Übrigens gibt es häufig auch den Punkt "Moderierte Server", wo man ggf. einsehen kann, mit welchen Instanzen diese Instanz eingeschränkt oder gar nicht föderiert - optional auch mit Begründung.

Je nach genutzter Serversoftware können sich Nutzungsbedingungen unter anderen URLs tummeln. Bei #Friendica möglicherweise unter der /tos-URL.

Im Beispiel für die Friendica-Instanz anonsys.net:
https://anonsys.net/tos

Im Fediverse ist Vielfalt angesagt: Also einfach schauen, ob es Regeln, Nutzungsbedingungen, AGB oder wie auch immer gibt... und ob diese mit der eigenen Persönlichkeit harmonieren.

Drum prüfe, wer sich (ewig) bindet... oder so ähnlich.

Das föderierte #Universum ist ein #Mitmachversum!

Das #Fediverse ist das, was Du daraus machst.

Hier kann man Eigeninitiative zeigen, sogar selbst eine #Instanz betreiben. Viel freie #Software zur Auswahl: #Mastodon, #Friendica, #Pixelfed, #PeerTube, #BookWyrm und viele mehr.

Und wer mag, technisch versiert ist, arbeitet sich in die zugrundeliegende Technik ein und entwickelt etwas selbst. Sei es via #ActivityPub oder über eine #Client-#API.

Wie schon ein schwedisches Möbelhaus wußte: Entdecke die Möglichkeiten!

Mastodon-Client-API

Auch wenn sich im #Fediverse viel um #ActivityPub dreht und hier durchaus auch eine #Client-Schnittstelle skizziert ist, nutzt #Mastodon eine eigene Client-API, die (zumindest teilweise) auch von anderer fediversaler Serversoftware unterstützt wird (z.B. #Friendica, #Firefish, #Mammuthus).

Diese #API (application programming interface, eine #Schnittstelle zur #Programmierung von Anwendungen) dient Apps und Clients dazu, entsprechende Funktionen auf einer #Instanz durchzuführen. Diese API ermöglicht die Entwicklung von Apps wie #Tusky, #Fedilab & Co.

Man kann diese API auch nutzen, um Konten etwa (teil)automatisiert zu betreiben.

Oder Statistiken zu sammeln... oder... oder... ;-)

Die API ist soweit öffentlich dokumentiert und steht frei zur Verfügung.

Allgemeine Dokumentation zu #Mastodon (auf Englisch):
https://docs.joinmastodon.org/

"Getting started with the API":
https://docs.joinmastodon.org/client/intro/

Wer mit dem Gedanken spielt, die API zu nutzen, sollte sich mit #HTTP, #JSON & Co. anfreunden können. Und Englischkenntnisse sind in diesem Bereich grundsätzlich von Vorteil...

#Fediverse-Client/App #Fedilab

Die #App Fedilab für #Android zählt als multifunktionaler #Client unter den fediversalen Apps und bietet die Unterstützung mehrerer Fediverse-Plattformen. Genannt werden #Mastodon, #PeerTube, #Pixelfed, #Pleroma, #Friendica sowie #GNU #Social.

Fedilab ist ein Open-Source-Projekt und auch über das F-Droid-Repository erhältlich.

Fedilab weist sehr viele Funktionen auf, unterstützt etwa auch vorgeplante Beiträge und bietet die Unterstützung für mehrere Konten. Auch die Pflege des eigenen Profils ist direkt über Fedilab möglich. Auch die Einbindung von öffentlichen Zeitleisten anderer Instanzen als Tab ist mit Fedilab möglich.

Website des Projekts:
https://fedilab.app/

Fedilab im Fediverse:
@apps@toot.fedilab.app
@Fedilab@piaille.fr

(Medien: 1)