Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.

Was ist Mastodon?

Mastodon, 2016 von dem deutschen Softwareentwickler, Eugen Rochko, aus Berlin, gegründet. Im Gegensatz zu den beliebten kommerziellen Social-Media-Plattformen, ist Mastodon Open Source. Folglich dient die Anwendung im Idealfall dem Ziel, der Öffentlichkeit einen Mehrwert zu schaffen und nicht primär irgendwelchen Aktionären.

Den Begriff Open Source habe ich bereits mehrfach in meinen Beiträgen erwähnt und werde es in einem der nachfolgenden Beiträge genauer erklären. Laut seiner Aussagen in seinem Blog arbeitete Eugen Rochko 5 Jahre lang als Einzelunternehmer an dem Projekt, mit dem er unter anderem auch seinen Lebensunterhalt bestritt, bevor er sich als Angestellter des gegründeten Unternehmens ein Gehalt ausgezahlt hat. 8 Jahre sollen die juristischen Angelegenheiten für die ordnungsgemäße Gründung gefressen haben.

(Hatte ich schon erwähnt, wie toll Deutschland als Gründungsland und Tech-Standort funktioniert? 😉)

Laut seiner Aussagen, konnten mehr Ressourcen für Dinge wie die Einstellung zusätzlicher Entwickler, UX-Designer, die Entwicklung offizieller Apps usw. aufgebracht werden. Im Juni 2021 konnte dann die Mastodon gGmbH (gemeinnützige Gesellschaft mit beschränkter Haftung) offiziell eingetragen werden. Eine kurze Erklärung, was eine gGmbH ist, erfolgt gleich im Anschluss.

Was ist eine gGmbH?

Eine gemeinnützige Gesellschaft mit beschränkter Haftung ist im Grunde genommen ähnlich strukturiert wie eine gewinnorientierte Gesellschaft mit beschränkter Haftung.

Mit ein paar wichtigen Unterschieden:

• Die Gründungsurkunde der Gesellschaft ist so verfasst, dass die Tätigkeit der Gesellschaft auf Ziele ausgerichtet ist, die der Allgemeinheit zugute kommen
• Die Gesellschafter dürfen keine Einkünfte aus der Tätigkeit der Gesellschaft erhalten und können höchstens die Gelder abheben, die sie ursprünglich eingezahlt haben
• Die Mitarbeiter dürfen keine außerordentlich hohen Löhne erhalten und die Gesellschaft kann Spenden erhalten, die dann steuerfrei sind, obwohl alle anderen Einkünfte, die nicht der Definition einer Spende entsprechen, weiterhin mit verschiedenen Steuern belegt werden
• Um eine solche juristische Person zu gründen, muss die Gründungsurkunde einer Prüfung durch das Finanzamt standhalten und die Gründer müssen ein Startkapital von 25.000 EUR einzahlen, wie es bei einer GmbH üblich ist.

Weiter mit „Was Mastodon eigentlich ist…“

Mastodon mag auf den ersten Blick wie ein Twitter-Klon aussehen aber das System hinter der Microblogging-Plattform ist etwas komplexer. Der Dienst ist dezentralisiert. Nicht im Sinne einer Blockchain. Die werde ich auch noch genauer unter die Lupe nehmen und in einem Beitrag thematisieren. Sie beschreibt sich selbst als „Federation“. Mit Föderation, in diesem Kontext, ist eine Form der Dezentralisierung gemeint, die anstelle eines zentralisierten Dienstes, den alle Menschen nutzen, mehrere Dienste, die von einer beliebigen Anzahl von Menschen zur Verfügung gestellt und genutzt werden kann.

Eine Mastodon-Webseite kann selbstständig funktionieren. Genau wie bei einer herkömmlichen Webseite, melden sich die Benutzer*Innen an, posten Nachrichten, laden Bilder hoch und sprechen miteinander. Im Gegensatz zu einer herkömmlichen Webseite können jedoch Mastodon-Webseiten mit den Nutzern interagieren und auch ihre Nutzer können untereinander kommunizieren. So als ob man eine E-Mail von einem Gmail-Konto an jemanden schickt, der bei beispielsweise bei Fastmail, ProtonMail oder einem anderen E-Mail-Anbieter registriert ist. Solange man die Adresse des Empfängers kennt, kann man jeden auf einer beliebigen Seite mit seiner Adresse erwähnen oder benachrichtigen.

Wie läuft die Sache mit der Registrierung/Anmeldung?

