Was ist eine API?

Eine API (Application Programming Interface) ist eine Sammlung von Protokollen, Routinen und Tools zur Interaktion zwischen verschiedenen Softwareanwendungen. Vereinfacht ausgedrückt, ermöglicht eine API die Kommunikation zwischen zwei Softwareanwendungen, indem sie dem Entwickler die Möglichkeit bietet, bestimmte Funktionen oder Daten einer Anwendung zu verwenden, ohne sich um deren interne Implementierung kümmern zu müssen.

Funktionsweise von APIs

APIs ermöglichen die Kommunikation zwischen Anwendungen, indem sie standardisierte Anfragen und Antworten verwenden. In der Regel bezeichnet man eine Anwendung, die eine API bereitstellt, als Server. Die Anwendung, die die API nutzt, bezeichnet man als Client. Der Client sendet eine Anfrage an den Server, der diese Anfrage bearbeitet und daraufhin eine Antwort zurücksendet.

Die Kommunikation erfolgt meist über das https-Protokoll und basiert auf einem Request-Response-Modell. Eine API-Anfrage enthält normalerweise Informationen wie die gewünschte Aktion, die zu verwendenden Daten und den Authentifizierungsschlüssel. Die Antwort beinhaltet dann das Ergebnis der Aktion, zusammen mit den angeforderten Daten, falls vorhanden.

Arten von APIs

Es gibt verschiedene Arten von APIs, je nach Zugriffsbeschränkungen und Anwendungsbereich. Hier sind einige der gebräuchlichsten Typen:

Öffentliche APIs: Auch als externe oder offene APIs bekannt, sind APIs, die für die Öffentlichkeit zugänglich sind. Entwickler können sie nutzen, um angebotene Dienste in ihre Anwendungen zu integrieren.

Private APIs: Diese APIs sind nur für einen bestimmten Entwicklerkreis oder innerhalb eines Unternehmens zugänglich. Entwickler verwenden sie, um interne Prozesse und Dienstleistungen zu unterstützen.

Partner-APIs: Partner-APIs sind für eine ausgewählte Gruppe von Entwicklern oder Unternehmen zugänglich, die eine Partnerschaft oder Geschäftsvereinbarung mit dem API-Anbieter eingegangen sind.

API-Protokolle und Datenformate

APIs nutzen verschiedene Protokolle und Datenformate, um Anfragen und Antworten zu strukturieren. Die gebräuchlichsten sind:

REST (Representational State Transfer): Ein Architekturstil, der auf der Verwendung von standardisierten https-Anfragen und Antworten basiert. REST-APIs sind ressourcenorientiert und relativ leicht verständlich. Man verwendet sie häufig mit JSON (JavaScript Object Notation) als Datenformat.

SOAP (Simple Object Access Protocol): Ein älteres Protokoll, das auf XML-basierten Nachrichten beruht und strenge Regeln für die Kommunikation vorschreibt. SOAP-APIs sind tendenziell komplexer als REST APIs, bieten jedoch eine höhere Sicherheit und formelle Spezifikationen.

GraphQL: Eine relativ neue API-Technologie, von Facebook. Im Gegensatz zu REST und SOAP ermöglicht GraphQL eine flexiblere Datenabfrage, indem der Client genau die benötigten Informationen anfordern kann. GraphQL verwendet eine eigene Abfragesprache und unterstützt sowohl Lese- als auch Schreiboperationen.

gRPC: Ein von Google entwickeltes API-Framework, das auf Protocol Buffers, als binäres Datenformat setzt und für hohe Leistungsfähigkeit und Skalierbarkeit optimiert ist. gRPC eignet sich besonders für Mikroservices und hochperformante Anwendungen. Ich gehe davon aus, dass ich darüber in naher Zukunft einen separaten Beitrag schreibe.

API-Authentifizierung und -Sicherheit

Um den Zugriff auf APIs zu kontrollieren und deren Sicherheit zu gewährleisten, kann man verschiedene Authentifizierungs- und Autorisierungsmechanismen einsetzen. 

Einige der gängigen Methoden sind:

API-Schlüssel: Ein einfacher und weit verbreiteter Ansatz, bei dem der Entwickler einen eindeutigen Schlüssel erhält, den man bei jeder API-Anfrage übermittelt, um den Zugriff zu autorisieren.

OAuth: Ein offener Standard für Authentifizierung und Autorisierung, der es ermöglicht, Anwendungen den Zugriff auf Benutzerdaten von Drittanbietern zu gewähren, ohne dass die Anwendung das Passwort des Benutzers kennen muss. Sozialen Netzwerke und große Webdienste wie Google und Facebook nutzen häufig OAuth.

