Project Sovereignty

Einführender Kontext

In Zeiten von Agenten, Bots und Fake-Identitäten wird es wichtig, Lösungen zu denken, die Vertrauen zurückholen und die Möglichkeit bieten, Informationen verifizieren zu lassen. Es wird nicht nur immer wichtiger, autonome KI-Agenten von echten Menschen zu unterscheiden, sondern auch, zwischen all dem Slop die realen Informationen zu identifizieren.

Gleichzeitig sind Daten der Rohstoff für das Training von KI. Es erscheint weder sinnvoll noch zeitgemäß, dass Plattformen aus der Web-2.0-Dekade die eigentlichen Besitzer und Gatekeeper vieler Daten sind. Ein Beispiel sind Daten, wie man sie auf LinkedIn vorfindet — und um die sich die verschiedensten Geschäftsmodelle entwickelt haben.

Project Sovereignty — MonkeyTribe Protocol

Project Sovereignty ist ein MonkeyLab-PoC: Das Projekt untersucht die Möglichkeit eines dezentralen professionellen Netzwerks, in dem Nutzer die Hoheit über ihre Karrieredaten (Ausbildung, Berufsstationen, Fähigkeiten etc.) behalten — während Recruiter, Partner und Interessenten trotzdem zwischen selbst getätigten und verifizierten Angaben unterscheiden können.

LinkedIn und vergleichbare Plattformen sind für Recruiter (und Jobsuchende) natürlich sehr interessant — aber letztlich auf Kosten der Nutzer: Profile sind an die Plattform gekoppelt, und diese (als Marktplatz inszeniert) entscheidet über Sichtbarkeit und die Möglichkeiten der Datenverwertung.

Die Idee war hier nun, anstelle einer zentralen Plattform ein Protokoll auf Eignung zu untersuchen. Ich habe dafür das AT-Protokoll gewählt. ATProto (das Protokoll hinter Bluesky) bietet eine spannende technische Alternative auf Basis portabler Identitäten, offener Lexicons und dezentraler Speicherung. Was mir konzeptuell noch fehlte, war ein Trust-Layer, der z.B. Recruiting-taugliche Verifikation abbilden könnte — so dass sich eigene Angaben von offiziellen oder Peer-bestätigten Angaben unterscheiden lassen.

Dieser Work-Artikel dokumentiert kurz den Stand und die Grundidee des PoC.

Ausgangslage

Die These: Souveränität im Recruiting entsteht nicht durch „noch eine Business-Plattform“, sondern durch nachvollziehbare Data Lineage (~ Rückverfolgbarkeit von Daten) und Verifikation — über eine Infrastruktur, auf die sich der Nutzer verlassen kann.

Systemarchitektur

Die Architektur ist bewusst hybrid: dezentrales Protokoll für Identität und Records, eigene AppView für Trust-Logik und Indexierung. Für den PoC habe ich mich entschieden, eine Server-Ebene umzusetzen, gegen die ein “exemplarischer” Client arbeitet. Auf der Serverseite wird das Datenmodell (welches die für unseren Case relevanten Daten als Lexicon modelliert) verwaltet und der Austausch gewährleistet. Der Client ist ein dezentrales Gegenstück (könnte also auch problemlos erweitert werden, z.B. zu einer Freelancer-Anwendung), das gegen dieses Format arbeitet. Vereinfacht also so:

┌─────────────────┐     XRPC / OAuth      ┌──────────────────┐
│  Client (Nuxt 4)│ ◄──────────────────►  │  AppView Server  │
│  Profil, Import │                       │  Node.js         │
│  Trust UI       │                       │  SQLite/Drizzle  │
└────────┬────────┘                       └────────┬─────────┘
         │                                         │
         │                              Firehose Subscribe
         │                                         │
         ▼                                         ▼
              ATProto (DIDs, Lexicon, PDS)

Client App (Nuxt 4)

Frontend für eigene Profilverwaltung, Recruiting-Features, Trust-Level Visualisierung und LinkedIn-Import. Hier läuft das gesamte UI inklusive Terminal-Style Import-Feedback.