Wenn man ein Konto zum ersten Mal erstellt, wählt man einen Server aus (Ähnlich wie bei der Eröffnung eines E-Mail-Kontos bei einem Provider), der die Adresse des Profils generiert. Wenn man sich zum Beispiel über den „ioc.exchange“ bei Mastodon anmeldet, lautet die Adresse @[Benutzername]@ioc.exchange. Unabhängig davon, bei welchem Server man sich anmeldet, kann man mit Benutzern von anderen Servern kommunizieren, so wie Gmail-Nutzer beispielsweise Protonmail-Nutzer anschreiben und umgekehrt. Allerdings kann es sein, dass einige Server andere Server blockieren, da sie nicht so ganz miteinander klarkommen (Gründe hierfür sind beispielsweise Interessenkonflikte). Folglich kann mit niemandem eines blockierten Servers kommunizieren werden.

Das Mastodon Jargon bzw. die Fachsprache

Mastodon-Benutzer bezeichnen die einzelnen Gemeinschaften im Allgemeinen als „Instanzen“ oder Server. Diese Mastodon-Server können von Einzelpersonen, Gruppen oder Organisationen erstellt und betrieben werden, die jeweils ihre eigenen Regeln für die Anmeldung von Benutzern sowie ihre eigenen Moderationsrichtlinien haben. Bei einigen Servern kann jeder mitmachen, während andere nur auf Einladung oder mit Genehmigung eines Administrators betrieben werden. Ein Server für professionelle Wissenschaftler verlangt beispielsweise, dass die Bewerber einen Link zu ihrer Forschung angeben, um zu zeigen, dass sie tatsächlich in einem professionellen akademischen Kontext bzw. Umfeld arbeiten.

Die Wahl des Servers, auf dem man das eigene Konto registrieren möchte, mag aufwändig erscheinen – Aber es ist möglich, das Konto später wieder zu verschieben. Aus diesem Grund ist die Auswahl des Servers nicht fundamental bzw. unumkehrbar. Außerdem kann man nach wie vor anderen Personen folgen, unabhängig davon, auf welchem Server man sich befindet.

Mastodon verwendet ein standardisiertes, offenes Protokoll zur Umsetzung des Verbunds. Es wird als ActivityPub bezeichnet. Jede Software, die von und durch die Federation über ActivityPub implementiert wird, kann nahtlos mit Mastodon kommunizieren, genau wie Mastodon-Webseiten miteinander kommunizieren.

Das Fediverse („federated universe“) ist die Bezeichnung für alle Webseiten, die über ActivityPub und das www (World Wide Web) miteinander kommunizieren können. Dazu gehören alle Mastodon-Server und auch andere Implementierungen wie:

• Pleroma – Ein modulares Microblogging-System
• Pixelfed – Eine föderierte Plattform für die gemeinsame Nutzung von Bildern, mit der man Medienbeiträge teilen und konsumieren kann
• Misskey – Das neben Microblogging auch ein anpassbares Dashboard enthält
• PeerTube – Mit dem man Videos in Kanäle hochladen kann
• Plume – Mit dem man längere Artikel veröffentlichen kann
• Und viele mehr, da es sich um individuelle und persönliche Webseiten handelt

Mastodons Äquivalent von Tweets werden als „Toots“ bezeichnet. Doch dieser Begriff scheint nicht mehr so beliebt zu sein und wird von den Nutzern eher als „Posts“ bezeichnet. Dennoch wird der Begriff „Toot“ immer noch auf älteren Clients von Drittanbietern verwendet.

Es unterstützt eine Reihe von Twitter-Konventionen wie Antworten, Retweets, Favoriten, Lesezeichen und Hashtags. Aber Retweets werden als „Boosts“ bezeichnet und es unterstützt nicht das Konzept der Zitat-Tweets. Dies war eine bewusste Entscheidung des Gründers. Seiner Meinung nach ermutigt es das Individuum mit der Audienz zu interagieren, statt mit einer spezifischen Person.

Auch die Mastodon-Listen scheinen etwas anders zu funktionieren als bei Twitter, da man nur Personen zu einer Liste hinzufügen kann, denen man bereits folgt. Und Direktnachrichten auf Mastodon sind nur Beiträge mit dem @Benutzernamen, keine privaten Nachrichten, die in einem DM-Posteingang landen.

Was klassifiziert Mastodon als Open Source?

Jeder kann Mastodon herunterladen, verändern und auf seinem eigenen Server installieren – Das Urheberrecht liegt nicht bei den Entwicklern der Plattform.

