Anbindungen

Google Kalender

Der übliche Weg: einmal bei Google zustimmen, danach aus der Liste den Kalender wählen, in den geschrieben werden soll. Ohne diese Wahl bleibt die Anbindung angefangen - die App schreibt bewusst nicht in den erstbesten Kalender.

Google Kalender (Dienstkonto)

Derselbe Abgleich, aber zentral eingerichtet: der Betreiber hinterlegt ein Roboterkonto, die Band gibt dessen Adresse in ihrem Google-Kalender frei. Umständlicher in der Einrichtung als die einfache Zustimmung - zwei Schritte statt einem, und beide müssen sitzen, siehe das Kapitel Kalender abonnieren.

Beide Wege stehen nebeneinander. Ist die Zustimmung erteilt, gilt sie - ein hinterlegtes Dienstkonto bleibt unangetastet und greift wieder, sobald die Verbindung gelöst wird.

iCloud Kalender

Hängt am eigenen Konto, nicht an der Band: jede Person richtet ihn in den persönlichen Einstellungen selbst ein, mit einem app-spezifischen Passwort - das normale Passwort der Apple-ID funktioniert hier nicht, Apple verlangt für jeden Fremdzugriff auf iCloud ein eigenes.

Erzeugt wird es nicht in dieser App, sondern bei Apple selbst: auf appleid.apple.com anmelden, dort unter „Anmelden & Sicherheit“ den Punkt „App-spezifische Passwörter“ öffnen und eines erzeugen. Die angezeigte Zeichenfolge (vier Vierergruppen, durch Bindestriche getrennt) wird einmalig angezeigt und dann in den persönlichen Einstellungen dieser App eingetragen - zusammen mit der eigenen Apple-ID als Benutzername.

Ohne aktive Zwei-Faktor-Authentifizierung an der Apple-ID bietet Apple diesen Menüpunkt gar nicht erst an - sie ist also Voraussetzung, nicht nur Empfehlung.

CalDAV

Derselbe aktive Abgleich wie bei iCloud, nur mit einem anderen Server: Nextcloud, Posteo, Mailbox.org, Fastmail - alles, was CalDAV spricht. Gebraucht werden die Serveradresse, der Benutzername und ein Passwort.

Die Adresse steht beim Anbieter: in Nextcloud unter den Kalender-Einstellungen bei „CalDAV“ (nicht zu verwechseln mit der WebDAV-Adresse für Dateien, siehe unten - beide sehen ähnlich aus, sind aber verschiedene Pfade auf demselben Server), bei den übrigen in deren Hilfeseiten unter „CalDAV“ oder „Kalendersynchronisation“. Sie muss mit https:// beginnen - CalDAV schickt das Passwort bei jeder Anfrage mit, und nur die verschlüsselte Leitung hält es zusammen.

Verlangt der Anbieter eine Zwei-Faktor-Authentifizierung, braucht auch er ein eigenes App-Passwort statt des gewöhnlichen Kontopassworts - genau wie bei iCloud, nur dass der Weg dorthin je Anbieter anders aussieht (meist unter Sicherheitseinstellungen oder Konto → Verbundene Geräte).

Eingerichtet wird das in den persönlichen Einstellungen, nicht im Bandbereich: der Kalender gehört der Person, nicht der Band. Nach dem Speichern sagt der Knopf „Verbindung testen“ sofort, ob Adresse und Zugangsdaten zusammenpassen, statt es erst beim nächsten Abgleich zu merken.

Kalender-Abo (ICS)

Der anbieterfreie Weg: eine Adresse, die jedes Kalenderprogramm abonnieren kann - Apple, Outlook, Thunderbird, Nextcloud. Nur lesen, dafür ohne Zustimmung und ohne Zugangsdaten. Einzelheiten im Kapitel Kalender abonnieren.

Gmail

Ist das Postfach der Band ein Gmail- oder Workspace-Konto, genügt die Bestätigung bei Google - es müssen keine Server und keine Passwörter eingetragen werden.

IMAP & SMTP

Für jedes andere Postfach: Server, Anschluss und Zugangsdaten von Hand, getrennt für Eingang (IMAP) und Ausgang (SMTP) - auch wenn beide beim selben Anbieter liegen, will die App beide Adressen einzeln wissen. Was die Zugangsdaten taugen, prüft ein eigener Knopf, bevor überhaupt etwas gespeichert wird.

Übliche Anschlussnummern: 993 für IMAP, 587 für SMTP, jeweils mit eingeschalteter Verschlüsselung (SSL/TLS) - das sind die Vorgaben, die die Felder vorschlagen. Nennt die Hilfeseite des Anbieters andere Werte, gelten die.