AppView Server (Node.js)

ATProto-Relay: verwaltet Sovereignty-Lexicon-Records, abonniert Firehose-Events, stellt XRPC-Endpoints bereit. SQLite via Drizzle ORM als lokaler Index — die Bridge zwischen PDS und Client. Ich habe hier SQLite verwendet, da ich zunächst eine pragmatische, leichtgewichtige Lösung anvisiert habe. Drizzle abstrahiert die Datenbankschicht, so dass später auf Postgres migriert werden kann, wenn es um andere Skalierung ginge.

Wichtig fürs Verständnis: Der AppView ist nur ein Index. Die eigentlichen Daten leben im PDS des Nutzers. Fällt der AppView weg, gehen keine Daten verloren — jeder kann einen eigenen AppView gegen dieselben Daten betreiben.

        SOURCE OF TRUTH                       NUR EIN INDEX
  ┌───────────────────────┐  Firehose   ┌───────────────────────┐
  │   PDS des Nutzers     │ ──────────► │   AppView (SQLite)    │
  │   • Alle Records      │  (Stream)   │   • Suchindex         │
  │   • User-kontrolliert │             │   • Trust-Scores      │
  └───────────────────────┘             └───────────────────────┘
       bleibt immer beim                  jederzeit löschbar &
       Nutzer (portabel)                  neu aufbaubar (Backfill)

Das ist der entscheidende Unterschied zu LinkedIn: Dort ist die Plattform die Datenbank. Hier ist die “Plattform” nur eine austauschbare Lesebrille auf Daten, die dem Nutzer gehören.

Warum ATProto?

• DIDs — verifizierbare, portable Identitäten
• Lexicon — strukturierte, versionierbare Datenschemata
• Firehose — Echtzeit-Event-Streaming
• OAuth 2.0 — standardisierte Auth
• Portable Data — PDS-Wechsel ohne Profil-Neuaufbau

Trust-Berechnung (Scores, Ranking) liegt serverseitig im AppView.

Kryptografische Grundlagen

Das Protokoll basiert auf Ed25519 Public-Key-Kryptografie — keine Blockchain, keine Token, keine Gas Fees. Die kryptografische Integrität ist jedoch zentral für das Trust-System.

Identitäten (DIDs)

Jeder Nutzer hat eine Decentralized Identifier (DID) — permanente, kryptografische Identität:

Die DID ist der “Anker” für alle Signaturen und Verifikationen.

AT-URI & CID

Jeder Record hat eine eindeutige Adresse:

at://did:plc:alice001/de.monkeytribe.sovereignty.experience/tid123

