ATproto

ATproto, ausgeschrieben Authenticated Transfer Protocol, ist ein offenes Netzwerkprotokoll für Social-Web-Anwendungen. Bekannt geworden ist es vor allem durch Bluesky, doch technisch ist ATproto nicht auf eine einzelne App beschränkt. Das Protokoll beschreibt, wie Identitäten, öffentliche Daten, Datenrepositorien, Serverrollen, APIs und Anwendungsschemata zusammenwirken, damit soziale Anwendungen dezentraler, portabler und interoperabler betrieben werden können. Für Domaininhaber, Shared-Hosting-Nutzer, Webprofessionals und E-Mail-Poweruser ist ATproto besonders interessant, weil es DNS, HTTPS, Identitätsnachweise und Hosting-Konzepte direkt miteinander verbindet. (atproto.com)

Was bedeutet ATproto?

ATproto ist ein Protokoll für offene Social-Web-Anwendungen. „Authenticated“ verweist darauf, dass Daten und Identitäten kryptografisch überprüfbar sein sollen. „Transfer“ beschreibt den Austausch von Daten zwischen verschiedenen Komponenten im Netzwerk. Anders als bei klassischen zentralisierten Plattformen soll nicht eine einzige Website oder App allein bestimmen, wo Identität, Inhalte, Moderation und Darstellung liegen. Stattdessen trennt ATproto mehrere Ebenen voneinander: Identität, Datenspeicherung, Datenaggregation, Anwendungssicht und Client-Oberfläche. (atproto.com)

Für Websitebetreiber ist diese Trennung ein wichtiger Punkt: Eine Domain kann nicht nur eine Website oder E-Mail-Adresse repräsentieren, sondern auch als öffentlich sichtbarer Identitätsanker in ATproto dienen. Ein Handle wie firma.de, name.firma.de oder redaktion.example.com ist im ATproto-Kontext nicht nur ein Anzeigename, sondern ein DNS-basierter Verweis auf eine technische Identität.

Die Grundidee: Identität, Daten und Anwendungen entkoppeln

Klassische soziale Netzwerke koppeln Benutzername, Login, Datenhaltung, Feed, Moderation und App-Oberfläche meist eng an eine Plattform. Wer die Plattform wechselt, verliert häufig Reichweite, Inhalte, Verbindungen oder zumindest die etablierte Identität. ATproto verfolgt einen anderen Ansatz: Die dauerhafte technische Identität ist eine DID, während der menschenlesbare Name als Handle über DNS abgebildet werden kann. Anwendungen können auf öffentlichen Daten aufbauen, sofern sie die passenden Lexicon-Schemata verstehen. (atproto.com)

Für Unternehmen, Selbstständige, Redaktionen und Communities ist das strategisch interessant. Eine eigene Domain besitzt bereits Reputation. Wenn diese Domain als Handle verwendet wird, entsteht eine Form der Selbstverifikation: Wer die DNS-Zone oder den Webspace kontrolliert, kann nachweisen, dass der betreffende ATproto-Account mit dieser Domain verbunden ist.

Wichtige Bausteine von ATproto

DID: die dauerhafte technische Identität

Eine DID ist ein „Decentralized Identifier“, also ein dezentraler Identifikator. In ATproto ist die DID der stabile, kanonische Identifikator eines Accounts. Sie ist für Menschen weniger gut lesbar, aber für Systeme entscheidend. ATproto unterstützt insbesondere did:plc und did:web. Eine DID wird zu einem DID-Dokument aufgelöst, das unter anderem Informationen über den zugehörigen Handle, öffentliche Schlüssel und den Personal Data Server enthalten kann. (atproto.com)

Für die Praxis bedeutet das: Der Handle kann sich ändern, die DID bleibt dagegen der technische Bezugspunkt. Wenn Sie also mit einer Domain als Handle arbeiten, ist die Domain die gut merkbare Adresse, während die DID die belastbare Identität im Hintergrund darstellt.

Handle: der menschenlesbare Name auf DNS-Basis

