ATmosphere

Was bedeutet "ATmosphere"?

ATmosphere bezeichnet das Ökosystem rund um das AT Protocol – also die Gesamtheit aus Anwendungen, Serverdiensten, Identitätsmechanismen, APIs, Datenströmen und Community-Projekten, die auf diesem Protokoll aufbauen. Der Begriff wird vor allem im Umfeld von Bluesky und anderen dezentralen Social-Web-Anwendungen verwendet. Technisch geht es dabei nicht um „Atmosphäre“ im allgemeinen Sinne, sondern um eine verteilte Infrastruktur für soziale Anwendungen, in der Identitäten, Inhalte und Dienste stärker voneinander getrennt werden als bei klassischen, zentral betriebenen Plattformen.

Das AT Protocol, ausgeschrieben Authenticated Transfer Protocol, ist ein offenes Framework für öffentliche Konversationen und soziale Anwendungen. Es definiert unter anderem, wie Benutzeridentitäten, Follows, Inhalte und Daten zwischen Diensten interoperabel – also systemübergreifend nutzbar – organisiert werden können. Die offizielle AT-Protocol-Dokumentation beschreibt das Protokoll als Standard für Social Apps mit föderierter Architektur und Account-Portabilität. (atproto.com)

Für Betreiberinnen und Betreiber von Websites, Domains und E-Mail-Infrastrukturen ist ATmosphere deshalb interessant, weil klassische Webhosting-Bausteine wie DNS, HTTPS/SSL, Webserver-Konfiguration, Dateiupload, SMTP und gegebenenfalls VPS- oder Serverbetrieb eine wichtige Rolle spielen. Wer eine eigene Domain besitzt, kann diese beispielsweise als verifizierbaren Handle im AT-Protocol-Umfeld nutzen. Wer tiefer einsteigen möchte, kann unter bestimmten Voraussetzungen sogar eigene Infrastruktur wie einen PDS betreiben.

ATmosphere, AT Protocol und Bluesky:
Die Begriffe sauber getrennt

AT Protocol

Das AT Protocol ist die technische Grundlage. Es beschreibt, wie Identitäten, Datenrepositories, API-Aufrufe, Synchronisation und Föderation funktionieren. „Föderation“ bedeutet hier: Mehrere voneinander unabhängige Server können zusammen ein Netzwerk bilden, ohne dass alle Daten und Konten zwingend auf einer einzigen zentralen Plattform liegen müssen.

Bluesky

Bluesky ist eine bekannte Social-Media-Anwendung, die auf dem AT Protocol basiert. Bluesky ist also nicht gleichzusetzen mit dem gesamten Protokoll. Vergleichbar wäre: Eine Website ist nicht „das Web“, sondern eine Anwendung innerhalb des Webs. Entsprechend ist Bluesky eine Anwendung innerhalb der ATmosphere.

ATmosphere

Die ATmosphere ist das größere Umfeld: Dazu gehören Bluesky, alternative Clients, Feed-Generatoren, AppViews, Personal Data Server, Relays, Moderationswerkzeuge, Entwicklerbibliotheken und weitere Anwendungen, die auf dem AT Protocol aufbauen. In der offiziellen Dokumentation wird die ATmosphere als verteilbarer Stack beschrieben, bei dem verschiedene Komponenten unterschiedlich gut für Self-Hosting geeignet sind. (atproto.com)

Die wichtigsten technischen Komponenten der ATmosphere

PDS: Personal Data Server

Ein PDS – Personal Data Server – ist ein zentraler Baustein im AT Protocol. Er hostet Benutzerkonten, verwaltet Identitätsbezüge, speichert Datenrepositories und übernimmt sicherheitsrelevante Aufgaben wie Account-Lifecycle, E-Mail-Verifikation, Passwort-Reset und teilweise Schlüsselverwaltung. Die AT-Protocol-Dokumentation beschreibt PDS-Instanzen als „Home in the Cloud“, also als Ort, an dem Benutzerdaten und Identitätsfunktionen zusammenlaufen. (atproto.com)

