LOOM — stories woven
Team-Server · Für die, die LOOM selbst betreiben

LOOM gemeinsam betreiben

Normalerweise läuft LOOM bei dir am Laptop — dann brauchst du diese Seite nicht. Sie ist für den Fall, dass ihr LOOM auf einen gemeinsamen Server stellt, damit das ganze Team im Browser am selben Board arbeitet.

Zuerst das Wichtigste: die Anmeldung ist nicht alles

LOOM hat eine Anmeldung: jedes Teammitglied bekommt einen persönlichen Zugangsschlüssel, ohne den nichts geht (weiter unten steht, wie ihr sie verteilt). Was LOOM nicht hat, ist eine Verschlüsselung eurer Verbindung — und ohne die ist die Anmeldung weniger wert, als sie aussieht.

⚠ Ein Schlüssel über eine unverschlüsselte Verbindung ist mitlesbar

Wenn euer Server ohne HTTPS im Internet steht, wandert der Zugangsschlüssel im Klartext durchs Netz — jeder auf dem Weg dorthin kann ihn abfangen und danach als euer Teammitglied hereinspazieren. Dann steht euer Project Memory offen: eure Namen, eure Entscheidungen, eure ganze Diplomarbeits-Geschichte.

Deshalb sind die zwei folgenden Schritte nicht optional: die Anmeldung schützt wen LOOM hereinlässt, die Verschlüsselung schützt den Schlüssel auf dem Weg dorthin. Ihr braucht beides.

Wie kommt LOOM zu euch?

Es gibt drei Wege, und keiner ist der richtige für alle. Sie unterscheiden sich darin, wer LOOM erreichen kann und wie viel ihr dafür einrichten müsst. Lest die drei Kästen und nehmt den, der zu eurer Lage passt — ihr könnt später jederzeit wechseln.

Die eine Frage, die alles entscheidet: habt ihr eine öffentliche IP?

Nur mit einer öffentlichen IP-Adresse kann jemand von außen zu euch verbinden. Testet es auf der Maschine, die den Server spielen soll:

curl -s https://api.ipify.org; echo

Vergleicht die Ausgabe mit der WAN-Adresse in eurem Router/Modem. Sind sie verschieden — oder beginnt die Router-Adresse mit 100.64. bis 100.127. — dann sitzt ihr hinter dem Provider-NAT: Portfreigabe und DynDNS bleiben wirkungslos, Weg 3 fällt aus.

Wichtig für Mobilfunk (4G/5G): dort ist Provider-NAT der Normalfall — aber kein Schicksal. Bei den österreichischen Anbietern könnt ihr für eure SIM eine öffentliche IP anfordern; danach genügt ein kleiner Router, und Weg 3 steht euch offen. Ein Anruf, kein Umbau.

Weg 1 — Im selben Netz (Schulnetz, WLAN vor Ort)
1
Ihr gebt gar keinen Port frei. LOOM läuft auf einem Rechner im selben Netz, ihr ruft es über dessen lokale Adresse auf. Von außen ist nichts erreichbar — weil nichts nach außen zeigt.
2
Aufwand: keiner. Kein Zertifikat, kein Konto, keine Freigabe. Das funktioniert bei jedem Team, heute.
3
Der Preis: ihr erreicht LOOM nur, wenn ihr im selben Netz seid. Für gemeinsames Arbeiten vor Ort — Casting, Showcase, Loomback — genügt das vollkommen. Von zuhause aus kommt ihr nicht dran.
Weg 2 — Tailscale (ein privates Netz über das Internet)
1
Tailscale verbindet eure Geräte zu einem eigenen, verschlüsselten Netz. Jedes Gerät baut die Verbindung nach außen auf — deshalb funktioniert es auch hinter Provider-NAT, ohne öffentliche IP, ohne Portfreigabe, ohne DynDNS.
2
Aufwand: ein Konto fürs Team, dann eine Installation je Gerät. Auf dem Server tailscale up, auf jedem Laptop dasselbe, einloggen — fertig. Das ist der Unterschied zu Weg 3: die Arbeit fällt bei jedem an, nicht einmalig bei einer Person.
3
Die Verschlüsselung ist eingebaut (WireGuard) — kein Zertifikat, nichts zu erneuern. Und weil kein Port offen steht, gibt es von außen nichts anzugreifen.
4
Der Preis: nur Geräte in eurem Tailscale-Netz kommen an LOOM — wer kurz etwas herzeigen will, muss den Gast erst aufnehmen. Und es ist ein Dienst einer Firma: ihr braucht Konten, und die Verbindungsvermittlung läuft über deren Server (eure Inhalte nicht).
Weg 3 — Reverse Proxy (LOOM steht im Internet)
1
Voraussetzung: eine öffentliche IP (siehe Kasten oben) und ein Name, unter dem man euch findet — eine Subdomain oder DynDNS.
2
Aufwand: am meisten — Portfreigabe, Proxy einrichten, Passwort setzen, Zertifikat (Caddy holt es automatisch). Dafür einmalig bei einer Person, danach müssen die anderen nichts installieren.
3
Der Gewinn: jede:r mit dem Link und dem Passwort kommt hinein — auch euer Coach, auch vom Handy, auch ohne Vorbereitung. Das ist der einzige Weg, der das kann.
4
Der Preis: euer Server steht im offenen Internet. Lest die Regeln unten bevor ihr freischaltet — sie sind kurz und sie sind wichtig.

