Der Stand des dezentralen Webs im Jahr 2026

Ein soziales Netzwerk ist im praktischen Sinne dezentral, wenn Nutzer den Anbieter wechseln können, ohne ihre Identität, ihre Daten oder ihre Follower zu verlieren – und ActivityPub, das AT Protocol sowie Solid erfüllen jeweils eine andere Teilmenge dieses Kriteriums.

Einen Server auszuwählen und einigen Accounts zu folgen, ist der leichte Teil. Das Vokabular, das mit diesen Netzwerken einhergeht (PDS, Relay, AppView, Pod, WebID), summiert sich schnell – und nichts davon spielt eine große Rolle, bis zu dem Tag, an dem man umziehen möchte.

Dies ist ein Statusbericht über die drei Protokolle, die heute für das dezentrale Web maßgeblich sind. Er erläutert, wie jedes von ihnen Identität, Daten und Publikum modelliert, benennt den jeweiligen Stand hinsichtlich Verbreitung und Spezifikation, hält registrierte Accounts und aktive Nutzer in den Zahlen sauber auseinander und endet mit einem Dienst, den Sie an einem Nachmittag selbst betreiben können.

Was bedeutet „dezentral” in der Praxis?

Dezentral bedeutet, dass Sie den Hoster Ihres Accounts verlassen und mit drei intakten Dingen an einem anderen Ort ankommen können: Ihrer Identität (der Name, unter dem man Sie kennt, und die dahinterliegenden Credentials), Ihren Daten (Posts, Medien, Follows, Einstellungen) und Ihrem Publikum (den Menschen, die Ihnen folgen und weiterhin erhalten, was Sie veröffentlichen). Geht eines dieser drei Dinge verloren, ist der Wechsel ein Neuanfang mit zusätzlichen Zwischenschritten.

Jedes der nachfolgenden Protokolle wird an diesem Kriterium gemessen – nicht daran, wie viele Server existieren oder wer die Software geschrieben hat. Die Serverzahl sagt etwas über Redundanz aus. Der dreiteilige Test sagt etwas über Lock-in aus.

Wie föderiert ActivityPub zwischen Instanzen?

ActivityPub, seit dem 23. Januar 2018 eine W3C Recommendation, föderiert, indem jeder Server die Aktivitäten eines Nutzers direkt an die Inboxes jener Server ausliefert, die die Follower dieses Nutzers hosten. Jeder Nutzer ist ein Actor mit einer Inbox und einer Outbox; beim Veröffentlichen wird in die eigene Outbox geschrieben, und der eigene Server sendet die Aktivität per POST an die Inbox jedes Followers. Es gibt keinen zentralen Index, sondern nur Server, die sich gegenseitig JSON zuschieben.

Mastodon, Pixelfed, Lemmy und PeerTube implementieren es alle – deshalb kann ein Mastodon-Account einem PeerTube-Kanal oder einer Lemmy-Community folgen.

Bei der Identität scheitert der Test. Ein Handle wie @user@instance.example gehört zur Instanz; ein Account, der nicht vor der Abschaltung seines Servers migriert wurde, lässt sich daher nirgendwo anders wiederherstellen. Mastodons Account-Umzug versendet eine Move-Aktivität, die Follower auf den neuen Account überträgt, doch die Dokumentation stellt klar, dass alles Veröffentlichte zurückbleibt und das herunterladbare Archiv nicht in einen anderen Mastodon-Account geladen werden kann. Am Test gemessen: Das Publikum übersteht einen geplanten Umzug, die Daten teilweise als Export, die Identität überhaupt nicht.

AT Protocol: Portable Identität, konzentrierte Infrastruktur

Beim AT Protocol ist die Identität eines Nutzers eine DID, die keinem Server gehört, und Posts, Follows sowie Profil liegen auf einem Personal Data Server (PDS), der zu einem anderen Hoster verlegt werden kann, ohne dass sich die DID ändert. Über dem PDS liegen Relays, die jeden PDS crawlen und eine einzige Firehose ausgeben, sowie AppViews, die diese Firehose zu dem Produkt indexieren, das ein Client rendert. Die Spezifikation wird von Bluesky Social PBC veröffentlicht und gepflegt.