Für Webhosting-Nutzer ist wichtig: Ein PDS ist keine typische PHP-Anwendung, die Sie einfach per FTP in ein Webverzeichnis hochladen. Der offizielle Bluesky-PDS wird als Container-basierte Serveranwendung bereitgestellt und richtet sich an technisch versierte Betreiberinnen und Betreiber, die eine geeignete Serverumgebung kontrollieren. Das offizielle PDS-Repository nennt unter anderem eine öffentliche IPv4-Adresse, einen öffentlichen DNS-Namen sowie eingehenden Zugriff auf Port 80 und 443 als Anforderungen; empfohlen werden für kleine Setups beispielsweise 1 GB RAM, 1 CPU-Kern und 20 GB SSD-Speicher. (github.com)

Relay

Ein Relay sammelt Ereignisse aus PDS-Instanzen und stellt daraus einen Datenstrom bereit. Dieser sogenannte Firehose-Ansatz ist für größere Social-Web-Anwendungen wichtig, weil Inhalte, Likes, Reposts und andere Events in skalierbarer Form verteilt werden müssen. Relays sind technisch anspruchsvoller als einfache Webanwendungen, weil sie viel Netzwerkverkehr verarbeiten können müssen. Die AT-Protocol-Dokumentation weist ausdrücklich darauf hin, dass der Betrieb eines Relays möglich, aber bandbreitenintensiv ist. (atproto.com)

AppView

Eine AppView ist die Anwendungsschicht, die aus Rohdaten nutzbare Ansichten erzeugt. Sie berechnet beispielsweise Feeds, Suchergebnisse, Zähler für Likes oder Reposts und andere anwendungsspezifische Darstellungen. Während ein PDS Daten beherbergt, macht die AppView diese Daten für eine konkrete Anwendung komfortabel sichtbar.

Handle und DID

Ein Handle ist die menschenlesbare Kennung eines Accounts, beispielsweise name.example.de. Ein DID – Decentralized Identifier – ist dagegen die technisch persistente Identität. Handles können geändert werden; DIDs sollen langfristiger und stabiler sein. Laut AT-Protocol-Spezifikation müssen Handle und DID bidirektional verknüpft sein: Der Handle muss auf die DID verweisen, und das DID-Dokument muss den Handle bestätigen. (atproto.com)

Warum Domains in der ATmosphere so wichtig sind

Die eigene Domain als verifizierbarer Handle

Für Domaininhaber ist einer der interessantesten Anwendungsfälle die Nutzung der eigenen Domain als Handle. Statt eines generischen Handles wie name.bsky.social kann ein Account unter einer eigenen Domain oder Subdomain auftreten, zum Beispiel:

• unternehmen.de
• redaktion.unternehmen.de
• max.mustermann.example.de

Das hat mehrere Vorteile:

• Wiedererkennbarkeit: Die Domain ist bereits Teil Ihrer digitalen Identität.
• Vertrauenssignal: Ein Handle unter einer offiziellen Domain wirkt glaubwürdiger als ein frei registrierbarer Plattformname.
• Portabilität: Die Identität ist stärker an Ihre Domain gekoppelt als an eine einzelne Plattform.
• Markenschutz: Organisationen können kontrollieren, welche Handles unter ihrer Domain verwendet werden.

Technisch erfolgt die Verifikation über DNS oder über eine HTTPS-Datei. Die AT-Protocol-Spezifikation unterstützt zwei Verfahren: einen DNS-TXT-Record oder eine Datei unter einem /.well-known/-Pfad. (atproto.com)

DNS-TXT-Methode

Bei der DNS-TXT-Methode wird ein TXT-Record für _atproto unterhalb des gewünschten Handles gesetzt. Für user.example.com wäre also ein TXT-Record unter _atproto.user.example.com relevant. Der Wert beginnt mit did= und enthält die zugehörige DID. Die AT-Protocol-Spezifikation beschreibt diese Methode als empfohlene und bevorzugte Variante für individuelle Handle-Konfigurationen. (atproto.com)

Für Domaininhaber bedeutet das: Sie benötigen Zugriff auf die DNS-Verwaltung Ihrer Domain. A-, AAAA-, MX-, SPF-, DKIM- oder DMARC-Einträge werden dadurch nicht ersetzt. Der _atproto-TXT-Record ergänzt die bestehende DNS-Zone lediglich um einen weiteren Nachweis.

HTTPS-Well-Known-Methode