Kurz zum Selbst-Einordnen

Ihr arbeitet ohnehin meist gemeinsam vor Ort? → Weg 1, fangt heute an. · Ihr wollt von zuhause dran und habt keine öffentliche IP? → Weg 2. · Ihr betreibt eine eigene VM oder einen Server und wollt, dass Außenstehende ohne Installation zugreifen können? → Weg 3.

Ehrlich dazu: Weg 2 haben wir selbst noch nicht im Schulbetrieb erprobt, und wie viele Geräte der kostenlose Tailscale-Tarif erlaubt, solltet ihr vor der Entscheidung nachsehen. Wenn ihr Erfahrungen macht — gute wie schlechte — sagt uns Bescheid.

Die zwei Regeln

Diese Regeln gelten für Weg 3. Bei Weg 1 und 2 verlässt euer Zugangsschlüssel das eigene Netz nie unverschlüsselt — dort seid ihr ohne Zutun auf der sicheren Seite.

Regel 1 — LOOM selbst bleibt auf localhost
1
LOOM lauscht von sich aus nur auf dem eigenen Rechner (localhost). Das ist Absicht und euer wichtigster Schutz.
2
Setzt nicht --urls oder ASPNETCORE_URLS auf 0.0.0.0, um LOOM „ins Netz zu stellen". Genau das hebelt den Schutz aus — dann hängt LOOM unverschlüsselt im Internet, und euer Zugangsschlüssel ist auf dem Weg dorthin mitlesbar.
Regel 2 — davor kommt ein Reverse Proxy mit Passwort und Verschlüsselung
1
Ein Reverse Proxy ist ein kleines Programm, das die Anfragen aus dem Netz entgegennimmt, ein Passwort verlangt und sie erst dann an das LOOM auf localhost weiterreicht.
2
Er erledigt gleichzeitig die Verschlüsselung (HTTPS). Ohne die wandern Passwort und Inhalte im Klartext durchs Netz — jeder auf dem Weg kann mitlesen.
3
Caddy ist dafür die einfachste Wahl: es holt das Zertifikat automatisch. Die Konfiguration passt in fünf Zeilen.
Caddyfile — Passwort und HTTPS in fünf Zeilen
loom.eure-schule.at {
    basic_auth {
        team <hier der Passwort-Hash>
    }
    reverse_proxy localhost:5311
}

Den Passwort-Hash erzeugen

Mit caddy hash-password — Caddy fragt nach dem Passwort und gibt den Hash aus, den ihr oben einsetzt. Das Passwort selbst steht nie in der Datei.

Wenn euch das zu viel ist — das ist völlig in Ordnung

Ihr müsst diesen Weg nicht gehen. Weg 1 und Weg 2 oben brauchen keine Portfreigabe, kein Zertifikat und keines dieser Regelwerke — und ihr könnt jederzeit später umsteigen. Ein Team, das mit Weg 1 anfängt und arbeitet, ist besser dran als eines, das an Weg 3 hängen bleibt.