JWT (JSON Web Tokens): Eine kompakte, selbstständige Methode zur sicheren Übertragung von Informationen zwischen Parteien in Form von Objekten. Man nutzt JWTs häufig in Kombination mit OAuth und anderen Authentifizierungsschemata.

Best Practices bei der Verwendung von APIs

Die erfolgreiche Nutzung von APIs erfordert einige Best Practices, um sicherzustellen, dass Anwendungen effizient und sicher arbeiten:

Dokumentation: Eine gut dokumentierte API erleichtert Entwicklern das Verständnis und die Integration der API in ihre Anwendungen.

Fehlerbehandlung: Eine robuste Fehlerbehandlung ist entscheidend, um sicherzustellen, dass Anwendungen auch bei unerwarteten Fehlern oder Ausfällen der API korrekt funktionieren.

Ressourcenmanagement: Bei der Verwendung von APIs ist es wichtig, auf Ressourcenmanagement zu achten. Dies erreichet man beispielsweise, indem man Ratenbegrenzungen (Rate Limiting) einhält, um die Anzahl der Anfragen pro Zeiteinheit zu begrenzen und die Belastung des API-Servers zu reduzieren.

Sicherheit: Bei der Arbeit mit APIs sollte man auf die Sicherheit der Anwendung und der API achten. Durch die Verwendung von Verschlüsselungstechniken und sicheren Authentifizierungsmethoden lässt sich dies relativ einfach realisieren.

Zukünftige Trends bei APIs:

APIs gewinnen weiterhin an Bedeutung, da sich die Technologielandschaft weiterentwickelt. Um neue Anforderungen und Herausforderungen zu bewältigen, müssen sich auch die APIs weiterentwickeln.

Einige zukünftige Trends bei APIs sind:

Hypermedia-APIs: Ein aufkommender Trend im Bereich der REST APIs ist die Verwendung von Hypermedia-Elementen zur Dynamisierung der API-Kommunikation. Hypermedia-APIs stellen Links und Aktionen in den API-Antworten bereit, um den Client zur Verfügung stehende Funktionen und Ressourcen dynamisch zu erkennen. Dadurch kann man die Kopplung zwischen Client und Server reduzieren.

API-Orchestrierung: Mit der zunehmenden Verbreitung von Mikroservices und verteilten Systemen gewinnen die API-Orchestrierung und -Aggregationen immer mehr an Bedeutung, um eine effiziente Kommunikation und Integration zwischen verschiedenen Diensten zu gewährleisten.

Edge-Computing und APIs: Mit der zunehmenden Verbreitung von IoT-Geräten und Edge-Computing-Technologien ist die Rolle von APIs bei der Bereitstellung von Echtzeitdaten und Funktionen für Geräte am Netzwerkrand essenziell.

KI-gestützte APIs: Integration von künstlicher Intelligenz und maschinellem Lernen, um leistungsfähige Funktionen wie Spracherkennung, Computer Vision bzw. Bildanalyse und datengesteuerte Vorhersagen bereitzustellen.

API-Sicherheit und Datenschutz: Angesichts der wachsenden Besorgnis über Datensicherheit und Datenschutz nimmt man APIs zunehmend unter die Lupe, um sicherzustellen, dass sie den geltenden Datenschutzbestimmungen entsprechen und angemessene Sicherheitsmaßnahmen implementieren.

Fazit

APIs sind ein grundlegendes Element moderner Softwareentwicklung und ermöglichen eine effiziente und skalierbare Kommunikation zwischen verschiedenen Anwendungen und Diensten. Durch das Verständnis der verschiedenen API-Typen, Protokolle, Datenformate und Best Practices können Entwickler ihre Anwendungen effektiv erweitern und mit externen Diensten integrieren. Indem man auf API-Dokumentation, Fehlerbehandlung, Ressourcenmanagement und Sicherheit achtet, kann man sicherstellen, dass die API-Integration erfolgreich ist und zur Verbesserung der Gesamtanwendung beiträgt.

Der Beitrag API – Nahtlose Verbindungen für Innovationen erschien zuerst auf CEOsBay.

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.

Was ist Discord?

Mit Discord haben Benutzer die Möglichkeit, mit Sprachanrufen, Videoanrufen, Textnachrichten, Medien und Dateien in privaten Chats oder als Teil von Gemeinschaften, die „Server“ genannt werden, zu kommunizieren. Ein Server ist eine Sammlung von dauerhaften Chaträumen und Sprachkanälen, auf die über Einladungslinks zugegriffen werden kann. Die Anwendung läuft auf Windows, macOS, Android, iOS, iPadOS, Linux und in Webbrowsern. Es ist möglich, durch den Einsatz von Bots, wesentliche Funktionen auf diesen Servern zu administrieren und zu automatisieren.

Ein bisschen Background Information