Die Portabilität hat Grenzen. Der offizielle Leitfaden zur Account-Migration behandelt diese Schritte als etwas, das außerhalb des eigentlichen Protokolls liegt und sich später ändern kann, und verweist auf die goat-CLI oder ein Community-Tool statt auf einen Ablauf innerhalb der App. Bryan Newbold, Protokoll-Entwickler bei Bluesky, schrieb im Oktober 2025, dass der Umzug eines Accounts im Live-Netzwerk seit Anfang 2025 funktioniert, aber noch Sache von Entwicklern ist – und dass die von Bluesky betriebenen PDS-Hosts keine eingehenden Account-Umzüge annehmen.

Die zweite Einschränkung ist operativer Natur. Blueskys Transparenzbericht 2025 besagt, dass das Unternehmen mehr Accounts hält als jeder andere und dort, wo die meisten Menschen sich anmelden – während sich der Rest des Netzwerks über tausende Personal Data Server verteilt, von denen die meisten von anderen betrieben werden. Keine offizielle Zahl quantifiziert, welcher Anteil des Netzwerks über das von Bluesky betriebene Relay und die AppView läuft. Kritiker argumentieren, dass unabhängige PDS-Hoster und Community-Infrastrukturprojekte sich weiterhin auf von Bluesky betriebene Kerndienste stützen, und manche schließen daraus, das Netzwerk sei in der Praxis nicht dezentral; das ist eine Bewertung, keine Messung. Am Test gemessen: Identität und Daten überstehen einen Anbieterwechsel per Design, Follower kommen mit, weil Follow-Records auf DIDs verweisen – und die Schichten oberhalb des PDS bleiben größtenteils in der Hand eines einzigen Unternehmens.

Solid: Daten-Pods ohne Endkundenmarkt

Solid speichert die Daten eines Nutzers in einem Pod, den dieser kontrolliert, und verlangt von jeder Anwendung, Zugriff anzufordern. Eine WebID identifiziert die Person, der Pod ist ein HTTP-Server, der RDF-Ressourcen hält, und Apps lesen und schreiben diese Ressourcen, sobald die Autorisierungsregeln es zulassen. Beim Test des Anbieterwechsels hat Solid das klarste Design der drei: Identität, Daten und Zugriffsregeln liegen sämtlich beim Nutzer, und eine App ist lediglich ein Client.

Die Verbreitung entspricht dem Design nicht. Das Solid Protocol ist ein Entwurf einer W3C Community Group (v0.11.0, 12. Mai 2024) und kein W3C-Standard; der TR-Index zeigt seither keine neue Version. Die vorangegangenen Releases waren 0.9.0 (Dezember 2021) und 0.10.0 (Dezember 2022), und die Arbeit an 0.12.0 liegt im Editor’s Draft. Die Erweiterungsspezifikationen, auf die Apps angewiesen sind – WebID Profile, Type Indexes und Application Interoperability –, sind weiterhin Entwürfe, und die Spezifikation erlaubt zwei inkompatible Autorisierungssysteme, WAC und ACP, wobei Server frei wählen können, welches sie implementieren. Tooling und Dokumentation hinken hinter beiden anderen Protokollen her.

Der praktische Hemmschuh ist die Frage, wo man sich überhaupt registriert. solidproject.org listet rund fünfzehn gehostete Pod-Dienste, die meisten klein oder experimentell, und Inrupt, das von Tim Berners-Lee mitgegründete Unternehmen, vermarktet heute Enterprise-Wallet-Infrastruktur an Unternehmen. Der Solid-App-Entwickler Noel De Martin benannte 2024 den fehlenden Endkundenmarkt für Pods als das größte Hindernis für Solid: Wer jemanden bittet, sich mit Solid anzumelden, schickt diese Person zunächst auf die Suche nach einem Anbieter – und genau dort hören die meisten auf.

Wie viele Nutzer haben Bluesky und Mastodon?

Blueskys Transparenzbericht 2025 (29. Januar 2026) zählte zum Ende des Jahres 2025 41,41 Millionen Accounts – nach 25,94 Millionen zuvor – über von Bluesky gehostete und unabhängige PDSs hinweg; das Unternehmen erfasst eine Zahl monatlich aktiver Nutzer, veröffentlicht sie aber nicht. Der Bericht normalisiert seine Moderationsdaten je 1.000 monatlich aktive Nutzer, ohne den Nenner zu nennen.