Alternativ kann ein Webserver unter der gewünschten Domain eine Textdatei bereitstellen:

/.well-known/atproto-did

Diese Datei enthält die DID als reinen Text. Für produktive Handle-Auflösungen ist laut Spezifikation sicheres HTTPS auf Port 443 erforderlich; unverschlüsseltes HTTP ist nur für lokale Entwicklung und Tests vorgesehen. (atproto.com)

Für Shared-Hosting-Nutzer ist dieses Verfahren besonders interessant, weil es häufig genügt, eine kleine Textdatei in das Webverzeichnis hochzuladen. Genau hier kommen klassische Hosting-Werkzeuge wie FTPS, SFTP oder gegebenenfalls SSH ins Spiel.

Bedeutung für Shared Hosting

Was mit Shared Hosting gut funktioniert

Shared Hosting eignet sich sehr gut für klassische Webaufgaben rund um die ATmosphere:

• Bereitstellung einer Website zur Domain
• Upload einer /.well-known/atproto-did-Datei
• Pflege von Landingpages für Social-Profile
• Nutzung der eigenen Domain als digitale Identität
• Betrieb von CMS-Systemen wie WordPress, wenn begleitende Inhalte veröffentlicht werden sollen
• Einrichtung von E-Mail-Adressen unter derselben Domain

Bei goneo können Dateien per verschlüsselter Verbindung auf den Webspace übertragen werden. Unverschlüsselte FTP-Verbindungen werden nicht mehr unterstützt; stattdessen stehen FTPS und SFTP zur Verfügung. SFTP wird dabei über Port 2222 angeboten, FTPS explizit über Port 21 und FTPS implizit über Port 990. (goneo.de)

Das ist für die HTTPS-Well-Known-Methode praktisch: Sie erstellen lokal eine Datei mit der DID, laden diese sicher auf den Webspace und stellen sicher, dass sie unter dem geforderten Pfad erreichbar ist.

Was Shared Hosting nicht leisten soll

Ein vollständiger PDS-Betrieb ist etwas anderes als das Bereitstellen einer statischen Datei. Dafür werden typischerweise Root- oder Administrationsrechte, Containerbetrieb, dauerhaft laufende Prozesse, ein Reverse Proxy, TLS-Automatisierung, WebSocket-Unterstützung, Firewall-Kontrolle und Backup-Prozesse benötigt. Das offizielle PDS-Installationsskript geht von einem eher frischen VPS aus und weist darauf hin, dass es nicht für Szenarien gedacht ist, in denen auf demselben Server bereits parallel ein anderer Webserver auf Port 80/443 betrieben wird. (github.com)

Daraus folgt: Shared Hosting ist hervorragend geeignet, um eine Domain als Handle zu verifizieren und begleitende Webinhalte bereitzustellen. Für den Betrieb eines eigenen PDS sollten Sie dagegen eine Serverumgebung wählen, die dauerhaft laufende Dienste, Container und vollständige Netzwerkkontrolle erlaubt.

FTP, FTPS, SFTP, SCP und SSH im ATmosphere-Kontext

FTP und FTPS

FTP steht für File Transfer Protocol und dient der Dateiübertragung zwischen lokalem Rechner und Webspace. Da klassisches FTP Zugangsdaten und Daten unverschlüsselt übertragen kann, ist es aus heutiger Sicht nicht mehr empfehlenswert. FTPS erweitert FTP um TLS-/SSL-Verschlüsselung. Dadurch wird der Transport abgesichert.

Im ATmosphere-Kontext ist FTPS relevant, wenn Sie Dateien für die Well-Known-Verifikation hochladen möchten. Das betrifft insbesondere die Datei atproto-did.

SFTP

SFTP steht für SSH File Transfer Protocol. Trotz des ähnlichen Namens ist SFTP technisch nicht einfach „FTP mit Verschlüsselung“, sondern ein Dateiübertragungsprotokoll über SSH. Für viele professionelle Workflows ist SFTP die bevorzugte Methode, weil sie sicher, gut automatisierbar und in gängigen Clients wie FileZilla, Cyberduck oder WinSCP verfügbar ist.

SCP

