Eigener Android-Store: F-Droid-Repo + Direkt-APK
Die Recherche zum App-Vertrieb hat die Richtung gesetzt: Auf Android bauen wir das souveräne Rückgrat selbst — ein selbst gehostetes F-Droid-Repo plus signierte Direkt-APK, an Google vorbei, in jedem Land nutzbar (auch der Schweiz). Bestehende Kanäle bleiben Reichweiten-Verstärker, die PWA der Default. Hier steht der Weg dorthin.
Schritte
Was als Nächstes ansteht
- Pilot-App festlegen (eine bereits FOSS-reife Android-App) und einen reproduzierbaren, deterministischen Release-Build aus dem Quellcode aufsetzen.
- `fdroidserver` auf mana-server aufsetzen, Repo unter `fdroid.mana.how/fdroid/repo/` hosten — Signing-Key getrennt vom Webserver, über den Secrets-Standard (SOPS/age) verwahrt.
- Direkt-APK-Download plus Ein-Klick-„Repo hinzufügen"-Anleitung auf der jeweiligen App-Landing.
- Obtainium-Source aus den GitHub-Releases als Null-Infrastruktur-Zweitweg ergänzen (zieht Updates ohne eigenes Hosting).
- Nach ein bis zwei Apps Installations- und Update-Zahlen messen → bewusstes Go/No-Go für den Flotten-Rollout.
Offene Punkte
Was uns aufhält, was wir noch nicht entschieden haben
Die ehrliche Seite: wenn etwas nicht weiterkommt, liegt es meist an einer der hier gelisteten Abhängigkeiten oder offenen Fragen.
Hängt ab von
- Reproducible-Build-Disziplin pro App (deterministischer CI-Build aus dem Quellcode) — Voraussetzung für ein vertrauenswürdiges Repo.
- Signing-Key-Verwahrung über den Secrets-Standard (SOPS/age) plus getrennter Build-/Publish-Host. Geht der Schlüssel verloren, brechen alle Update-Pfade.
- Subdomain + Cloudflared-Route (`fdroid.mana.how`) und ein Repo-Container auf mana-server.
Offene Fragen
- Rechtfertigt die Android-Reichweite den Pflegeaufwand, oder bleibt die PWA der bessere Default? Erst messen, dann Flotte.
- Eigenes Repo allein — oder zusätzlich ins F-Droid-Hauptrepo (mehr Sichtbarkeit gegen Review-Zeit und ein Stück Kontrollverlust)?
- Wie nehmen wir Nutzer:innen die „aus unbekannter Quelle"-Hürde beim Onboarding, ohne in Sicherheits-Theater zu verfallen?
- Welche Apps zuerst — und welche bleiben bewusst PWA-only?
Anker
Wohin das im Verein zeigt
- Inframana-serverDer Hauptserver des Vereins — ein Mac mini M4 in Tägerwilen (Schweiz), der die ganze Plattform trägt.
- LösungEigener App-Store — Android-Vertrieb in eigener HandAuf Android war der Vertrieb nie verschlossen — also betreiben wir ihn selbst, an Google vorbei, ohne Gatekeeper und ohne Gebühr.
Belege
Wo dieses Vorhaben in der Doku oder im Code lebt
○ Später
Weitere Vorhaben im selben Horizont
Entschieden, aber ohne festen Termin.
- Stiftungs-Umwandlung — sobald die Plattform finanziell trägtDer Verein ist als Schweizer Verein konstituiert; die langfristige Rechtsform ist eine Stiftung, weil sie Eigentum endgültig dem Verein bindet und keinen Verkauf zulässt. Schritt entscheidend für „unverkäuflich" — aber nur dann, wenn die laufenden Kosten dauerhaft gedeckt sind.
- SEPA-Lastschrift direkt — Stripe als bewusste Externe ablösenStripe ist heute eine der drei bewusst akzeptierten externen Stellen. Der Ablöse-Pfad steht in der Landing-Sektion „Bewusste Externe": SEPA-Lastschrift direkt, ohne Payment-Provider zwischen Verein und Mitglied.
- On-Device-LLM für alle Apps — Anthropic/OpenAI/Gemini ablösenDie LLM-APIs (Anthropic, OpenAI, Gemini) sind heute die dritte bewusst akzeptierte Externe. Ablöse-Pfad: lokale Modelle, gestaffelt — Gemma/Mistral auf dem Gerät via mana-swift-llm, größere Modelle auf der eigenen GPU-Box.
- Web-Push (VAPID) — APNs/FCM für PWAs ablösenAPNs und FCM sind die zweite bewusste Externe. Für PWAs (unsere Android- Primärlinie) lässt sich der Push-Channel mit Web-Push + VAPID direkt aus dem Server bedienen, ohne Apple oder Google im Pfad.
Vorhaben sind die vorwärts-gerichtete Schwester des Devlogs. Erledigtes wandert in die passende Kalenderwoche, damit hier nur das steht, was wirklich noch ansteht.