Der CID (Content Identifier) ist der kryptografische Hash des Record-Inhalts. Wichtig: Für Signaturen wird der CID über den Record ohne die Felder verification und encryptedPayload berechnet (Protocol Invariant #4). Dies verhindert zirkuläres Hashing.

Signatur-Scope (Invariante)

Institutionelle Signaturen signieren nur die Claim-Daten, nicht die Metadaten:

// Was signiert wird (Canonical CID):
{
  $type: "de.monkeytribe.sovereignty.experience",
  role: "Senior Dev",
  organizationName: "Acme Corp",
  startDate: "2022-01-01",
  // ... weitere Felder
}

// Was NICHT signiert wird:
{
  verification: { ... },      // Wird nachträglich hinzugefügt
  encryptedPayload: "..."     // Optional, verschlüsselte Daten
}

Revocation

Issuer oder Record-Owner können ein revocation Record publishen:

{
  "$type": "de.monkeytribe.sovereignty.revocation",
  "subjectCid": "bafyrei...",
  "subjectUri": "at://.../experience/tid",
  "revokerDid": "did:web:acme-corp.com",
  "revokerType": "issuer",
  "reason": "Optional",
  "createdAt": "2026-07-06T08:00:00.000Z"
}

Der AppView kaskadiert diese Revocation automatisch und setzt verificationStatus auf revoked.

Authentifizierung: ATProto OAuth

Der Login funktioniert über ATProto OAuth 2.0 — derselbe Standard wie bei allen Bluesky-Apps. Für Nutzer sieht es aus wie “Sign in with Google”, aber mit stärkeren Sicherheitsgarantien.

Der Flow (Schritt für Schritt)

1. Klick auf “Connect with Bluesky” → Nutzer gibt Handle ein (z.B. alice.bsky.social)
2. Redirect zum eigenen PDS → Nicht zu Sovereignty, sondern zum PDS-Provider (z.B. bsky.social)
3. Permission Screen → “Sovereignty Client darf Profile lesen und Records schreiben” → Nutzer klickt “Allow”
4. Redirect zurück zum Client → Client erhält kurzlebigen Access Token
5. Declaration Record → Nutzer publisht mit einem Klick (“Create my profile”) einen declaration Record in den eigenen PDS — das Signal fürs Netzwerk, dass dieser Account am Protokoll teilnimmt

DPoP (Demonstrating Proof of Possession)

ATProto OAuth verwendet DPoP — ein stärkeres Sicherheitsmodell als Standard Bearer Tokens:

• Client generiert lokales Ed25519 Keypair
• Access Token ist mathematisch an dieses Keypair gebunden
• Selbst wenn Token abgefangen wird → nutzlos ohne Private Key (der auf dem Gerät bleibt)

Umgesetzt ist das als BFF-Pattern (Backend for Frontend): Der Nitro-Server des Nuxt-Clients hält das DPoP-Keypair serverseitig, der Browser kommuniziert nur mit den eigenen /api/* Endpoints. Tokens erreichen den Browser nie.

Wichtig: Das Passwort des Nutzers berührt den Sovereignty Client nie. Authentifizierung läuft immer über den eigenen PDS-Provider — und der Zugriff kann jederzeit dort widerrufen werden.

ID-Mapping & Firehose

Wie werden Identitäten und Daten im System verknüpft?

DID → Handle Resolution

Der AppView löst DIDs zu Handles auf (und umgekehrt) über ATProto-Resolver. Dies ermöglicht flexible Identitätswechsel ohne Datenverlust.

Firehose-Subscription

Der AppView abonniert den ATProto Firehose (WebSocket-Stream) bei bsky.network:

Commit-Event → Filter auf de.monkeytribe.sovereignty.* → Indexierung

Jede Änderung an Records erscheint innerhalb von Sekunden im Suchindex. Kein Polling, keine Verzögerung.

Data Lineage über claimSource

Jeder Record trägt eine claimSource für Herkunftsnachweis:

Sobald ein L2 Peer-Vouch oder eine L3 Institution-Signatur existiert, wird der Penalty komplett aufgehoben (“Escape Hatch”). Der volle Trust-Score-Algorithmus ist als Architektur spezifiziert; im PoC läuft ein vereinfachtes Score-Modell, die claimSource wird aber bereits durchgängig indexiert.

Trust Architecture (PoC-Level)

Für Daten wie Skills, Arbeitserfahrung etc. ist vorgesehen, dass es verschiedene Ebenen der Verifizierung gibt. Da Orte wie LinkedIn nicht zuletzt Orte der Selbstinszenierung sind, fand ich es wichtig zu überlegen, wie Informationen von Dritten als ‘wahr’ bestätigt werden könnten: Wie könnte man Zeugnisse, Zertifikate etc. maschinell signieren? Wie können Personen sich untereinander Fähigkeiten attestieren? Ich habe mich für die PoC-Phase zu einem mehrstufigen Modell entschieden.

Das Vertrauensmodell in drei Stufen:

Jeder Datensatz beinhaltet eine Provenance: claimSource (native, linkedin-import, resume-parser), Issuer-DID, Signature Timestamp. Über DataLineageTooltip ist die Herkunft im UI nachvollziehbar.

Vouch Request Flow (3 Schritte)

Wie kommt man von L1 zu L2? Indem andere für die eigenen Angaben ‘bürgen’. Der Flow ist bewusst so einfach gehalten wie das Teilen eines Spotify-Links:

1. URL Generation — eindeutiger Vouch-Link pro Experience
2. Copy Link — Clipboard API mit Toast-Feedback
3. Message Snippets — formelle und lockere Templates für Slack, E-Mail, LinkedIn

Ziel: virales Wachstum der Verifikation ohne zentrale Moderation.

Sybil-Resistenz

Damit Endorsements nicht direkt zum “Endorsement-Spam” verkommen, sieht die Trust-Architektur vor, das Gewicht eines Vouches an die Identität des Endorsers zu koppeln:

Zusätzlich ist Reputation Staking konzipiert: Wer für ein später als Fake geflaggtes Profil gebürgt hat, verliert selbst Trust-Score. Beides wird rein AppView-seitig zur Query-Zeit berechnet — keine PDS-Writes nötig, deterministisch reproduzierbar. Im PoC ist dieses Modell spezifiziert und vorbereitet; die Score-Engine selbst läuft aktuell in einer vereinfachten Version.

LinkedIn Import

LinkedIn ist nun mal aktuell einer der geläufigsten und wirkmächtigsten Marktplätze, wenn es um professionelle Profile geht. Daher war es nur logisch, den LinkedIn-Export als sehr wahrscheinliche Import-Quelle heranzuziehen. Jeder würde die eigenen Daten von dort in ein universelleres Profil mappen wollen. Somit habe ich das als Use Case direkt mit umgesetzt.

Wer auf LinkedIn einen Export der eigenen Daten anfordert, bekommt ein ZIP mit vielen wilden CSV-Dateien. Der Import transformiert diese Daten und mappt sie auf die ATProto-Records unseres Lexicon-basierten Datenmodells:

1. CSV-Parsing (Positions, Education, Skills, …)
2. Mapping auf Sovereignty Lexicon
3. claimSource = 'linkedin-import' für Lineage
4. Terminal-Style Progress mit Echtzeit-Logs
5. Post-Import Screen mit Top-2-Jobs als nächster CTA (Vouch anfragen)

Mapper (11): Position, Education, Certification, Honor, Project, Publication, Volunteer, Course, Skill, Endorsement, Recommendation

UI & Design System

Das User Interface der Client-App ist bewusst einfach gehalten. Denn primär ging es in dem Projekt um das Datenmodell, die Protokoll-Nutzung und konzeptuelle Aspekte bzgl. Identität und Verifikation von Informationen — weniger um UI.

Trotzdem erschien es sinnvoll, eine erste Beispielanwendung umzusetzen, die man sehen und direkt benutzen kann. Interessant war dabei vor allem, wie das UI Vertrauen kommunizieren kann: Unverifizierte Daten werden visuell gedimmt und eingeklappt, verifizierte Daten hervorgehoben — die Trust-Hierarchie wird direkt sichtbar (“Visual Collapsing”).

So sind ein paar Komponenten für die grundsätzlichen Zwecke auf Vue-3/TailwindCSS-v4-Basis in der Nuxt-App entstanden:

Design Tokens für trust, peer, sovereign; Dark Mode mit Mode Toggle; Dialog-Modals via Teleport; Sonner Toasts; Mobile First.

Experience Grouping: semantische Gruppierung von Stationen inkl. Projects-Section.

Technischer Stack (Monorepo)

Insgesamt habe ich mich für ein Monorepo mit folgenden Zutaten entschieden:

Einordnung im MonkeyLab

Project Sovereignty hängt konzeptuell mit Mehr digitale Souveränität wagen und dem MonkeyTribe-Ökosystem zusammen — aber mit anderem Fokus:

• MonkeyTribe CRM — operative Tools für Selbstständige
• MonkeyTribe 2.0 — hybride Mensch-Agenten-Teams (Update im CRM-Work-Eintrag )
• Project Sovereignty — Datenhoheit und Trust im beruflichen Identitätsraum

Es ist ein Forschungs-PoC, kein Gegenentwurf zu LinkedIn im Marktmaßstab — sondern ein Test, ob ATProto + Trust-Tiers ein besseres Nutzererlebnis bei kontrollierter Datenhoheit ermöglichen.

Ergebnisse & Learnings

Der PoC beantwortet die Ausgangsfrage positiv — mit klaren Einschränkungen:

Was funktioniert:

• ATProto trägt den Use Case. Eigene Lexicons, Firehose-Indexierung und OAuth funktionieren zuverlässig — Karrieredaten lassen sich vollständig dezentral abbilden, ohne Blockchain-Overhead.
• Trust ist modellierbar. Das L1/L2/L3-Modell plus Data Lineage (claimSource) macht den Unterschied zwischen Behauptung und Verifikation maschinenlesbar — genau das, was z.B. LinkedIn-Profilen fehlt. Die Frage nach Identitätsnachweis ist damit jedoch nicht gelöst.
• Der Index ist austauschbar. Der AppView ist reine Read-Infrastruktur. Das Kernversprechen der Datenhoheit ist damit architektonisch eingelöst.
• Import als Data-Bootstrapping. Der LinkedIn-Import mit anschließendem Vouch-CTA verwandelt kalte Web2-Daten in einen Startpunkt für Web-of-Trust-Interaktionen.

Was jedoch im PoC offen bleibt:

• Das Henne-Ei-Problem. L3-Signaturen brauchen Institutionen (z.B. Universitäten), die mitmachen. Ohne Issuer bleibt das Modell bei L1/L2 stehen — pragmatische Brücken (E-Mail-Domain-Proving, OAuth-Bridging) sind konzipiert, aber nicht implementiert.
• Sybil-Resistenz ist ein Wettrüsten. Das konzipierte Gate (Account-Alter, Aktivität) ist ein Anfang, aber keine finale Lösung.
• UX entscheidet. Die Technik für neue Lösungen ist da und funktioniert; ob Nutzer jedoch den Mehrwert von Datenhoheit, Dezentralität und Unabhängigkeit zu schätzen wissen ist fraglich. Denn Plattformen wie LinkedIn sind vor allem erfolgreich, weil dort so viele Nutzer sind. Ganz klassisch nach dem the rich-get-richer Gravitationsprinzip.

Kernbefund: Nicht die Kryptografie oder die Abbildung besserer Datensouveränität sind die Herausforderungen — sondern die soziale Skalierung von Vertrauens-Infrastrukturen. Das Protokoll kann Verifikation abbilden; ob Menschen sie einfordern, ist eine Design- und Adoptionsfrage.

Ausblick (Roadmap)

• Trust Filters in SearchDirectory (L2/L3 Toggles)
• Rollenbasierte Datenfreigaben (you define who consumes what)
• Recruiter View mit Verified Job Counts
• Institutional Verification (Company DIDs)
• Institutional Directories / Alumni View
• Institutional Certification Flows (~ Zeugnisse, Veröffentlichungen, Weiterbildungen)
• E-Mail-Domain-Proving & OAuth-Bridging als pragmatische Verifikations-Brücken
• Resume Parser als zweite Import-Quelle
• Reputation-Algorithmus für Directory-Ranking
• Verknüpfung mit Realtime-Daten (z.B. Verfügbarkeiten)
• Konzeptuelle Unterscheidung Mensch / Maschine (Agent) erfolgt, Implementierung noch nicht

Anwendungsfälle

• Peer- / Freelancer-Netzwerke / virtuelle Teambildung
• Interoperable HR-Tech Anwendungen (Perks, Weiterentwicklung, HR-Feedback (Leadership) …)
• Klar: Recruitement Anwendungungen
• Klar: Potential für Jobsuche

usw.

Status

PoC mit funktionierender Trust-UI, OAuth-Login, Import-Pipeline und 217 automatisierten Tests. Nicht öffentlich deployed — Launch-Entscheidung steht aus.

Fragen zum Projekt oder zur Architektur: Kontakt .