Ein Handle ist bei ATproto ein DNS-Name. Er kann beispielsweise person.example.com oder example.com lauten. Das bekannte @-Zeichen wird in Benutzeroberflächen häufig davor angezeigt, gehört aber technisch nicht zum Handle selbst. Handles sind nicht der primäre technische Identifikator, sondern müssen in fast allen relevanten Fällen zu einer DID aufgelöst werden. (atproto.com)

Der große Vorteil für Domaininhaber: Sie können eine eigene Domain oder Subdomain als Handle verwenden. Dadurch wird Ihre bestehende Domainautorität für soziale Identität nutzbar. Für Unternehmen bietet sich etwa ein Schema wie dieses an:

• firma.de für den Hauptaccount
• presse.firma.de für Presse- oder Kommunikationsaccounts
• vorname-nachname.firma.de für Mitarbeitende
• support.firma.de für Servicekommunikation
• projekt.firma.de für Kampagnen, Produkte oder Communities

PDS: Personal Data Server

Ein PDS ist ein Personal Data Server. Er hostet den Account eines Nutzers, speichert dessen Datenrepository und verwaltet Signaturschlüssel. Ein PDS kann einen oder viele Accounts betreiben und kommuniziert mit AppViews und Relays. Ein PDS ist nicht primär die sichtbare Social-App, sondern eher die Daten- und Kontoebene im Hintergrund. (atproto.com)

Für Shared-Hosting-Nutzer ist diese Unterscheidung besonders wichtig: Eine Domain als Handle zu nutzen, ist meist eine DNS- oder Webspace-Konfiguration. Einen eigenen PDS zu betreiben, ist hingegen Serverbetrieb und benötigt in der Praxis typischerweise eine Umgebung, in der Dienste, Container, Ports, Zertifikate und Updates kontrolliert werden können. Die offiziellen Self-Hosting-Hinweise verweisen für PDS-Hosting auf Docker-Images und Installationsressourcen; Relays und AppViews sind nochmals anspruchsvollere Infrastrukturkomponenten. (atproto.com)

AppView: die Anwendungssicht

Eine AppView ist die Anwendungsebene, die Daten aus dem Netzwerk aufbereitet und für Nutzer sichtbar macht. Im Vergleich zum Web kann man sich eine AppView wie eine Such-, Indexierungs- und Darstellungsschicht vorstellen. Sie aggregiert Daten, erstellt Ansichten, bietet Suche, Feeds oder Benutzeroberflächenfunktionen und kann mit PDS-Instanzen kommunizieren. (atproto.com)

Für Webprofessionals heißt das: ATproto ist nicht einfach „ein weiterer Webserver“, sondern eine mehrschichtige Architektur. Wer Anwendungen auf ATproto entwickeln möchte, muss unterscheiden, ob er nur mit vorhandenen Daten interagiert, eine eigene AppView betreibt, einen Feedgenerator baut oder sogar eigene Schemas definiert.

Relay und Firehose

Ein Relay sammelt Datenrepositories vieler PDS-Instanzen und stellt daraus einen Strom von Änderungsereignissen bereit, häufig als „Firehose“ bezeichnet. Relays sind eine Skalierungs- und Aggregationskomponente. Sie reduzieren die Notwendigkeit, dass jede Anwendung direkt mit jedem PDS kommunizieren muss. (atproto.com)

Für klassische Hosting-Kunden ist ein Relay in der Regel nicht der Einstiegspunkt. Wer jedoch Data Engineering, Suche, Monitoring, Archivierung oder Social-Web-Analyse betreibt, sollte verstehen, dass Relays eine zentrale Rolle für großflächige Datenaggregation spielen können.

ATproto und Domains: warum DNS so wichtig ist

Der vielleicht greifbarste Berührungspunkt zwischen ATproto und Webhosting ist die Verwendung eigener Domains als Handles. Ein Handle muss bidirektional mit einer DID verbunden sein: Die Domain muss zur DID auflösen, und das DID-Dokument muss wiederum den Handle beanspruchen. Diese bidirektionale Prüfung verhindert, dass beliebige Dritte fremde Accounts unter einer Domain „aliasieren“. (atproto.com)