Mastodon veröffentlicht auf der Server-Seite von joinmastodon.org eine eigene netzwerkweite Zahl, und Drittanbieter-Tracker, die Instanz-Statistik-APIs abfragen, veröffentlichen ihre eigenen. Die Zahlen stimmen nicht überein. TechCrunch berichtete im Februar 2026, dass Mastodons eigene Website rund 785.000 monatlich Aktive auswies, während die Tracker – je nachdem, welchen man fragte – zwischen etwa 750.000 und einer Million lagen. Diese Tracker verorten die registrierten Accounts bei rund 10 Millionen auf etwa 10.000 Servern, wobei die Gesamtzahlen zwischen den Trackern um eine Million oder mehr schwanken, abhängig davon, wie jeder mit inaktiv gewordenen Servern umgeht.

Registrierungen und Aktive unterscheiden sich bei Mastodon um eine Größenordnung, und Blueskys Verhältnis ist unbekannt. Ein Vergleich, der die Registrierungen eines Netzwerks den Aktiven eines anderen gegenüberstellt, vergleicht unterschiedliche Größen.

Was lässt sich auf ActivityPub, Solid und Bluesky bauen?

Alle drei Protokolle sind schlichtes HTTP – deshalb genügt ein Terminal, um sie zu inspizieren:

# ActivityPub: resolve a handle with WebFinger, then fetch the actor document
curl -s 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
curl -s -H 'Accept: application/activity+json' https://mastodon.social/users/Mastodon

# Solid: read an RDF resource from a pod as Turtle (replace with a real pod URL)
curl -s -H 'Accept: text/turtle' https://alice.example.org/profile/card

WebFinger ist RFC 7033 und eine Konvention des Mastodon-Ökosystems, nicht Teil von ActivityPub selbst. Solid-Server müssen RDF-Ressourcen auf Anfrage als Turtle oder JSON-LD ausliefern.

Das zugänglichste Projekt ist ein Bluesky Custom Feed. Ein Bluesky Custom Feed ist ein HTTP-Dienst, der eine sortierte Liste von Post-URIs zurückgibt; die AppView holt und rendert diese Posts selbst, sodass der Feed-Dienst niemals Post-Inhalte speichern oder ausliefern muss. Zwei XRPC-Routen sind erforderlich, und das getFeedSkeleton-Lexicon definiert die Parameter (feed, limit bis zu 100, cursor) sowie den Fehler UnknownFeed:

// feedgen.mjs — run with: node feedgen.mjs
import { createServer } from 'node:http';

const SERVICE_DID = 'did:web:feeds.example.com';
const FEED_URI = 'at://did:plc:yourpublisherdid/app.bsky.feed.generator/weekend';

// A real generator fills this from a firehose consumer or a database.
const POSTS = [
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux6xlrdb42v',
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux7x2uvip2v',
];

const json = (res, status, body) => {
  res.writeHead(status, { 'content-type': 'application/json' });
  res.end(JSON.stringify(body));
};

createServer((req, res) => {
  const { pathname, searchParams } = new URL(req.url, 'http://localhost');

  if (pathname === '/xrpc/app.bsky.feed.describeFeedGenerator') {
    return json(res, 200, { did: SERVICE_DID, feeds: [{ uri: FEED_URI }] });
  }

  if (pathname === '/xrpc/app.bsky.feed.getFeedSkeleton') {
    if (searchParams.get('feed') !== FEED_URI) {
      return json(res, 400, { error: 'UnknownFeed', message: 'Feed not found' });
    }
    // Requests may carry a JWT signed by the user's key. A feed that is
    // identical for every user can ignore it, as this one does.
    const limit = Math.min(Number(searchParams.get('limit') ?? 50), 100);
    const start = Number(searchParams.get('cursor') ?? 0);
    const page = POSTS.slice(start, start + limit);
    const cursor = start + limit < POSTS.length ? String(start + limit) : undefined;
    return json(res, 200, { feed: page.map((post) => ({ post })), cursor });
  }

  json(res, 404, { error: 'NotFound' });
}).listen(3000);

