atvoto
atvoto ist ein neutraler ATProto-Store für Abstimmungsdebatten: PDS, Indexer, Writer (Annahmeschleuse, Übersetzungen, Embeddings), AppView (öffentliche Lese-API) und Registrar (Admin-API für Clients). Clients wie smartinfo setzen darauf auf. Sie übernehmen Login, Teilnehmer-Verwaltung und Redaktion. Architektur: ARCHITECTURE_SPLIT.md.
Einstieg: Was ist atvoto? (Zweck und Begriffe), ATProto in atvoto (für Neulinge), AppView-API (Lese-API für Clients), ROADMAP.md (was offen ist). Online: https://docs.test.atvoto.ch.
Endpunkte (test)
Abschnitt betitelt „Endpunkte (test)“Eine eigene Weboberfläche hat atvoto nicht. Die Oberfläche für Teilnehmende betreibt der Client (smartinfo). prod: noch kein Overlay.
Öffentlich (Ingresses in deploy/overlays/test/):
| Host | Dienst | Inhalt |
|---|---|---|
https://api.test.atvoto.ch |
AppView | Lese-API /xrpc/ch.atvoto.*, Bluesky-kompatibel /xrpc/app.bsky.feed.* und app.bsky.actor.*, /xrpc/com.atproto.label.queryLabels, /.well-known/did.json, /healthz |
https://pds.test.atvoto.ch, https://*.test.smartvote.social |
PDS | ATProto-PDS-API (com.atproto.*), Handle-Auflösung, /xrpc/_health. Gesperrt: /xrpc/com.atproto.admin.*, createInviteCode |
https://registrar.test.atvoto.ch |
Registrar | nur /xrpc/ch.atvoto.registrar.* (Bearer-Client-Key, Rate-Limit, Body-Limit). Alles andere 404, auch /healthz |
Geschrieben wird in den PDS, gelesen über die AppView, verwaltet über den Registrar. Schemas: LEXICONS.md.
Aufrufe aus dem Client (ARCHITECTURE_SPLIT.md §5.2):
- Öffentlich lesen: direkt an
api.…. - Mit Bezug auf die Person (
dossier.getPermissions,quota.get,peerreview.*,activity.markSeen…): an den PDS mit dem Access-Token der Person und dem Headeratproto-proxy: did:web:api.test.atvoto.ch#atvoto_appview. Der PDS leitet mit einem Service-Auth-JWT (aud= AppView,lxm= Methode) an die AppView weiter. - Schreiben: Record ins Repo der Person (
com.atproto.repo.createRecord), ohne Weiterleitung. Indexer und Writer holen ihn über die Firehose. - Registrar: direkt mit dem Client-Key, kein Proxy.
Registrar-API für Clients: https://registrar.test.atvoto.ch/xrpc/ch.atvoto.registrar.<Methode>,
Header Authorization: Bearer <Client-Key>. Alles bezieht sich auf den aufrufenden
Client (seine Mitglieder, Vorlagen, Regeln). Parameter und Details:
ARCHITECTURE_SPLIT.md §5.1, Einrichtung:
NEW_CLIENT.md, Code:
services/writer/src/registrar/main.py.
| Methode | HTTP | Zweck |
|---|---|---|
createAccount |
POST | PDS-Konto + Profil + App-Passwort, Mitgliedschaft → {did, handle, appPassword} |
updateParticipant |
POST | Prüfstufe (assurance) eines eigenen Mitglieds ändern |
revokeParticipant |
POST | eigene Mitgliedschaft widerrufen |
getParticipationPolicy / setParticipationPolicy |
GET / POST | Teilnahmeregeln der eigenen Vorlagen |
getPeerReviewSettings / setPeerReviewSettings |
GET / POST | Peer Review ein/aus, Quorum |
createDossier |
POST | Vorlage mit Community-Konto anlegen (Phase draft) |
updateDossier / getDossier |
POST / GET | Metadaten, Phase (draft, open, paused, closed, withdrawn) |
putOfficialArgument / deleteOfficialArgument |
POST | offizielle Argumente direkt ins Community-Repo |
taxonomy.publishSnapshot |
POST | Themenbaum des Clients als Snapshot ins Community-Repo veröffentlichen |
taxonomy.getSnapshot |
GET | Letzten Snapshot lesen (?dossier=) |
Nur im Cluster:
| Dienst | Adresse | Endpunkte |
|---|---|---|
| indexer | Port 3001 | /health, /backfill |
| registrar | http://registrar:3000 |
/healthz |
| writer | http://writer |
/healthz, /internal/embed (für die AppView) |
| postgres | postgres:5432 |
– |
Monitoring: nur Health-Endpunkte (Liveness- und Readiness-Probes). Von aussen
prüfbar: api.test.atvoto.ch/healthz, pds.test.atvoto.ch/xrpc/_health. Kein
/metrics, kein Prometheus/Grafana, kein Alerting. Den Writer sieht man nur über
Pod-Status und Logs.
| Dokument | Inhalt |
|---|---|
| VERFASSUNG.md | Regeln der Plattform: Rechte, Rollen, Peer Review, Verbote (Entwurf) |
| VO_INTEROPERABILITAET.md | Verordnung zur Bluesky-Anbindung: Spiegelung, externe Antworten, Likes (Entwurf) |
| VO_KONTEN_TEILNAHME.md | Verordnung über Konten, Prüfstufe und Teilnahmeregeln (Entwurf) |
| VO_MODERATION.md | Verordnung über die Moderation: Werte, Meldungen, Verfahren, Einspruch (Entwurf) |
| NUTZUNGSBEDINGUNGEN.md | Eckpunkte für die Nutzungsbedingungen: Lizenz der Beiträge, Löschung, Föderation, KI (Sammlung) |
Betrieb — doc/betrieb/
Abschnitt betitelt „Betrieb — doc/betrieb/“| Dokument | Inhalt |
|---|---|
| RUNBOOK.md | Aufbau einer Umgebung von null, Schritt für Schritt |
| RUNBOOK_VERLAUF.md | Was beim Aufbau gemacht, getestet und entschieden wurde (keine Anleitung) |
| COMMANDS.md | Befehlsreferenz: kubectl, psql, Registrar, Secrets, goat |
| NEW_CLIENT.md | Neuen Client (z.B. smartinfo) einrichten, Key rotieren, sperren |
| GITHUB_DEPLOYMENT.md | Branch main, Test automatisch per GitHub Actions, Ablauf für prod |
| PRODUCTION_DEPLOYMENT.md | Cluster-Wahl und Prioritäten für prod |
| FEDERATION.md | PDS mit dem Bluesky-Relay föderieren, Throttling, Reset/Restore (nur prod) |
Architektur — doc/architektur/
Abschnitt betitelt „Architektur — doc/architektur/“| Dokument | Inhalt |
|---|---|
| ARCHITECTURE_SPLIT.md | Trennung Store (atvoto) ↔ Client, Services, Schnittstellen, Umgebungen |
| LEXICONS.md | Record-Schemas ch.atvoto.*, Veröffentlichung, Weiterentwicklung |
| ROADMAP.md | Wie föderal ist atvoto? Mitgliedschaft, Teilnahmeregeln pro Client, Stufen 0–3 und eID (Konzept) |
| ACCOUNT_DELETION.md | Löschung eines Kontos: was verschwindet, was bleibt, Indexer, offene Fragen (Konzept) |
| MODERATION.md | Funktionsumfang, Datenmodell, Labels, Sperre beim Login, Testbedarf (Konzept) |
| THIRD_PARTY_PDS.md | Teilnehmer mit fremdem PDS / OAuth, technische Details zu Stufe 1 (Konzept) |
| INTEROPERABILITY.md | Bluesky-Anbindung, technische Umsetzung: Crosspost, Poller, Feed-Generator |
| RECORD_TRANSLATIONS.md | Mehrsprachige Records: Modell, Worker, Konfiguration |
| DB_ROLES.md | DB-Rollen der Dienste: welche Rolle welche Tabelle/Spalte lesen und ändern darf, mit Begründung |
Participation — doc/participation/
Abschnitt betitelt „Participation — doc/participation/“| Dokument | Inhalt |
|---|---|
| ARGUMENT_CRITERIA.md | Die fünf Kriterien für neue Argumente (Vorprüfung + Peer Review) |
| PEER_REVIEW.md | Peer-Review-Mechanismus: Einladung, Abschluss, Betrieb |
| DUPLICATE_CHECK.md | Duplikat-Hinweis beim Verfassen (Embeddings) |
| LM_PEER_REVIEW.md | Historischer Plan: Embeddings als Grundlage für Duplikat-Check und semantische Suche |
atvoto (Store) und der Client (smartinfo) sind zwei eigene Projekte; beide sind aus poltr hervorgegangen. poltr wird nur noch dort erwähnt, wo es um die Migration und die Herkunft von Code geht. Client-Dokumentation (Frontend-Design, UI-Übersetzungen, Aggregation, Auth) liegt im Client-Projekt.
| Teil | Lizenz |
|---|---|
| Code und alles Übrige, sofern nicht unten genannt | AGPL-3.0-or-later |
lexicons/ |
MIT |
doc/ |
CC BY 4.0 |
Copyright © 2026 Dominik Wyss. Inhalte von Teilnehmenden (Argumente, Kommentare) fallen nicht unter diese Lizenzen.