Als Discord im Jahr 2015 auf den Markt kam, musste es sich gegen drei etablierte Apps behaupten: Skype, Slack und TeamSpeak. Alle drei taten, was sie sollten, doch waren sie nicht besonders gut darin. Dies ist wohl auch eines der Gründe, warum die Anwendung von Anfang an so viel Traffic und Zulauf erhielt. Der Andrang führte unweigerlich zu mehreren Serverabstürzen, da das Unternehmen sich schwertat, mit dem enormen Nutzerzahlen gleich zu Beginn klarzukommen.

Jason Citron, der Gründer von Discord, hatte gerade eine 100-Millionen-Dollar-Übernahme seiner vorherigen Social-Gaming-Technologie OpenFeint abgeschlossen. Er wusste, dass seine Anwendung durch einen modernen Ansatz für die Online-Kommunikation das Angebot von Skype und TeamSpeak bei weitem übertreffen konnte.

Anstatt auf Reddit oder in Foren zu suchen, konnten die Nutzer, die primär Gamer bzw. Spieler waren, einem Server beitreten, der speziell für ein bestimmtes Spiel gedacht war. Als die Server immer beliebter wurden, bekamen die Administratoren die Möglichkeit, Unterkanäle für bestimmte Themen oder Spielmodi hinzuzufügen.

Es gibt mittlerweile ca. 7 Millionen aktive Server auf Discord. Und mittlerweile kann man durchaus man sagen, dass eine nicht zu unterschätzende Zahl nicht mehr viel mit Spielen zu tun haben. Unter ihnen findet sich auch mein Unternehmens Server oder auch ein paar Server, in denen ich in Bezug auf NFTs und Krypto Teilhaber bin. Obwohl Discord nach wie vor für Gamer gedacht ist, hat das Team versucht, die Reichweite zu vergrößern, um mit Slack und Microsoft Teams zu konkurrieren. Und dies machen sie wirklich gut.

Die Möglichkeit, unmoderierte private Server zu erstellen, hat in der Vergangenheit auch für Kontroversen gesorgt. Im Jahr 2017 wurde ein Server von amerikanischen Nationalisten genutzt, um die Kundgebung in Charlottesville, Virginia, zu organisieren. Discord sperrte die Mitglieder der White-Supremacist-Gruppe und viele andere Neonazi- und Alternativ-rechte-Server und hat seitdem Verifizierungs- und Bot-Moderationstools eingeführt, um diese Art von Gruppen schneller aus dem Verkehr zu ziehen.

Wie bereits erwähnt, bot Discord zu Beginn nur Text- und Audiokommunikation. Im Jahr 2017 wurden Videoanrufe und Bildschirmfreigaben hinzugefügt. Später wurden auch Integrationen mit Twitch, Spotify und Xbox Live hinzugefügt.

Der Aufstieg von Discord kam mit dem Wachstum des E-Sports zusammen. Mit Spielen wie League of Legends, Overwatch und Fortnite, die allesamt über eher begrenzte Kommunikationstools verfügten. Als immer mehr Twitch-Streamer zu Discord wechselten, wurde dies zu einem Selbstläufer bzw. geradezu zu einer kostengünstigen Marketingkampagne für das Unternehmen.

Trotz des schnellen Wachstums, dass sich von 10 Millionen monatlich aktiven Nutzern (MAUs) im Jahr 2016 auf 45 Millionen im Jahr 2018 beschleunigte, kämpfte Discord damit, ein Einnahmemodell zu finden, dass die Erträge des Unternehmens sichern sollte. In den ersten Jahren verkaufte Discord digitale Aufkleber und Merchandise-Artikel. Aber diese Maßnahme brachte dem Unternehmen 2017 lediglich 10 Millionen US-Dollar ein.

Im Jahr 2018 wurde ein Spiele-Shop eingeführt, der eine ausgewählte Auswahl an Spielen bot. Außerdem wurde ein Abonnementdienst, Discord Nitro, eingeführt, der mehr Emojis, eine größere Uploadgröße, Serverunterstützung und Zugang zu den Videospielen im Schaufenster „Im Endeffekt Bildschirm-Sharing“ bot.

Während Discord Nitro noch immer im Einsatz ist, hat das Unternehmen die Funktion mit dem Spiele-Shop im Jahr 2019, mit der Begründung des mangelnden Interesses der Abonnenten entfernt. Seitdem hat es die Storefront auf Eis gelegt, die Discord oder den Spieleentwicklern von Drittanbietern offenbar nicht viel Geld einbrachte.

Trotz des Scheiterns der Storefront befindet sich Discord weiterhin in einer gesunden Position. Die Nutzung ist während der COVID-19-Ausgangssperre, die ja weitestgehend global realisiert wurde, sprunghaft angestiegen. Kürzlich wurden über 100 Millionen MAUs und ein neuer Höchststand von 10,6 Millionen gleichzeitig aktiven Nutzern bekannt gegeben.