Der Cursor ist für die AppView opak und ganz Ihre Sache; für eine feste Liste genügt ein Positionsindex, und das offizielle Tutorial empfiehlt einen zusammengesetzten Cursor aus Timestamp und CID, sobald die Posts aus einem Live-Index kommen. Für den Produktivbetrieb deployen Sie über HTTPS, veröffentlichen ein DID-Dokument, das auf den Host verweist (das Starter Kit richtet dies standardmäßig als did:web ein), und führen dessen Skript publishFeedGen.ts aus, um den app.bsky.feed.generator-Record in Ihrem eigenen Repo zu erzeugen. Von da an erscheint der Feed in der Bluesky-App wie jeder andere.

Wo wir stehen

Am Kriterium des Anbieterwechsels gemessen, überträgt ActivityPub die Follower, aber nicht die Identität; das AT Protocol überträgt auf dem Papier alle drei, während der Großteil des Netzwerks weiterhin über Relay und AppView eines einzigen Unternehmens läuft; und Solid überträgt im Prinzip alles, ohne einen Endkundenmarkt, der es tatsächlich trägt. Wählen Sie das Protokoll, mit dessen Schwachstelle Sie leben können – und investieren Sie dann ein Wochenende in den obigen Feed-Generator: Er ist der kürzeste Weg vom Lesen über das dezentrale Web zum Betreiben eines Stücks davon.

FAQs

Können sich Bluesky- und Mastodon-Nutzer gegenseitig folgen?

Nicht direkt: ActivityPub und das AT Protocol sind nicht interoperabel, weshalb netzwerkübergreifende Follows über eine Bridge laufen. Bridgy Fed, betrieben von der Non-Profit-Organisation A New Social, funktioniert per Opt-in: Ein Bluesky-Nutzer folgt @ap.brid.gy, ein Fediverse-Nutzer folgt @bsky.brid.gy@bsky.brid.gy. Gebridgte Accounts erscheinen auf Bluesky als user.instance.ap.brid.gy und im Fediverse als handle@bsky.brid.gy. Nur vollständig öffentliche Posts werden gebridgt, und Fediverse-Posts mit mehr als 300 Zeichen werden auf Bluesky abgeschnitten.

Was ist der Unterschied zwischen did:plc und did:web beim AT Protocol?

Das AT Protocol unterstützt nur zwei DID-Methoden. did:plc, entwickelt von Bluesky Social PBC, registriert Identifier im PLC-Directory, unterstützt Key-Rotation und Recovery und wird vom offiziellen PDS-Installer für neue Accounts erzeugt. did:web leitet den Identifier von einem Hostnamen ab, den Sie kontrollieren, erlaubt ausschließlich Identifier auf Hostnamen-Ebene ohne Pfade und bietet keine Wiederherstellung, wenn Sie die Domain verlieren – es eignet sich daher für Dienste wie Feed-Generatoren.

Kann ich meine eigene Domain als Bluesky-Handle nutzen, ohne einen PDS zu hosten?

Ja. Ein Handle ist ein DNS-Hostname, der bidirektional mit Ihrer DID verknüpft ist, und diese Verknüpfung ist unabhängig davon, welcher PDS Ihre Daten speichert. Veröffentlichen Sie die DID an einer von zwei Stellen: in einem DNS-TXT-Record namens _atproto.yourdomain mit dem Wert did= gefolgt von Ihrer vollständigen DID, oder als Klartext-Antwort unter https://yourdomain/.well-known/atproto-did. Die Spezifikation empfiehlt Privatpersonen die DNS-Methode; die HTTPS-Methode richtet sich an große Dienste.

Wenn ich einen Personal Data Server selbst hoste, kann ich die Bluesky-App weiterhin nutzen?

Ja. Der offizielle PDS wird als Docker-Image für einen VPS mit öffentlicher IPv4-Adresse, einem Wildcard-DNS-Record und offenen Ports 80 und 443 ausgeliefert; Bluesky empfiehlt 1 GB RAM und 20 GB Speicher für 1 bis 20 Nutzer. Zum Anmelden geben Sie Ihre PDS-URL in der App ein. Die Standardkonfiguration verweist auf Blueskys AppView, Relay und PLC-Directory – der PDS ist somit oberhalb der Datenschicht weiterhin von Bluesky-betriebenen Diensten abhängig.