Ist an dem Postfach eine Zwei-Faktor-Authentifizierung eingeschaltet, verlangt der Anbieter meist ein eigenes App-Passwort statt des gewöhnlichen Kontopassworts - erzeugt wird es dort, in den Sicherheitseinstellungen des Postfachs, nicht in dieser App. Ohne dieses Passwort meldet der Verbindungstest einen Anmeldefehler, obwohl das normale Passwort stimmt.

IMAP und SMTP teilen sich oft, aber nicht immer dieselben Zugangsdaten - manche Anbieter verlangen für den Versand ein zweites, eigenes Passwort. Schlägt nur der SMTP-Teil des Tests fehl, lohnt ein Blick in die Hilfeseite des Anbieters, ob genau das der Fall ist.

Google Drive

Die Dateien der Band in einer Google-Ablage. Verbunden wird wie beim Postfach und beim Kalender - einmal bei Google bestätigen, ohne Zugangsdaten einzutippen.

Gefragt wird dabei nur das Recht auf die Dateien der Anwendung selbst: sie legt einen eigenen Ordner an und sieht danach ausschließlich, was sie dort ablegt. Der übrige Inhalt der Ablage bleibt ihr verborgen.

Es gilt immer nur ein eigener Ablageort. Ist Google Drive verbunden, gehen die Dateien dorthin - auch wenn daneben noch WebDAV-Zugangsdaten stehen. Wer die Verbindung löst, verliert nichts: die abgelegten Dateien bleiben in der Ablage.

Dropbox

Dieselbe Ablage bei Dropbox statt bei Google - für Bands, die dort ohnehin ihre Dateien haben. Verbunden wird genauso: einmal bei Dropbox bestätigen, keine Zugangsdaten eintippen.

Die Anwendung ist als App-Ordner-Anwendung angelegt und bekommt deshalb einen eigenen Ordner in eurer Dropbox, den sie nicht verlassen kann - der übrige Inhalt bleibt ihr verborgen. Gefragt werden nur die Rechte, die sie dafür braucht: Kontoinfo, Metadaten sowie Lesen und Schreiben von Dateien.

Auch hier gilt nur ein Ablageort: Google Drive hat Vorrang, danach Dropbox, danach WebDAV. Solange Drive verbunden ist, bleibt die Dropbox-Kachel deshalb stumm. Wer die Verbindung löst, verliert nichts - die abgelegten Dateien bleiben in der Dropbox.

Der Weg trägt vorerst den Hinweis „Beta – coming soon“: gebaut und geprüft ist er, aber die Anwendung bei Dropbox ist noch nicht für beliebig viele Konten freigegeben.

Nextcloud & WebDAV

Anhänge, Belege und Bilder der Band landen dann in eurem eigenen Speicher statt beim Betreiber. Angebunden wird über WebDAV - das spricht Nextcloud, aber genauso ownCloud, Synology, Seafile oder mailbox.org Drive. Gebraucht werden die Serveradresse, ein Benutzername, ein Passwort und der Ordner, in dem alles liegen soll.

Die Adresse ist der häufigste Stolperstein: es reicht nicht die reine Serveradresse, sondern der vollständige WebDAV-Pfad samt Benutzername, bei Nextcloud etwa https://cloud.example.com/remote.php/dav/files/nutzername - die Startseite der Cloud allein führt zu nichts. Zu finden ist er meist in den eigenen Nextcloud-Einstellungen unter „Auf Dateien zugreifen“ oder in der Hilfe des Anbieters; bei Nextcloud lässt er sich auch aus der eigenen Serveradresse plus /remote.php/dav/files/ und dem eigenen Nextcloud-Benutzernamen zusammensetzen. Sie muss außerdem mit https:// beginnen: WebDAV meldet sich mit Basic Auth an und schickt das Passwort bei jeder Anfrage mit. Einzige Ausnahme ist ein Server auf derselben Maschine (localhost bzw. 127.0.0.1) - dorthin geht nichts über eine Leitung, auf der jemand mithören könnte.

Beim Passwort gilt dieselbe Regel wie beim Kalender: ist an dem Konto eine Zwei-Faktor-Authentifizierung eingeschaltet (bei Nextcloud der Normalfall in vielen Installationen), nimmt man nicht das gewöhnliche Kontopasswort, sondern ein eigenes App-Passwort - unter den persönlichen Nextcloud-Einstellungen bei „Sicherheit“ erzeugt.

