Die Migration eines Bluesky Accounts auf einen eigenen Personal Data Server (PDS) stellt für viele Nutzer eine interessante Möglichkeit dar, mehr Kontrolle über ihre Daten zu erlangen und unabhängig von den zentralen Hosting-Diensten zu werden. Der Prozess ist technisch anspruchsvoll und erfordert ein gutes Verständnis sowohl der technischen Grundlagen von Bluesky als auch der eingesetzten Tools. Dieser Artikel begleitet dich auf dem Weg vom ursprünglichen Mushroom-PDS zum selbst gehosteten Server und zeigt, worauf du achten musst, um einen reibungslosen Umzug zu ermöglichen. Besonders relevant ist das Thema für Nutzer mit einem umfangreichen Account und vielen Beiträgen, da die Datenmengen beträchtlich sein können. Bluesky basiert auf dem AT Protocol, das strenge Anforderungen an Identität, Schlüsselverwaltung und Datenkonsistenz stellt.
Eine sorgfältige Planung und präzise Ausführung sind nötig, da die aktuelle Toollandschaft noch keine vollautomatischen Lösungen für die Migration bereithält – das bedeutet, dass manuelle Arbeitsschritte und Problemlösungen zum Alltag gehören. Begonnen wird mit der Inspektion des bestehenden Accounts. Hilfreich dafür ist das Tool pdsls. dev, mit dem du alle relevanten Informationen zu deinem Account einsehen kannst. Die DID (Decentralized Identifier) des Accounts beinhaltet etwa Angaben, wo der Account derzeit gehostet ist, welche Keys gültig sind und wie die Identitätszuordnung aussieht. Die DID ist unveränderlich und bildet den Kern deiner Identität innerhalb des AT Protocol-Ökosystems. Nachdem man sich vergewissert hat, dass alle bestehenden Metadaten vollständig und aktuell sind, folgt die Einrichtung der nötigen Werkzeuge. Die wichtigste Hilfsanwendung ist der „goat“ Kommandozeilen-Client, der den Zugriff auf Account-Daten, Blob-Management und DID-Dokumente ermöglicht.
Voraussetzung ist eine funktionierende Go-Umgebung, die auf gängigen Betriebssystemen wie macOS oder Linux problemlos installiert werden kann. Die Installation erfolgt in wenigen Schritten und eröffnet Zugriff auf diverse Kommandos, die den komplexen Migrationsprozess managen. Bevor der tatsächliche Umzug beginnt, ist es ratsam, eine sogenannte Recovery Key einzurichten. Dieser Schlüssel fungiert als Sicherheitsmechanismus, falls zum Beispiel der bisherige PDS-Host kompromittiert wird oder die ursprünglichen Schlüssel verloren gehen. Ein Recovery Key ermöglicht die Wiederherstellung der eigenen Identität und damit den Zugriff auf einen fremdübertragenen Account. Die Verwaltung erfolgt ebenfalls über „goat“ und erfordert das Anfordern eines temporären Tokens per E-Mail, um Operationen wie das Hinzufügen eines neuen Schlüssels durchzuführen. Stimmen Verwaltung und Sicherheit der Schlüssel, folgt die Datenextraktion aus dem ursprünglichen PDS, dem sogenannten Mushroom-PDS.
Hierbei wird der Account in zwei Teile zerlegt: Zum einen die Repository-Daten, die alle Beiträge, Likes und andere strukturierte Inhalte enthalten, und zum anderen die Blobs, sprich Mediendateien wie Bilder und Kurzvideos. Die Repository-Daten werden als sogenanntes CAR-File (Content Addressable Archive) exportiert. Dieses Format ermöglicht eine konsistente, blockchainähnliche Struktur, die für die Übertragung und spätere Re-Importierung entscheidend ist. Das Herunterladen der Blobs gestaltet sich dagegen deutlich aufwändiger, insbesondere bei großen Datenmengen. Aufgrund von Netzwerk-Timeouts und Serverbeschränkungen können wiederholte Versuche erforderlich sein. Dafür bietet „goat“ jedoch eine Art Wiederaufnahmefunktion, die bereits heruntergeladene Dateien überspringt, damit der Download nicht bei jedem Verbindungsabbruch von vorne beginnen muss.
Neben reinen Datenpunkten ist es ebenfalls möglich, die persönlichen AppView-Präferenzen zu exportieren, welche individuell angelegte Einstellungen abbilden. Obwohl diese Objekte vergleichsweise klein sind, tragen sie zu einer vollständigen Account-Übernahme bei. Auf der Zielseite, dem eigenen PDS, ist vor der eigentlichen Datenübertragung zunächst die Erstellung eines neuen Accounts notwendig. Dabei wird die ursprüngliche DID wiederverwendet, um Kontinuität der Identität zu gewährleisten. Eine wichtige Hürde stellt der Diensttoken dar, der den Account-Erstellungsprozess absichert und via Dienstauthentifizierung per Kommando generiert wird. Einladungen und Invite-Codes sind dabei bedingt je nach Server erforderlich. Nach erfolgreich angelegtem Account folgen der Import der Repository-Daten und das Hochladen der Blobs zum neuen PDS. Letzteres kann durch technische Limitierungen des Servers erschwert werden. So sind z. B.
Upload-Limits als Voreinstellung bei einem selbst betriebenen Server oftmals konservativer als beim offiziellen Mushroom-PDS. Ein Beispiel hierfür ist die Dateigrößenbeschränkung, die erst im Server-Umfeld angepasst werden sollte. Dies geschieht durch Änderung der Konfigurationsdatei in „pds. env“ und einem anschließenden Neustart des Dienstes. Fehler während des Datenimports, wie abgebrochene HTTP-Verbindungen oder Zeitüberschreitungen, sind keine Seltenheit. Sie erfordern Geduld, Wiederholungen und gegebenenfalls Anpassungen an der Serverkonfiguration. Ein „fehlerfreier“ Import wird durch den Abgleich der erwarteten und importierten Blobs sowie der Revisionsnummern dokumentiert. Das graue Ende des Prozesses bildet die finale Aktualisierung des DID-Dokuments. Dieses Dokument beschreibt, wo deine Identität verortet ist und welche Schlüssel zur Verifikation gelten.
Da der Umzug des Kontos auch mit einer Änderung der Hosting-URL und Verifizierungskeys einhergeht, muss das DID-Dokument entsprechend angepasst werden. Der Prozess hierfür fordert eine sorgfältige Bearbeitung und signierte Übermittlung mittels „goat“. Jede Änderung am DID-Dokument, auch scheinbar kleine wie die Änderung von Aliasnamen, invalidiert die Signatur und verlangt eine erneute Signierung mit einem aktuellen Token. Ist dieser Vorgang erfolgreich, wird die Identität offiziell auf den neuen PDS verwiesen und gilt als „validDid“. Lediglich ein abschließender Wechsel des Handles auf den ursprünglichen Namen über das Webinterface ist oft noch erforderlich, um die Konsistenz nach außen zu gewährleisten. In Bezug auf das alte Konto auf dem Mushroom-PDS ist der Zustand uneindeutig. Offizielle Löschprozeduren stoßen aufgrund technischer Beschränkungen in der Chat- und Datenverwaltung an Grenzen.
Als beste praktikable Lösung empfiehlt sich die Deaktivierung des Kontos, um möglichen Missbrauch zu vermeiden. Der gesamte Prozess demonstriert, wie der aktuelle Stand der Technik bei Bluesky-Migrationen funktioniert: Manuelles Eingreifen, Verständnis jedes Schrittes, Umgang mit Fehlern und ein tiefer Einblick in die Architektur von AT Protocol sind Grundvoraussetzungen. Dennoch eröffnet die Möglichkeit, seinen Account selbst zu hosten, eine faszinierende Perspektive für Nutzer, die Wert auf Datensouveränität legen. Zukünftige Entwicklungen im Bereich der Automatisierung, etwa in Form verbesserter Migrations-Tools, könnten diesen Prozess vereinfachen und einer breiteren Nutzerbasis zugänglich machen. Bis dahin garantiert eine gründliche Vorbereitung, die Nutzung etablierter Werkzeuge und ein gewisses technisches Know-how einen erfolgreichen Umzug der Bluesky-Daten auf einen eigenen PDS.