SCP steht für Secure Copy Protocol und kopiert Dateien über SSH. In Serverumgebungen mit Shell-Zugriff ist SCP ein einfaches Werkzeug, um Dateien per Kommandozeile zu übertragen. In klassischen Webhosting-Paketen ist SCP jedoch nicht immer als eigenständiger Workflow vorgesehen. Entscheidend ist, welche Zugriffsmethoden Ihr Hosting-Paket tatsächlich bereitstellt.

SSH

SSH – Secure Shell – ermöglicht den Kommandozeilenzugriff auf einen Server oder Webspace. Bei goneo steht SSH in Webhosting-Paketen ab Webhosting Profi zur Verfügung und richtet sich an fortgeschrittene Nutzerinnen und Nutzer, die Kommandozeilenbefehle sicher beherrschen. (goneo.de)

Für ATmosphere-Aufgaben im Shared Hosting ist SSH komfortabel, aber nicht zwingend erforderlich. Für einen PDS-Betrieb auf einem VPS ist SSH dagegen praktisch unverzichtbar, weil Installation, Updates, Logs, Backups und Konfigurationsänderungen typischerweise über die Kommandozeile erfolgen.

SSL, TLS und HTTPS: Ohne Verschlüsselung geht es nicht

Im Webhosting-Alltag wird häufig noch von SSL gesprochen, technisch ist heute meist TLS gemeint. TLS ist das moderne Verschlüsselungsprotokoll hinter HTTPS. Es schützt die Verbindung zwischen Browser, Client oder API und Server.

Für die ATmosphere ist HTTPS in mehreren Bereichen zentral:

• Handle-Verifikation per /.well-known/atproto-did
• API-Kommunikation
• Login- und OAuth-Flows
• PDS-Zugriff
• WebSocket-Verbindungen über wss://
• Schutz von Passwörtern und Sessiondaten

Die Handle-Spezifikation verlangt für reale HTTPS-basierte Handle-Auflösung sicheres HTTPS auf Port 443. (atproto.com) Auch beim offiziellen PDS-Setup spielen Port 80 für TLS-Zertifikatsprüfung und Port 443 für Anwendungsanfragen eine zentrale Rolle. (github.com)

Bei goneo werden benötigte SSL-Zertifikate für Websites kostenfrei von Let’s Encrypt bezogen; eigene SSL-Zertifikate werden in den Webhosting-Paketen nicht unterstützt. (goneo.de) Für typische Website- und Handle-Verifikationszwecke ist das eine einfache und praxistaugliche Lösung.

E-Mail-Perspektive: SMTP, Identität und Benachrichtigungen

E-Mail bleibt auch in der ATmosphere wichtig. Ein PDS benötigt E-Mail-Funktionen beispielsweise für Verifikation, Passwort-Reset und administrative Kommunikation. Das offizielle PDS-Repository beschreibt die Einrichtung eines SMTP-Servers oder eines externen E-Mail-Dienstes für den Versand solcher Nachrichten. (github.com)

Für E-Mail-Poweruser ergeben sich mehrere praktische Punkte:

• Der AT-Protocol-Handle ist nicht automatisch eine E-Mail-Adresse.
• Eine Domain kann gleichzeitig für Website, E-Mail und AT-Protocol-Handle genutzt werden.
• MX-Einträge für E-Mail und _atproto-TXT-Einträge für Handle-Verifikation erfüllen unterschiedliche Aufgaben.
• SPF, DKIM und DMARC sollten für professionellen Mailversand sauber konfiguriert bleiben.
• Benachrichtigungsmails aus Webanwendungen sollten nicht mit Massenmailing verwechselt werden.

Bei goneo können E-Mail-Konten mit gängigen Programmen und mobilen Geräten über Standardprotokolle wie IMAP, POP3 und SMTP genutzt werden. Außerdem sind SIEVE-Skripte zur detaillierten Mailfilterung möglich, was insbesondere für Poweruser und strukturierte Postfach-Workflows interessant ist. (goneo.de)

Sicherheit und Betriebsverantwortung

Identität schützen

Wer eine eigene Domain als Handle nutzt, sollte diese Domain langfristig kontrollieren. Läuft die Domain aus, wird falsch delegiert oder werden DNS-Einträge versehentlich entfernt, kann die Verifikation beeinträchtigt werden. Die AT-Protocol-Spezifikation sieht vor, dass Handles bei fehlender bidirektionaler Bestätigung als ungültig markiert werden können. (atproto.com)

