#instanz

🏞️ Das Pendant zu #Instagram im #Fediverse ist doch #Pixelfed...

Welche #Instanz könnt ihr für einen #Verein empfehlen?

#Alternative

Eine #Jitsi-#Instanz finden.

Der freie #Videochat #Jitsi erfreut sich einer grossen Beliebtheit. Wie ihr Instanzen für euren Call findet, erfahrt ihr in diesem Artikel. ...

https://gnulinux.ch/eine-jitsi-instanz-finden

Das Fediverse und Deine E-Mail-Adresse

Um ins #Fediverse einzutauchen und Teil der #Föderation zu werden, wirst Du vermutlich über Deine E-Mail-Adresse ein Konto auf einer fediversalen #Instanz erstellen.

Dieses Konto beinhaltet eine weltweit gültige Fediverse-Adresse, die völlig unabhängig von Deiner bei Deiner Instanz genutzten E-Mail-Adresse ist.

Nur mit dieser Fediverse-Adresse werden Beiträge und Interaktionen von Dir zwischen den Instanzen föderiert. Deine für das Fediverse-Konto genutzte E-Mail-Adresse ist nur Deiner kontoführenden Instanz bekannt.

Sofern Deine Instanz eine #Software nutzt, die Beiträge und Medien von anderen Instanzen im Fediverse zwischenspeichert (und damit die Rolle des Auslieferers übernimmt), verbleibt auch die Kenntnis der von Dir genutzten IP-Adresse für den aktuellen Zugriff auf Deine kontoführende Instanz beschränkt.

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!

Mit Version 4.0 führte die fediversale Serversoftware #Mastodon eine Übersetzungsoption ein, um den Text von Beiträgen von einer Sprache in eine andere zu übersetzen.

Hierzu muß die #Instanz einen Übersetzungsdienst konfiguriert und aktiviert haben. Dies kann etwa ein kommerzieller Dienst wie #DeepL sein. Daher ist zu berücksichtigen, daß die Übersetzung durch einen Dritten vorgenommen wird, der dadurch Kenntnis von entsprechenden Texten/Beiträgen erhält.

Diese Übersetzungsfunktion kann auch via #API angesprochen werden. Dies bedeutet, je nach App und Version kann diese Option im Angebot von Apps (wie z.B. #Fedilab oder #Pachli) sein oder (noch) nicht.

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!

instances.social

Das englischsprachige Projekt instances.social will bei der Auswahl einer #Mastodon-#Instanz helfen.

Zu diesem Zweck stellt die Website einige Fragen, um im Anschluß unter Berücksichtigung der Antworten geeignete Instanzen vorzuschlagen.

Es wird nach der Sprache gefragt, nach der Anzahl registrierter Nutzender und ob Nacktheit oder Werbung ein wichtiger Punkt sind.

Dann wird eine Liste von Instanzen ausgegeben, in der man auch suchen kann.

Es existieren weitere Funktionen, etwa Listenanzeigen, ein erweiterter Modus und eine #API.

https://instances.social/

Das Projekt wird betrieben von @TheKinrar@mastodon.xyz

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...

Grundlagen der #Föderation

A folgt B

Das #Fediverse heißt nicht ohne Grund "föderiertes Universum". In dieser Föderation spielen viele tausend Instanzen zusammen. Aber heißt das, jede #Instanz muß den gesamten Datenbestand des gesamten Fediversums lokal vorhalten oder ständig über das Netz funken? Nein.

Eine Basisfunktion, damit Instanzen wissen, wer sich für welche Beiträge interessiert, ist das Folgen.

Wenn Akteur A auf Instanz A eine Folgeanfrage an Akteurin B auf Instanz B absetzt, weiß Instanz B im Anschluß, das sich jemand für die passenden (z.B. öffentlichen) Beiträge von Akteurin B auf Instanz A interessiert und wird diese ab diesem Zeitpunkt an Instanz A zustellen. Instanz A kann diese Beiträge von Akteurin B auf Instanz B dann auch in der föderierten Zeitleiste allen Nutzenden auf Instanz A anzeigen.

Damit die Instanzen sich untereinander über ihre lokalen Konten informieren können, dient das an anderer Stelle beschriebene #Webfinger-#Protokoll.

Im #Fediverse spielt das #Protokoll #WebFinger gemäß #RFC 7033 eine wichtige Rolle, um Nutzende ausfindig zu machen.

Diese Webfinger-Abfragen finden im normalen Umgang mit dem Fediverse aus Sicht der Nutzerschaft hinter den Kulissen statt. Von einer fediversalen #Instanz wird erwartet, daß sie über eine sogenannte "Well-known #URI" (dazu an anderer Stelle mehr) auf eine Webfinger-Anfrage reagiert.

Dieser (gut bekannte) Identifikator lautet:

/.well-known/webfinger?resource=acct:

(wobei die Domain der Instanz sowie die abzufragende Kennung zu ergänzen ist)

Netterweise kann man diese Abfrage auch über die Weboberfläche von webfinger.net durchführen lassen.

Wer neugierig ist und dies (z.B. mit der eigenen Fediverse-Adresse) ausprobieren will:

➡️ https://webfinger.net/ im Browser aufrufen.

➡️ Oben rechts im Suchkästchen "Lookup WebFinger" die gewünschte Adresse eingeben, z.B. tagestipp@mastodonium.de (ohne das führende At-Zeichen) oder die #URL-Schreibweise https://mastodonium.de/@tagestipp und das Ergebnis bewundern.

➡️ Es sollte ein "#JSON Resource Descriptor (JRD)" zu sehen sein. Okay, möglicherweise ist das immer noch ziemlich technisch... ;-)

Zum Nachlesen und schmökern:
https://en.wikipedia.org/wiki/WebFinger
https://datatracker.ietf.org/doc/html/rfc7033
https://webfinger.net/
https://en.wikipedia.org/wiki/Well-known_URI
https://de.wikipedia.org/wiki/Uniform_Resource_Identifier

(Medien: 1)