DNS-TXT-Methode

Die bevorzugte Methode für individuelle Handle-Konfigurationen ist ein DNS-TXT-Record. Dabei wird unter _atproto ein TXT-Eintrag hinterlegt, dessen Wert mit did= beginnt. Für den Handle user.example.com sähe das Prinzip so aus:

txt Name: _atproto.user.example.com Typ: TXT Wert: did=did:plc:example123456789

Wenn Sie die Hauptdomain selbst als Handle verwenden möchten, lautet der Name entsprechend:

txt Name: _atproto.example.com Typ: TXT Wert: did=did:plc:example123456789

In vielen DNS-Oberflächen tragen Sie nicht den vollständigen FQDN ein, sondern nur den Hostnamen relativ zur Zone, also beispielsweise _atproto oder _atproto.user. Hier lohnt es sich, die Logik des jeweiligen DNS-Panels genau zu prüfen.

HTTPS-Well-Known-Methode

Alternativ kann ein Webserver eine Datei beziehungsweise Antwort unter /.well-known/atproto-did bereitstellen. Die Antwort enthält die DID ohne did=-Präfix. Für Shared-Hosting-Nutzer ist diese Variante interessant, wenn DNS-TXT-Einträge nicht komfortabel verfügbar sind oder wenn die Webspace-Verwaltung einfacher ist. Die offizielle Spezifikation verlangt für reale Handle-Auflösung sicheres HTTPS auf Port 443; unverschlüsseltes HTTP ist nur für lokale Entwicklung und Tests vorgesehen. (atproto.com)

Beispielinhalt der Datei:

txt did:plc:example123456789

Wichtig ist: DNS-TXT und Well-Known dürfen nicht widersprüchlich auf verschiedene DIDs zeigen. Wenn beide Verfahren genutzt werden, sollte die Konfiguration sauber, eindeutig und dokumentiert sein.

Bedeutung für Shared Hosting

Für Shared-Hosting-Kunden ist ATproto vor allem über die Domain- und Webspace-Ebene relevant. Sie müssen keinen eigenen PDS betreiben, um eine eigene Domain als Handle zu verwenden. In vielen Fällen reicht es, den passenden DNS-TXT-Record zu setzen oder die Well-Known-Datei im Webspace bereitzustellen.

Typische Aufgaben im Shared Hosting sind:

• DNS-Zone bearbeiten und TXT-Record setzen
• Subdomain-Strategie für Accounts planen
• HTTPS-Verfügbarkeit sicherstellen
• .well-known-Pfad korrekt ausliefern
• Weiterleitungen, Caching und Content-Type prüfen
• Domainverlängerung und DNS-Konsistenz organisatorisch absichern

Gerade der letzte Punkt wird oft unterschätzt. Wenn eine Domain abläuft, DNS-Einträge gelöscht werden oder ein Relaunch die .well-known-Datei entfernt, kann der Handle ungültig werden. ATproto sieht für solche Fälle den Sonderwert handle.invalid vor, wenn ein bekannter DID-Account keinen gültig bestätigten Handle mehr hat. (atproto.com)

Bedeutung für Domaininhaber und Marken

Eine eigene Domain als ATproto-Handle ist ein starker Vertrauensanker. Für Marken, Behörden, Medien, Vereine und Selbstständige kann ein Handle unter der offiziellen Domain eine Alternative zu plattforminternen Verifikationszeichen sein. Statt auf ein Badge-System eines einzelnen Anbieters angewiesen zu sein, wird die Kontrolle über DNS oder Webhosting als Nachweis genutzt.

Das ist besonders wertvoll für:

• Markenaccounts
• Geschäftsführungs- und Pressesprecherprofile
• Redaktionsaccounts
• Support- und Statuskanäle
• Entwickler- und Open-Source-Projekte
• Communities mit eigener Domain
• Mitarbeitende unter einer Organisationsdomain

Gleichzeitig entstehen neue Governance-Fragen. Wer darf einen Handle unter der Unternehmensdomain erhalten? Was passiert beim Ausscheiden eines Mitarbeitenden? Werden Handles personenbezogen, rollenbezogen oder funktionsbezogen vergeben? Wer pflegt die DNS-Einträge? Diese Fragen sollten nicht erst bei Konflikten geklärt werden.