Dies bedeutet jedoch nicht, dass man den Code von Mastodon ohne Quellenangabe einfach so übernehmen kann, wie die Social-Media-Plattform des ehemaligen Präsidenten Donald Trump, „Truth“ im Jahr 2021, die Runde machte. Freie Software steht in der Regel unter der Lizenz AGPL. Diese erlaubt es, den Code zu benutzen und zu verändern, wenn man sich dabei an die Lizenzvereinbarungen hält. Die AGPL-Lizenz schreibt vor, dass die Software auch nach ihrer Veränderung öffentlich zugänglich bleibt. Das soll verhindern, dass kommerzielle Anbieter*Innen sich den Code aneignen, ohne der Allgemeinheit etwas zurückzugeben.

Gibt es im Vergleich zu Twitter irgendwelche Nachteile?

Soweit ich es beurteilen kann, ist die Nutzerbasis von Mastodon im Vergleich zu Twitter immer noch sehr klein. Es ist vergleichsweise auch weitaus weniger intuitiv zu bedienen, da es nicht für ein großes globales Publikum wie Twitter ausgelegt ist. Dies kann sich aber mit der Zeit ändern. Vor allem dann, wenn sich dem Projekt mehr Entwickler anschließen.

Und da die Ausstattung, damit sind die Hardware-Ressourcen gemeint, von Mastodon noch nicht so gut ist wie die von Twitter, funktioniert es scheinbar hin und wieder nicht so gut. In den letzten Tagen war der Dienst zeitweise träge, wenn nicht sogar völlig zum Stillstand gekommen, da sich die Server an den massiven Zustrom neuer Nutzer erst anpassen mussten. Dies kann sich auch auf andere Bereiche der Nutzung auswirken. Vor allem wenn man versucht, auf die Schnelle eine Reihe von Freunden auf dem Dienst zu folgen, und feststellt, dass man zwischendurch warten muss, weil Restriktionen auftreten.

Was sind die Vorteile von Mastodon im Vergleich zu Twitter?

Allem voran, es ist Open Source und vor allem dezentral. Ob es dem Twitter-Hype gleichkommt, kann ich mir persönlich nicht vorstellen. Einige Nutzer können Mastodon jedoch Twitter vorziehen, da es von Natur aus individueller anpassbar ist. Im Gegensatz zu Twitter haben die einzelnen Communities unterschiedliche Inhaltsrichtlinien, die eine Vielzahl von unterschiedlichen Nutzererfahrungen ermöglichen, die man so bei Twitter nicht hat. Und obwohl die Nutzerbasis auf Mastodon kleiner ist, kann dies manchmal zu persönlicheren und direkteren Gesprächen führen, als wenn man sozusagen ins Leere tweetet.

Wie steht es mit der Sicherheit?

Mastodon ist das, was man daraus macht. Aufgrund des dezentralen Charakters von Mastodon, kann man den eigenen Wünschen entsprechend, ein kontrolliertes Online-Erlebnis, mit strengeren Schutzmaßnahmen gegen Belästigungen erschaffen, wenn man einen Server erstellt. Einige Mastodon Funktionen existieren explizit für die Eindämmung von Belästigungen. Man kann zum Beispiel nur nach Hashtags suchen. Nicht aber nach Wörtern, die in einem Beitrag vorkommen. Wenn man also möchte, dass ein Beitrag auffindbar ist, kann man es taggen. Wenn das Publikum eingeschränkt werden soll, kann niemand den Tweet über beispielsweise „Teureres Parfüm“ finden, indem nach „Teureres Parfüm“ gesucht wird, wenn es nicht getagged wurde.

Eine textbasierte Suche kann jedoch Beiträge anzeigen, die man selbst geschrieben, favorisiert oder geboosted hat. Auch sind die Beiträge auffindbar, in denen jemand die eigene Person erwähnt oder getagged hat..

Der Dienst verfügt über eine weitere praktische Funktion, die es Nutzern ermöglicht, direkt im Erstellungsfeld eine Inhaltswarnung zu einem Beitrag hinzuzufügen. Einige Mastodon-Nutzer haben sich in letzter Zeit einen Spaß daraus gemacht und andere gewarnt, dass ihr Beitrag ein Twitter-Drama zum Inhalt hat.

Können Bilder/Medien gepostet werden?

Wie bereits erwähnt, unterstützt Mastodon viele Twitter-Konventionen. Die Unterstützung für Medien ist jedoch relativ begrenzt. Twitter untertützt eine Vielzahl von Medien und anderen Daten, die man an Tweets angehängten kann. Einschließlich der eignen sozialen „Spaces“, die Audio, Fotos, Videos, GIFs, Umfragen, genaue Ortsangaben und experimentelle „Status“-Tags enthalten. Mastodon unterstützt lediglich Bilder, Videos, Audio und Umfragen.