Bevor ihr anfangt

Ein Team-Server nimmt euch die gemeinsame Ablage ab — nicht die KI. Die braucht auf jedem Gerät etwa 16 GB Arbeitsspeicher und ein installiertes Ollama ↗, genau wie beim Arbeiten am eigenen Laptop. Wer das nicht hat, kann LOOM voll benutzen, nur eben ohne die KI-Hilfen.

Das richtige Paket für eure Maschine

LOOM wird als fertiges Paket ausgeliefert — ihr braucht kein installiertes .NET. Aber das Paket muss zu eurer Maschine passen, und zwar in zwei Hinsichten: Betriebssystem und Prozessor-Architektur. Ein Paket für einen normalen PC läuft auf einem Raspberry Pi gar nicht, da hilft auch kein Nachhelfen.

Fangt beim Betriebssystem an — der Rechner, der den Server spielen soll, ist meistens der, den sowieso jemand herumstehen hat:

macOS
Ein Mac (auch ein MacBook) kann euer Team-Server sein → loom-<version>-osx-arm64.zip. Darin liegt LOOM.app zum Doppelklicken. Gilt für alle Macs mit Apple-Chip (M1 und neuer); für die alten Intel-Macs gibt es derzeit kein Paket. Beim ersten Öffnen meldet sich die Gatekeeper-Warnung — die Schritte stehen in OPEN-ON-MAC.txt im Paket.
Windows
→ LOOM-Setup-<version>.exe (Installer) oder loom-<version>-win-x64.zip, wenn ihr nichts installieren wollt.
Linux / Raspberry Pi
Hier entscheidet zusätzlich die Architektur — siehe direkt darunter.

Nur für Linux: welche Architektur habt ihr?

Auf der Maschine, die den Server spielen soll, im Terminal:

uname -m

Die Antwort sagt euch das Paket:

aarch64
Raspberry Pi 4/5 und andere ARM-Rechner → loom-<version>-linux-arm64.zip oder LOOM-<version>-aarch64.AppImage
x86_64
normaler PC oder Server → loom-<version>-linux-x64.zip oder LOOM-<version>-x86_64.AppImage
armv7l
32-Bit-Raspberry-Pi-OS — dafür gibt es derzeit kein Paket. Installiert das 64-Bit-Raspberry-Pi-OS neu (Standard seit 2022) und sagt uns Bescheid.

Warum die Reihenfolge so ist: uname -m antwortet auf einem Mac mit arm64 und unter Windows gar nicht — wer mit diesem Befehl anfängt, findet seine Ausgabe in der Liste oben nicht wieder. Deshalb zuerst das System, dann die Architektur.

⚠ Ehrlich gesagt: auf einem echten Pi haben wir es noch nicht laufen sehen

Das ARM-Paket ist gebaut und wurde in einer echten ARM-Linux-Umgebung gestartet — LOOM antwortet dort, die Hilfe-Seiten werden ausgeliefert, im Start-Protokoll steht kein Fehler. Was nicht geprüft ist: euer Pi mit eurem Betriebssystem-Abbild, und ob seine Leistung im Alltag reicht. Ihr seid die Ersten. Wenn etwas klemmt, ist das ein Befund und kein Anwenderfehler — sagt Bescheid, wir wollen es genau wissen.

LOOM in den Team-Modus schalten

LOOM kennt zwei Betriebsarten. Am eigenen Laptop läuft es im Modus local — da darfst du alles. Auf einem Team-Server stellt ihr hosted ein.

Die Einstellung steht in der Datei app-settings.yaml auf der Maschine, auf der LOOM läuft:

macOS
~/Library/Application Support/LOOM/app-settings.yaml
Windows
%APPDATA%\LOOM\app-settings.yaml
Linux
~/.config/LOOM/app-settings.yaml
app-settings.yaml
port: 5311
mode: hosted

Danach LOOM neu starten. Den aktiven Modus seht ihr jederzeit in LOOM unter Settings → App; ändern lässt er sich dort bewusst nicht — dafür muss man an die Maschine.