Der Knopf „Verbindung prüfen“ sagt auf der Stelle, ob Adresse, Zugangsdaten und Ordner zusammenpassen - und legt den Ordner an, wenn er in der Cloud noch fehlt, statt erst beim ersten Hochladen zu scheitern. Die Meldung dahinter kommt unverändert vom Server - meist ein Hinweis auf eine falsche Adresse oder ein falsches Passwort, manchmal auch nur ein technischer Fehlercode; im Zweifel hilft, die Adresse noch einmal gegen die Nextcloud-Einstellungen zu prüfen.

Was im eigenen Speicher liegt, zählt nicht gegen das Kontingent der Installation. Für Bandlogo, Mitgliederfotos und Website-Dateien gilt das nicht: die liefert die Anwendung selbst aus und legt sie deshalb bei sich ab.

Discord

Ereignisse der Band landen zusätzlich in einem Discord-Kanal. Die Adresse dafür legt Discord selbst an: im Kanal auf Bearbeiten, dann Integrationen, dann Webhooks - die erzeugte Adresse wird im Bandbereich unter Benachrichtigungen hinterlegt.

Je Kanal wird ausgewählt, welche Ereignisse hinausgehen. Ohne Auswahl bleibt er still: ungefragt in einen fremden Chat zu schreiben wäre der schlechtere Fehler.

Wer die Adresse anlegt, braucht auf dem Server das Recht, Webhooks zu verwalten - in einem fremden Server, auf dem man nur Mitglied ist, fehlt der Menüpunkt schlicht. Die erzeugte Adresse ist selbst das Geheimnis: wer sie hat, kann in diesen Kanal schreiben, ohne Mitglied zu sein. Sie gehört deshalb nicht in eine Chatnachricht und nicht in ein öffentliches Repository.

Slack

Derselbe Weg für Slack: dort die App "Incoming Webhooks" hinzufügen, einen Kanal wählen und die erzeugte Adresse hinterlegen.

Slack bindet eine solche Adresse fest an einen Kanal - für einen zweiten Kanal wird eine zweite erzeugt. Das ist kein Umweg, sondern die Absicht dahinter: so entscheidet Slack, wohin geschrieben wird, und diese App nur, was geschrieben wird.

Freier Webhook

Für alles andere: eine eigene HTTPS-Adresse, die JSON per POST annimmt. Anders als Discord und Slack bekommt sie keinen fertigen Satz, sondern die Einzelteile - Band, Ereignisart, Titel, Link und Zeitpunkt. Dahinter sitzt meist eine Automatisierung, die selbst entscheiden will, was sie damit tut.

Die Adresse gilt als Geheimnis und wird verschlüsselt abgelegt; sie lässt sich danach nicht wieder anzeigen, nur ersetzen. Ein Probeversand sagt auf Knopfdruck, ob die Leitung steht.

Claude

Ein Sprachmodell für die Band, mit einem Schlüssel aus der Anthropic Console (API Keys) - unabhängig von einem Claude-Abo. Vorerst nutzt das nur die Belegerkennung: Quittungen und Rechnungen werden beim Buchen ausgelesen, Bezeichnung, Betrag, Datum und Konto stehen als Vorschlag im Formular.

Eingerichtet wird auf einer gemeinsamen Seite für alle drei Anbieter: Anbieter wählen, Schlüssel eintragen, auf Wunsch ein Modell nennen. Es gilt immer nur ein Anbieter; die Schlüssel der anderen bleiben hinterlegt. Tipp: den Schlüssel mit Ausgabenlimit anlegen. Speichern prüft die Verbindung gleich mit - ein Schlüssel, den der Anbieter nicht annimmt, oder ein Modell, das es nicht mehr gibt, wird nicht gespeichert, sondern gemeldet. „Verbindung prüfen“ tut dasselbe ohne zu speichern.

ChatGPT

Dasselbe über OpenAI, mit einem Schlüssel aus dem OpenAI-Dashboard (API keys). Das Formular bekommt dieselben Vorschläge wie bei Claude.

Gemini

Dasselbe über Google, mit einem Schlüssel aus Google AI Studio (API-Schlüssel). Welches Modell liest, lässt sich auf der Einrichtungsseite überschreiben.

REST-API & MCP

Der Zugang für eigene Skripte, Websites und Sprachmodelle. Anders als die übrigen Anbindungen gibt ihn der Betreiber frei; steht er zur Verfügung, legt die Band ihre Zugänge selbst an. Einzelheiten im Kapitel Zugänge, wie ein KI-Assistent angebunden wird im Kapitel KI-Assistenten verbinden.