So ist Calíope gebaut

Eine App, drei Binaries

Calíope wird als eine App ausgeliefert, org.caliope.caliope, mit Universalkauf: ein Kauf deckt jedes Apple-Gerät ab, auf dem sie läuft. Hinter dieser einen App stehen drei Binaries: eines für macOS, eines für iPhone und iPad (dasselbe Binary bedient beide, und die Apple-Watch-App reist darin eingebettet mit) und eines für Apple TV.

Der größte Teil des Codes wird nicht dreimal geschrieben. Sources/Shared enthält 268 Swift-Dateien und 234 SwiftUI-Views, die sowohl ins Mac-Binary als auch ins iOS-Binary kompiliert werden. Die Widgets sind Erweiterungen derselben App und lesen, was die App über eine App Group veröffentlicht; die App schreibt, das Widget liest nur.

SwiftUI von Anfang bis Ende

Jedes Fenster ist natives SwiftUI — keine Web Views, keine plattformübergreifende Emulation. Dieser Satz steht auf der Startseite, und er ist wörtlich wahr: Die 234 geteilten Views sind SwiftUI, und wo sich ein Mac und ein iPad unterschiedlich verhalten müssen, wird der Unterschied beim Kompilieren entschieden, in derselben Datei, nicht in einer Kompatibilitätsschicht zur Laufzeit.

Die Grenze zur Engine

Alles, was mit einer Datenbank-Engine spricht, lebt hinter 15 Protokollen in Sources/Models/Database/Protocols/, eines pro Teilbereich. Jede Engine hat eine Implementierung dieser Protokolle, und nichts oberhalb der Grenze — keine View, kein Orchestrator — schreibt SQL oder kennt die Fehlercodes einer Engine. Eine Engine hinzuzufügen heißt, die Protokolle zu implementieren, nicht die Aufrufer zu ändern.

MySQL und MariaDB laufen über MySQLKit 4.10.1, PostgreSQL über PostgresKit 2.16.1 auf PostgresNIO 1.33.1, alles auf SwiftNIO 2.101.0 (Versionen Stand September 2026). Abfragen mit Parametern verwenden die nativen Prepared-Statement-Bindings von MySQLNIO: Die Werte reisen über das Netzwerkprotokoll und werden nie in das SQL hineinkonkateniert.

SQLite ist anders: Der SQLite-Editor spricht über die C-API mit der Systembibliothek, ohne Treiber dazwischen. MongoDB ist noch einmal anders. Es wird über MongoKitten 7.16.3 unterstützt, einen Community-Treiber, und liegt bewusst außerhalb der Engine-Grenze: Keine View importiert MongoKitten, und die gesamte MongoDB-Schicht ist so entworfen, dass sie entfernt werden könnte, ohne die relationale Seite anzufassen.

SSH ohne ssh

Der SSH-Tunnel ist in der App geschrieben, auf SwiftNIO SSH 0.13.0 und swift-crypto 3.15.1. Keine Abhängigkeit vom ssh des Systems. Entschlüsselte Schlüssel werden nie auf die Platte geschrieben.

Calíope liest private OpenSSH-Schlüssel selbst, akzeptiert ed25519 und ECDSA P-256, P-384 und P-521, prüft den Host-Schlüssel, bevor irgendetwas anderes gesendet wird, und öffnet einen direct-tcpip-Kanal zur Datenbank. Auf deiner Seite lauscht sie auf 127.0.0.1, auf einem Port, der beim Öffnen des Tunnels gewählt wird, und die Datenbankverbindung läuft durch diesen lokalen Proxy. Ein passphrasengeschützter Schlüssel wird im Speicher entschlüsselt, und dort bleibt er.

In der Sandbox

Calíope läuft mit eingeschalteter App Sandbox, wie es der Mac App Store verlangt, und Caliope.entitlements verlangt genau dies:

• com.apple.security.app-sandbox
• com.apple.security.network.client — die ausgehenden Verbindungen zu deinen Servern
• com.apple.security.network.server — die lokalen Listener: der Proxy des Tunnels und der MCP-Server
• com.apple.security.device.audio-input — das Diktat, das auf dem Gerät läuft
• com.apple.security.files.user-selected.read-write — die .sql-Dateien, die du öffnest, und die Ordner, die du für Backups wählst
• com.apple.security.application-groups — der geteilte Container, aus dem die Widgets lesen
• iCloud: CloudDocuments, CloudKit und der Key-Value-Speicher, für die Synchronisierung, die du einschalten kannst

Und was nicht drin ist: kein Zugriff auf das ganze Dateisystem, keine Ausnahme von der Bibliotheksvalidierung, kein JIT.

KI und MCP zu deinen Bedingungen

Der KI-Assistent kennt drei Arten von Anbieter. Apple Intelligence läuft über Apples Framework FoundationModels, auf dem Gerät, ohne Schlüssel und ohne Konto. Ollama läuft auf deinem eigenen Rechner, mit den Modellen, die du dort installiert hast. Die Cloud-Anbieter funktionieren mit deinem eigenen Schlüssel. Wie die App mit einem Anbieter spricht, entscheidet sie nach den Fähigkeiten, die er deklariert, nicht nach seinem Namen. Sie ist ein Assistent, kein Agent.

Der MCP-Server, auf macOS, dreht das um und lässt einen externen KI-Client — Cursor, Claude Desktop, alles, was MCP spricht — Calíope nach deinen Datenbanken fragen, innerhalb von Grenzen. Er ist ab Werk aus. Er lauscht nur auf 127.0.0.1, auf Port 41500, sofern du ihn nicht änderst, und diese Adresse ist nicht konfigurierbar. Jede Anfrage braucht ein Bearer-Token, das Calíope erzeugt (32 zufällige Bytes) und im Schlüsselbund aufbewahrt. Der Client sieht nur die Verbindungen, die du ausdrücklich freigibst, und diese Liste beginnt leer. Er ist nur lesend: eine Anweisung pro Aufruf, geprüft von einem Gate, das auch FOR UPDATE und LOCK IN SHARE MODE ablehnt, und Ergebnisse sind auf 200 Zeilen begrenzt. Fünf Werkzeuge, JSON-RPC 2.0 über eine einzelne Route POST /mcp, Protokollversion 2025-06-18. Keine der beiden Einwilligungen — weder der Schalter noch die freigegebene Liste — wird auf ein anderes Gerät synchronisiert oder reist in einem Einstellungs-Backup mit. Die Seite zum MCP-Server listet die fünf Werkzeuge auf und erklärt, wie man einen Client darauf richtet.

Was sie bewusst nicht tut

• Kein Windows, kein Linux. Calíope ist für die Apple-Plattformen geschrieben und bleibt dort.
• Kein SQL Server, kein Oracle, kein Redis. Die Engines sind MySQL, MariaDB, PostgreSQL, SQLite und MongoDB.
• Keine Team-Arbeitsbereiche. Es gibt keinen Server von uns und keine Konten; deine Profile und dein Verlauf gehören dir, und die iCloud-Synchronisierung ist eine Option zwischen deinen eigenen Geräten.

Wenn du eines dieser drei Dinge brauchst, nennt der Vergleich auf der Startseite die Werkzeuge, die es gut können.