Wer darf den Modus ändern?

Wer die Datei bearbeiten kann. LOOM hat dafür keine eigene Rolle — wer Zugriff auf den Server hat, betreibt ihn. Das ist keine Lücke, sondern Absicht: eine Berechtigung weniger, die falsch stehen kann.

Zugangsschlüssel verteilen

Jedes Teammitglied bekommt einen eigenen Zugangsschlüssel (Token). Damit meldet es sich am Team-Server an — LOOM weiß dann, wer etwas geworfen hat. Es gibt bewusst keine Benutzerkonten und keine Passwörter: ein Schlüssel pro Person, mehr braucht ein DA-Team nicht.

⚠ Reihenfolge beachten — sonst sperrt ihr euch aus

Die Schlüssel werden im lokalen Modus erzeugt, bevor ihr auf hosted umstellt. Sonst braucht ihr zum Anmelden einen Schlüssel, den ihr nur im angemeldeten Zustand erzeugen könntet.

So richtet ihr es ein
1
LOOM auf dem Server starten, solange mode noch auf local steht (oder die Zeile fehlt).
2
Settings → App → Team access: für jedes Mitglied auf Create token klicken. Der Schlüssel erscheint genau einmal — kopieren und der Person geben (persönlich, nicht in den Gruppenchat).
3
mode: hosted setzen und LOOM neu starten. Ab jetzt fragt LOOM beim Öffnen nach dem Schlüssel.
4
Danach kann nur noch die Person Schlüssel verwalten, die im Setup als Maintainer eingetragen ist.

Schlüssel verloren?

Einfach einen neuen erzeugen — der alte hört im selben Moment auf zu funktionieren. Es gibt kein „Passwort vergessen", weil es kein Passwort gibt.

Wo die Schlüssel liegen

Neben app-settings.yaml auf der Maschine, und zwar nur als Prüfsumme — der Schlüssel selbst steht nirgends. Er landet nie in eurem Projekt-Ordner, denn der liegt in Git und wäre damit in jedem Klon.

Was sich im Team-Modus ändert

Board ist festgelegt

Der Vault-Umschalter oben links ist weg. Sonst würde ein Klick von einer Person allen anderen das Board unter den Füßen wegziehen.

Kein Ausschalten

Der Beenden-Knopf ist weg. Auf einem gemeinsamen Server würde er den Dienst für alle stoppen.

Die KI läuft bei dir

Am Team-Server hat die KI keine zentrale Adresse mehr. Jede:r von euch braucht Ollama auf dem eigenen Gerät — dort läuft eure KI, egal ob ihr in der Schule sitzt oder zuhause. Der Server selbst braucht kein Ollama; auf einem Raspberry Pi könnte es ohnehin nicht laufen. Auch das Modell wählt jede:r für sich.

Alles andere bleibt wie gewohnt: Stories, Flocks, Beacons, Casting, Loomback — der ganze Rhythmus funktioniert unverändert.

Zwei Stolpersteine

Live-Aktualisierung braucht Durchlass

LOOM hält eine offene Verbindung nach /api/events, um Änderungen zu melden. Manche Reverse Proxys puffern solche Verbindungen und halten sie zurück. Bei Caddy funktioniert es out of the box; bei nginx braucht es proxy_buffering off; und eine großzügige proxy_read_timeout.

Ollama muss LOOM hereinlassen

Euer Ollama nimmt standardmäßig nur Anfragen vom eigenen Rechner an — LOOM kommt aber vom Server. Einmalig erlauben: OLLAMA_ORIGINS. LOOM sagt es euch selbst, wenn es klemmt, samt der Zeile für euer System. Achtung auf dem Mac: die Einstellung greift erst, wenn Ollama danach komplett beendet und neu gestartet wird — ein laufendes Ollama übernimmt sie nicht, und nichts weist darauf hin.

LOOM · Team-Server
Iron-Labs · Diese Seite beschreibt den Stand v1.1. LOOM hat eine eigene Anmeldung — trotzdem gilt ohne Ausnahme: euer Zugangsschlüssel darf nie unverschlüsselt durchs Netz. Welchen der drei Wege ihr dafür nehmt, ist eure Entscheidung.