Bedeutung für E-Mail-Poweruser

E-Mail-Poweruser kennen die Bedeutung von DNS-Einträgen bereits von MX, SPF, DKIM, DMARC, Autodiscover oder MTA-STS. ATproto fügt mit _atproto einen weiteren TXT-basierten Nachweis hinzu. Technisch ist das Prinzip vertraut: Eine Domain veröffentlicht maschinenlesbare Informationen, die externe Dienste prüfen können.

Der Unterschied liegt im Zweck. Während SPF oder DKIM die E-Mail-Authentizität und Zustellbarkeit unterstützen, verbindet _atproto eine soziale Identität mit einer DID. Wer bereits mehrere DNS-Nachweise für Dienste wie E-Mail, Suchmaschinen, Analysewerkzeuge oder SaaS-Plattformen verwaltet, sollte ATproto-Einträge genauso sauber dokumentieren:

• Welche Subdomain gehört zu welchem Account?
• Welche DID ist aktuell zugeordnet?
• Wer ist fachlich verantwortlich?
• Welcher TTL-Wert ist gesetzt?
• Gibt es parallele Well-Known-Konfigurationen?
• Wird die Konfiguration nach Website-Relaunches getestet?

AT-URIs: Referenzen im ATproto-Netzwerk

ATproto verwendet sogenannte AT-URIs, die mit at:// beginnen. Eine AT-URI kann auf ein Repository, eine Collection oder einen konkreten Record verweisen. Die Authority-Komponente kann ein Handle oder eine DID sein. Wichtig: Anders als bei https:// gibt die Authority einer AT-URI nicht zwingend den Netzwerkstandort der Ressource an. Ein Handle dient hier der Identitätsauflösung, nicht automatisch als Host des Inhalts. (atproto.com)

Beispiele:

txt at://example.com at://example.com/app.bsky.feed.post at://did:plc:example123456789/app.bsky.feed.post/recordkey

Für Entwickler ist entscheidend: Handles können sich ändern. Wenn eine besonders stabile Referenz benötigt wird, ist die DID in der Authority robuster als der Handle. Für starke Referenzen kann zusätzlich ein CID-Hash sinnvoll sein. (atproto.com)

Lexicon, NSID und Erweiterbarkeit

ATproto-Anwendungen beschreiben Datenstrukturen und APIs über Lexicon. Lexicon ist eine Schemasprache, vergleichbar mit Konzepten aus JSON Schema oder OpenAPI. Sie definiert, welche Records, APIs oder Event-Strukturen eine Anwendung versteht. NSIDs sind namespaced identifiers im Reverse-DNS-Stil, zum Beispiel app.bsky.feed.post. Die Reverse-DNS-Struktur ordnet Schema-Namensräume organisatorisch Domaininhabern zu. (atproto.com)

Für Webprofessionals ist das spannend, weil Domainbesitz hier nicht nur für Handles, sondern auch für Schema-Governance eine Rolle spielen kann. Wer eigene ATproto-Anwendungen entwickelt, kann eigene Lexicon-Schemata unter einem kontrollierten Namensraum veröffentlichen. Die Spezifikation beschreibt dafür auch DNS-TXT-Einträge mit _lexicon, die von der Handle-Auflösung zu unterscheiden sind. (atproto.com)

Sicherheit, Datenschutz und Betrieb

ATproto arbeitet mit öffentlichen Datenrepositories. Das bedeutet: Viele Inhalte sind grundsätzlich für die Verteilung und Verarbeitung im Netzwerk vorgesehen. Für Datenschutz und Compliance ist daher wichtig, die Anwendungsebene genau zu betrachten. Nicht jede Social-Web-Nutzung ist automatisch privat oder vertraulich. ATproto selbst weist darauf hin, dass Mechanismen für nichtöffentliche Daten beziehungsweise persönliche und gruppenbezogene Datenfreigabe geplant sind und nicht einfach durch nachträgliches „Anschrauben“ von Verschlüsselung an bestehende öffentliche Primitive ersetzt werden sollten. (atproto.com)