Ob es in der Lage sein wird, Nutzer und Unternehmen von Slack und Microsoft Teams zu gewinnen, bleibt abzuwarten. Im März änderte es sein Motto von „Chat for Gamers“ in „Chat for Communities and Friends“ und gestaltete seine Website neu, um weniger Gamer-spezifische Inhalte zu zeigen. Kommt scheinbar im professionellen Umfeld nicht so gut an 😉

Ist Discord Open Source?

Discord ist nicht quelloffen und somit auch nicht Open Source. Obwohl es sich um einen geschlossenen Quellcode handelt, kommuniziert Discord selbst, dass sie als Unternehmen an die Open-Source-Entwicklungsprinzipien der Zusammenarbeit und der gemeinsamen Nutzung von Lösungen glauben. Es ist proprietär lizenziert, und der Source Code ist nicht frei zugänglich bzw. kann nicht modifiziert werden.

Warum ist Discord nicht Open Source?

Es ist anzunehmen, dass Discord keine Open-Source-Software ist, weil die Entwickler der App primär Geld verdienen möchten. Es erlaubt ihnen auch, die Software „begehrenswert“ zu halten. So zumindest die Aussage eines Mitarbeiters.

Da der Quellcode von Discord geschlossen ist, kann die Öffentlichkeit den Code der Discord-App nicht einsehen. Dies wirft viele Fragen darüber auf, was sich hinter dem Quellcode der Software verbirgt. Discord hat sich nicht zu den Spekulationen geäußert, warum es eine Closed-Source-Plattform ist. Die Geheimhaltung des Quellcodes kann Vorteile haben, muss es aber meiner Meinung nach nicht. Mich persönlich interessiert es, welche Daten erhoben werden.

Discord Bezahlmodell? 

Discord ist in der Standardversion kostenlos und bietet ein monatliches Abonnement mit dem Namen Discord Nitro an. Das Abonnement bietet Vorteile wie Streaming mit höherer Auflösung, das Hinzufügen von Änderungen an dem eigenen Server sowie größere Datenuploads.

Gibt es Alternativen zu Discord?

Klar gibt es Alternativen. Diese sind Mumble, Element, Tox.Chat, Jitsi, TeamSpeak und Skype.

Wobei ich persönlich, zusammen mit Discord, nur TeamSpeak, Mumble und Jitsi aktiv benutze. Evtl. werde ich auch Beiträge zu den alternativen Lösungen erstellen.

Fazit

Alles in allem finde ich persönlich Discord ok. Die Tatsache, dass der Quellcode nicht offen und somit Open Source ist, gefällt mir nicht. Auch gefällt es mir nicht, dass ich für den Einsatz von Bots extra Geld ausgeben muss, obwohl der Bot von mir persönlich entwickelt wurde und auch von mir selbst gehostet wird. Ich habe keine Ahnung, welche Daten der Kommunikation von Discord selbst erhoben werden. Wahrscheinlich sammeln sie alles.

Es gibt keinen Grund, paranoid zu sein, dennoch sollte man mit dieser Annahme gewissenhaft umgehen. Denn solange man nicht wirklich weiß, was unter der Haube läuft, kann man sich eben nicht sicher sein. Und die jüngsten Ereignisse in dem Kontext der sozialen Medien haben gezeigt, dass viel Unfug damit anstellen. Besonders fällt mir dies persönlich im Blockchain-, Krypto– und NFT-Space auf. Viele Projekte, in die ich investiert oder an denen ich beteiligt war, wurden meistens über Discord gehacked, da die Sicherheitsmaßnahmen nicht ausgefeilt genug waren.

Sicherlich gehört da auch die Gewissenhafte Verwaltung und Administration des eigenen Servers auch dazu, doch ich möchte Discord selbst mindestens genauso zur Verantwortung ziehen, da es ihre Anwendung ist, über den der Missbrauch stattfindet. Nichtsdestotrotz hat sich auch das NFT-Space mittlerweile regelrecht in Discord etabliert. Es ist abzuwarten, was Elon Musk mit Twitter anstellt. Vielleicht ergibt sich schon bald eine Alternative, die Discord zumindest im NFT-Space ablöst.

Dennoch muss ich sagen, dass ich ohne Discord wohl nicht auf grandiose Menschen gestoßen wäre, mit denen ich viel Zeit verbringe, um richtig gute Anwendungen und Lösungen zu entwickeln. Auch der Wissensgehalt, den ich mir lediglich durch die Nutzung der Plattform angeeignet habe, ist immens. Man findet halt relativ schnell Gleichgesinnte, mit einem gewissen Etwas 😉

Der Beitrag Discord – Community durch nahtlose Kommunikation und Zusammenarbeit erschien zuerst auf CEOsBay.