DNS sorgfältig verwalten

DNS ist in diesem Zusammenhang nicht nur technische Infrastruktur, sondern Identitätsgrundlage. Änderungen an TXT-Records sollten dokumentiert werden. Besonders bei Organisationen empfiehlt sich ein Vier-Augen-Prinzip für DNS-Änderungen.

PDS absichern

Wer einen eigenen PDS betreibt, übernimmt Verantwortung für:

• Systemupdates
• Firewall-Regeln
• TLS-Zertifikate
• Backups
• Wiederherstellung
• SMTP-Konfiguration
• Account-Sicherheit
• Schlüsselmaterial
• Monitoring
• Missbrauchs- und Moderationsprozesse

Die Produktionshinweise der AT-Protocol-Dokumentation behandeln unter anderem Hardening, Backups, PLC-Key-Management, Objekt-Storage, Rate Limits und Moderation. (atproto.com) Das zeigt: Ein eigener PDS ist ein ernstzunehmender Serverdienst, kein Nebenbei-Upload in ein Webverzeichnis.

Praxisbeispiel: Eigene Domain als AT-Protocol-Handle nutzen

Ein typischer Ablauf für Domaininhaber sieht so aus:

• Sie wählen eine Domain oder Subdomain als Handle.
• Sie prüfen, ob die gewünschte Schreibweise den Handle-Regeln entspricht.
• Sie erzeugen in der jeweiligen AT-Protocol-Anwendung den Verifikationswert.
• Sie setzen entweder einen _atproto-TXT-Record im DNS oder legen eine /.well-known/atproto-did-Datei per SFTP/FTPS auf Ihrem Webspace ab.
• Sie aktivieren HTTPS für die Domain.
• Sie lassen die Anwendung die Domain verifizieren.
• Sie dokumentieren den Eintrag, damit er nicht versehentlich gelöscht wird.

Für viele semiprofessionelle Webseitenbetreiber ist dies der attraktivste Einstieg in die ATmosphere: Sie nutzen die eigene Domain als Identitätsanker, ohne sofort eigene dezentrale Social-Web-Infrastruktur betreiben zu müssen.

Zusammenfassung

Die ATmosphere ist das Ökosystem rund um das AT Protocol und umfasst Anwendungen, Serverdienste, Identitäten, Datenströme und Entwicklerwerkzeuge für das dezentrale Social Web.

Für Shared-Hosting-Nutzer ist vor allem die Nutzung einer eigenen Domain als Handle relevant, entweder über einen DNS-TXT-Record oder über eine HTTPS-Datei im /.well-known/-Verzeichnis.

Ein vollständiger PDS ist deutlich anspruchsvoller als eine normale Website und benötigt typischerweise eine kontrollierbare Serverumgebung mit dauerhaft laufenden Diensten, TLS, offenen Ports, Backups und Administrationszugriff.

Für Domaininhaber und E-Mail-Poweruser ist wichtig: DNS, HTTPS und SMTP bleiben zentrale Bausteine digitaler Identität – auch im Social-Web-Kontext.

Fragen, die dieser Text beantwortet

• Was bedeutet ATmosphere im Zusammenhang mit Webhosting und dem AT Protocol?
• Wie unterscheiden sich ATmosphere, AT Protocol und Bluesky voneinander?
• Welche Rolle spielen PDS, Relay, AppView, Handle und DID?
• Wie kann eine eigene Domain als AT-Protocol-Handle verwendet werden?
• Welche Bedeutung haben DNS-TXT-Records und /.well-known/atproto-did?
• Was können Shared-Hosting-Nutzer im ATmosphere-Kontext praktisch umsetzen?
• Warum ist ein eigener PDS kein typischer Shared-Hosting-Anwendungsfall?
• Welche Rolle spielen FTPS, SFTP, SCP, SSH, SSL/TLS und HTTPS?
• Was sollten E-Mail-Poweruser bei SMTP, Domainidentität und DNS beachten?
• Welche Sicherheits- und Betriebsaspekte sind bei ATmosphere-Projekten wichtig?