Aus Betriebssicht empfehlen wir besonders:

• Domainverlängerung langfristig absichern
• DNS-Änderungen versionieren oder dokumentieren
• TTL-Werte bewusst setzen
• Verantwortlichkeiten für DNS und Webspace klären
• HTTPS-Zertifikate und Weiterleitungen regelmäßig prüfen
• .well-known-Pfade bei Relaunches nicht überschreiben
• Handles nach DNS-Änderungen testen
• Mitarbeitenden-Handles organisatorisch sauber verwalten

Für Organisationen mit hohem Schutzbedarf ist außerdem wichtig, Impersonation-Risiken zu berücksichtigen. Ähnlich aussehende Domains oder lange, abgeschnittene Handles können Nutzer täuschen. Die Spezifikation weist ausdrücklich darauf hin, dass solche Handles Sicherheits- und Nachahmungsprobleme erzeugen können. (atproto.com)

ATproto im Vergleich zu klassischem Webhosting

ATproto ersetzt kein Webhosting, keine Domainregistrierung und keinen E-Mail-Dienst. Vielmehr erweitert es die Rolle der Domain im Social Web. Webhosting liefert weiterhin Website, Dateien, SSL/TLS, Weiterleitungen und serverseitige Anwendungen. DNS verbindet Domainnamen mit Diensten. E-Mail nutzt DNS für Zustellung und Authentifizierung. ATproto nutzt DNS und HTTPS zusätzlich für soziale Identität.

Für viele Nutzer ist der erste sinnvolle Schritt daher nicht der eigene PDS, sondern ein sauber konfigurierter Domain-Handle. Damit lässt sich vorhandene Webinfrastruktur nutzen, ohne sofort komplexe Social-Web-Infrastruktur zu betreiben. Wer später tiefer einsteigt, kann sich mit PDS-Self-Hosting, AppViews, Relays, Lexicon-Entwicklung oder Datenanalyse beschäftigen.

Zusammenfassung

ATproto ist ein offenes Protokoll für dezentrale Social-Web-Anwendungen, bei dem Identität, Datenhaltung, Anwendungssicht und Clients voneinander getrennt werden.

Für Domaininhaber ist besonders relevant, dass eigene Domains und Subdomains als Handles genutzt werden können, sofern sie per DNS-TXT oder HTTPS-Well-Known korrekt mit einer DID verbunden sind.

Shared-Hosting-Nutzer müssen in der Regel keinen eigenen PDS betreiben, um eine Domain als Handle zu verwenden; DNS-Zugriff oder Webspace mit HTTPS reichen für viele praktische Anwendungsfälle aus.

Für Webprofessionals eröffnet ATproto zusätzliche Perspektiven rund um Identitätsmanagement, Lexicon-Schemata, AT-URIs, PDS-Betrieb und Social-Web-Anwendungen.

Für Unternehmen, Redaktionen und E-Mail-Poweruser ist eine sorgfältige DNS- und Domain-Governance entscheidend, damit Handles dauerhaft vertrauenswürdig, nachvollziehbar und betriebssicher bleiben.

Fragen, die dieser Text beantwortet

• Was ist ATproto und wofür wird es verwendet?
• Welche Rolle spielen DIDs, Handles, PDS, AppViews und Relays?
• Warum sind Domains und DNS für ATproto so wichtig?
• Wie funktioniert ein eigener Domain-Handle über DNS-TXT oder HTTPS-Well-Known?
• Was müssen Shared-Hosting-Nutzer beachten?
• Wann ist ein eigener PDS sinnvoll und wann nicht?
• Welche Bedeutung hat ATproto für Domaininhaber, Marken und Organisationen?
• Welche Parallelen gibt es zu E-Mail-DNS-Einträgen wie SPF, DKIM oder DMARC?
• Was sind AT-URIs, Lexicon und NSIDs?
• Welche Sicherheits- und Betriebsaspekte sollten professionelle Anwender berücksichtigen?