Man kann einem Beitrag bis zu vier Bilder mit einer Größe von bis maximal 8 Megabyte hinzufügen. Videos und Audiodateien können beliebig lang sein, die Dateigröße ist jedoch auf 40 Megabyte begrenzt.

Kann man privat Freunden schreiben/posten?

Ähnlich wie bei Twitter soll es den Nutzern möglich sein, die Sichtbarkeit der Tweets durch die „Circle-Funktion“ einzuschränken. So bietet Mastodon die Möglichkeit, die Privatsphäre eines Beitrags zum Zeitpunkt der Erstellung festzulegen. Beiträge können so eingestellt werden, dass sie für alle sichtbar sind. Auch so, dass sie nicht gelistet werden. Man kann sie von den „discovery features“ ausschließen. Nur für die eignen Follower sichtbar machen oder nur für die ausschließlich erwähnten Nutzer sichtbar machen.

Kann man wie bei „Twitter-Blue“ verifiziert werden?

Es gibt kein universelles Verifizierungssystem wie bei Twitter. Einige Server überprüfen die Benutzeranmeldungen und man kann sich in gewisser Weise selbst verifizieren. Dies macht man, indem man Links zu dem eigenen Mastodon-Profil hinzufügt. Diese müssen ein bestimmtes Attribut (rel=“me“) haben, um zu beweisen, dass man die Person ist, die man vorgibt zu sein.

Einige Server machen sich zurzeit mit der Verifizierung auf eine weniger offizielle Art und Weise einen Spaß. Auf dem Server mstdn.social kann man beispielsweise dem Anzeigenamen blau-weiße Häkchen und andere Emoji hinzufügen, die einen verifiziert aussehen lassen, obwohl diese Emojis keinerlei Bedeutung haben – So ähnlich wie das neue Verifizierungssystem von Twitter, nur kostenlos! 😉

Ist Mastodon hier, um zu bleiben?

Mastodon erfährt einen massiven Zustrom neuer Nutzer von Twitter. So viel ist jedenfalls klar. Ob sich dieses Wachstum fortsetzen kann, wird sich zeigen. Mit nur 1,8 Millionen Nutzern am Tag ist Mastodon weitaus kleiner als Twitter, welches Stand heute über 206 Millionen täglich aktive Nutzer zählt, die darüber hinaus auch noch monetisiert werden können. Dennoch sind nicht alle sozialen Netzwerke gleich und vielleicht zieht man es auch vor, auf einem eigenen Server über Spiele zu plaudern, anstatt in ein Reich des Wahnsinns zu twittern. Oder aber man ist fasziniert von dezentralisierten Systemen und macht allein schon aus diesem Grund mit.

Kann man von Twitter zu Mastodon cross-posten?

Ja, dies scheint mithilfe von Tools von Drittanbietern möglich zu sein. So kann man mit den gängigen Autorisierungen, Twitter-Posts direkt zu Mastodon weiterleiten. Hierzu gibt es bereits einige Repositories auf GitHub, die man dafür nutzen kann. Auf GitHub und Repositories gehe ich in einem späteren Beitrag ein.

Fazit

Alles in allem finde ich Open Source Anwendungen grundsätzlich gut. Ob sich Mastodon durchsetzen wird, lässt sich in diesem Augenblick wohl eher schlecht als recht sagen. Auch sollte man nicht vergessen, dass sich im Jahr 2019 das rechtsradikale Netzwerk „Gab“ mit ungefähr einer Millionen Nutzer*Innen auf Mastodon niederließ und damit eines der größten Knotenpunkte darstellte. Aus diversen Foren habe ich erfahren, dass Administratoren vieler Instanzen Gab blockiert haben (Hierfür ist ein einfacher Eintrag in den Einstellungen der jeweiligen Instanz nötig).

Folglich wurden Nachrichten „Toots“ von Gab nicht mehr weitergeleitet, man konnte die Nachrichten auch nicht mehr in der öffentlichen Timeline sehen und man konnte Gab Nutzer nicht suchen bzw. finden. Die Entwickler*Innen von Mastodon selbst distanzierten sich umgehend von Gab. Ich bin jetzt auf jeden Fall mal dabei und werde mich die Tage, falls ich etwas Zeit finde, mehr damit beschäftigen. So gesehen, war ich bereits ende 2018 mal online, doch irgendwie wurde der Server scheinbar gelöscht. Heute findet man mich auf Mastodon über @coezbay@ioc.exchange – Erst einmal nicht so aktiv und eher aus Forschungszwecken dabei 😉

Der Beitrag Mastodon – Open Source Twitter Alternative erschien zuerst auf CEOsBay.