ATProto in atvoto

Stand: 2026-11-07. Einführung für alle, die ATProto noch nicht kennen. Die Spezifikation steht unter atproto.com.

Das AT Protocol (ATProto) ist das offene Protokoll hinter Bluesky. atvoto nutzt es nicht für Kurznachrichten, sondern als Speicher für die Abstimmungsdebatte. Damit gehören die Beiträge den Personen, sind kryptografisch signiert und für jede Anwendung lesbar.

Grundbegriffe

Begriff	Was es ist	In atvoto
DID	Dauerhafte, globale Kennung eines Kontos, z.B. `did:plc:abc…`. Bleibt gleich, auch wenn Handle oder Server wechseln.	Jede teilnehmende Person und jedes Dossier hat eine. Die AppView selbst hat eine `did:web` (`did:web:api.test.atvoto.ch`).
Handle	Lesbarer Name, ein Domainname, z.B. `anna.test.smartvote.social`. Zeigt auf die DID.	Unter der Domain des Clients. Community-Konten: `dossier-<id>.id.<domain>`.
PDS	Personal Data Server: hostet die Repos der Konten und nimmt Schreibzugriffe an.	Eigener PDS (Bluesky-Software) unter `pds.…`.
Repo	Die signierte Datensammlung eines Kontos. Nur das Konto selbst schreibt hinein.	Beiträge der Person im eigenen Repo; angenommene Kopien im Repo des Community-Kontos.
Record	Ein Datensatz im Repo, z.B. ein Argument.	Typen `ch.atvoto.*`, z.B. `ch.atvoto.dossier.argument`.
Lexicon / NSID	Schema eines Record-Typs oder einer API-Methode, benannt mit einer umgekehrten Domain (NSID).	Schemas in `lexicons/`, beschrieben in Lexicons.
AT-URI	Adresse eines Records: `at://<did>/<collection>/<rkey>`.	So verweisen Kommentare auf Argumente, Gutachten auf Argumente usw.
rkey / CID	rkey = Schlüssel des Records im Repo; CID = Hash einer bestimmten Version.	Die kanonische Kopie hält `originUri` und `originCid` des Originals: Welche Fassung angenommen wurde, ist damit fest.
Firehose	Strom aller Änderungen eines PDS (`com.atproto.sync.subscribeRepos`).	Indexer und Writer lesen ihn und bauen daraus den Index.
Relay	Sammelt die Firehoses vieler PDS (bei Bluesky `bsky.network`).	In prod vorgesehen, in test bewusst nicht angeschlossen (Föderation).
AppView	Liest den Firehose, baut einen Index und beantwortet Abfragen.	Die atvoto-AppView unter `api.…` (API).
Service-Auth	Kurzlebiges JWT, das der PDS einer Person für einen anderen Dienst ausstellt.	So weist sich eine Person gegenüber der AppView aus, ohne dass diese Passwörter oder Sessions kennt.
Label	Signierte Markierung eines Records oder Kontos durch einen Labeler.	Moderation: ausgeblendet wird über Labels (Moderation).

Schreiben und Lesen

Wie überall in ATProto gilt: Geschrieben wird in den PDS, gelesen über die AppView.

              Schreiben                             Lesen
Client ──createRecord──► PDS (Repo der Person)      Client ◄── AppView (api.…)
                            │                                     ▲
                            │ Firehose                            │ Postgres
                            ▼                                     │
                   Indexer + Writer ──────────────────────────────┘
                            │
                            └─► kanonische Kopie im Community-Konto (PDS)

Der Client schreibt mit der Session der Person einen Record in deren Repo.
Indexer und Writer sehen ihn im Firehose. Der Writer prüft Argumente und Gutachten und schreibt die angenommene Kopie ins Community-Konto. Kommentare und Bewertungen prüft der Indexer und übernimmt sie direkt.
Die AppView beantwortet Abfragen aus dem Index: Listen, Zähler, Übersetzungen, Peer-Review-Status.

Weil die Person ihr Repo selbst kontrolliert, kann sie am Client vorbei schreiben. Deshalb sind alle verbindlichen Prüfungen im Store, die Prüfungen im Client sind nur Komfort.

Wer bin ich? Service-Auth

Die AppView kennt keine Logins. Braucht eine Abfrage die Person (z.B. „meine offenen Gutachten“), läuft sie über deren PDS:

Client ──(Access-Token der Person,
          atproto-proxy: did:web:api.test.atvoto.ch#atvoto_appview)──► PDS
PDS    ──(Service-Auth-JWT: iss = DID der Person, aud = AppView, lxm = Methode)──► AppView

Die AppView prüft die Signatur gegen das DID-Dokument der Person. Das Token gilt nur für diese eine Methode und nur kurz. Details: AppView-API.

Warum ATProto?

Datenhoheit: Beiträge liegen im Repo der Person, nicht in einer Datenbank des Betreibers.
Nachprüfbarkeit: Jeder Record ist signiert. Die kanonische Kopie verweist auf das Original samt Hash.
Offenheit: Andere Anwendungen können die Daten lesen und eigene Ansichten bauen. Clients sind austauschbar.
Portabilität: Konten können später zu einem anderen PDS umziehen (Roadmap, Stufe 3).

atvoto und Bluesky

Die Records ch.atvoto.* sind für bsky.app unsichtbar, Bluesky zeigt nur app.bsky.*. Die Verbindung läuft über drei Wege, alle in test ausgeschaltet:

Crosspost: Argumente erscheinen als Bluesky-Post des Community-Kontos.
Poller: Antworten auf Bluesky kommen als externe Kommentare zurück.
Feed: Die AppView ist ein Feed-Generator für alle Crossposts.

Technik: Bluesky-Anbindung, Regeln: VO Interoperabilität.

Anders als bei Bluesky üblich nutzt atvoto für die Moderation nicht Ozone: Der Registrar signiert die Labels, die AppView gibt sie über com.atproto.label.queryLabels öffentlich heraus (Moderation).