Magma ist im Urlaub entstanden. Italien, MacBook auf dem Tisch, eigentlich hatte ich anderes vor. Ich wollte keine Notiz-App bauen, ich wollte nur endlich eine haben, die zwei Dinge gleichzeitig kann: meine Notizen als schlichte Markdown-Dateien auf meiner eigenen Platte liegen lassen und Claude ordentlich mitschreiben lassen. Ich habe eine Weile gesucht und dann angefangen zu tippen.
Vier Releases später, gestern kam v0.1.3, ist daraus ein Projekt geworden, an dem jemand mitarbeitet, den ich nie getroffen habe, und in dem ein Fremder ein Problem gefunden hat, das ich selbst nie bemerkt hätte.
Das ist der Teil an einem Devblog, den ich nicht weglassen will. Ein Changelog zeigt, was funktioniert. Ein Devblog zeigt, was ich übersehen habe, bis mich jemand daraufgestoßen hat.
Hier ist der Stand heute: was Magma überhaupt ist, was in v0.1.3 steckt, welches Problem im MCP-Server aufgetaucht ist, und woran ich gerade tatsächlich schraube.
Was ist Magma?
Magma ist eine Notiz-App für macOS und Windows. Open Source unter MIT-Lizenz, kein Account, kein Abo, keine Telemetrie.
Die Grundidee kennst du, wenn du Obsidian kennst: Deine Notizen sind ganz normale Markdown-Dateien in einem Ordner auf deiner Platte. Du verbindest sie mit [[wikilinks]], siehst zu jeder Notiz die Rückverweise, und ein Graph zeigt dir, wie dein Wissen zusammenhängt. Wenn du Magma morgen löschst, bleiben deine Dateien liegen und lassen sich mit jedem Texteditor weiterbearbeiten. Einen bestehenden Obsidian-Vault öffnest du direkt, ohne Import.
Der Unterschied steckt im zweiten Autor. Magma bringt einen MCP-Server mit, über den Claude deinen Vault lesen und beschreiben kann. Nicht als Chatfenster am Rand, sondern als Schreibzugriff auf dieselben Dateien, in denen du selbst arbeitest. MCP ist kurz gesagt ein Protokoll, über das ein Sprachmodell Werkzeuge auf deinem Rechner benutzen darf. In diesem Fall Werkzeuge, die deine Notizen suchen, lesen, anlegen und verknüpfen.
Genau das ist der Punkt, an dem die meisten zurecht misstrauisch werden. Deshalb prüft Magma jeden [[link]], den ein Modell schreiben will, gegen den echten Bestand, statt tote Verweise entstehen zu lassen. KI-geschriebene Notizen bekommen author: ai in die Frontmatter, erscheinen violett im Graph und stehen gesammelt auf einer eigenen Seite. Vor jedem KI-Schreibzugriff sichert Magma einen Versionsstand.
Was steckt in v0.1.3?
Zwei Dinge, beide in Pull Request 19.
Schnappschuss vor jedem KI-Schreibzugriff. Bisher hat Magma vor größeren Änderungen und vor jedem vaultweiten Ersetzen eine Version gesichert. Jetzt greift dieselbe Mechanik, sobald Claude über den MCP-Server schreibt, egal wie klein der Eingriff ist. Der Gedanke dahinter ist simpel: Ich merke sofort, wenn ich selbst etwas kaputt mache. Bei einem Modell merke ich es unter Umständen erst drei Tage später, wenn ich die Notiz wieder aufmache. Dann brauche ich einen Stand von vorher, nicht eine Erklärung.
Umlaute in Notiznamen. Notizen wie Bürokratie.md oder Übersicht Projekte.md haben sich in v0.1.2 nicht sauber verhalten. In einer App, die ein deutschsprachiger Entwickler für den eigenen deutschsprachigen Vault gebaut hat. Behoben. Den technischen Hergang lasse ich hier bewusst offen, weil ich ihn ohne den Commit vor mir nicht sauber wiedergeben kann, und einen halb erinnerten Bugfix nachzuerzählen bringt niemandem etwas.
Was mich daran mehr beschäftigt als der Bug selbst: Meine eigenen Testnotizen tragen fast alle englische Titel, weil der Code englisch ist und ich beim Entwickeln in dem Kontext bleibe. Der Fehler saß in der Lücke zwischen der Sprache, in der ich baue, und der Sprache, in der ich schreibe.
Warum mir ein fremdes Issue mehr bringt als sieben Stars
Am 7. August hat bo-developing Issue 18 aufgemacht. Titel, sinngemäß: Es gibt keinen Vault-Index, jeder MCP-Schreibvorgang kostet ungefähr drei komplette Vault-Durchläufe. Frage dahinter: Wie verhält sich das bei mehreren tausend Notizen?
Die ehrliche Antwort ist, dass ich es nicht weiß. Mein Vault ist ein persönlicher Vault. Der Graph baut sich in Millisekunden auf, die Suche fühlt sich sofort an, find_link_candidates liefert ohne spürbare Wartezeit. Bei meiner Größenordnung fällt ein linearer Durchlauf schlicht nicht auf.
Das ist der klassische Blindfleck beim Bauen für sich selbst. Ich habe die Vault-Logik in magma-core gekapselt und unit-getestet, damit Desktop-App und MCP-Server garantiert dasselbe Modell meiner Notizen sehen. Über das Laufzeitverhalten sagt diese Architektur nichts. Sauber getrennt und trotzdem dreimal zu viel gelesen, das schließt sich nicht aus.
Was mir das Issue konkret gebracht hat: eine Messgröße, die ich vorher nicht hatte, und die Erkenntnis, dass ich einen synthetischen Vault mit ein paar tausend Notizen brauche, bevor ich irgendetwas optimiere. Erst messen, dann cachen. Ein Index, den ich baue, ohne die Kosten zu kennen, ist nur eine zweite Datenquelle, die falsch werden kann.
Sieben Stars sind nett. Ein Issue, das eine Annahme in meinem Kopf zerlegt, ist unbezahlbar.
Woran ich gerade arbeite
Drei offene Pull Requests, Stand jetzt.
alexandermut hat in Nummer 15 einen In-App-Updater beigesteuert. Er hat schon in v0.1.2 den Großteil der eingegangenen Änderungen geliefert, was die Beschreibung „Ein-Personen-Projekt“ inzwischen ungenau macht. Ich habe seinen Stand in Nummer 21 auf v0.1.3 rebased, weil der Unterbau sich seither bewegt hat und ich ihm keinen Merge-Konflikt zumuten will, den ich selbst verursacht habe.
Nummer 22 ist mein eigener Entwurf für den Remote-Vault: Ordner einzeln durchgehen, statt den kompletten Baum in einem Rutsch beim WebDAV-Server anzufragen. Auf einem lokalen Testserver ist der Unterschied kaum messbar. Auf einer echten Verbindung mit Latenz und Timeouts ist es der Unterschied zwischen „Sync läuft“ und „Sync hängt“.
Dazu Issue 20, das ich heute selbst geöffnet habe: Ein Vault soll seine eigenen Schreibkonventionen tragen und sie dem Modell mitgeben können. Ordnerstruktur, Namensschema, Frontmatter-Felder, Sprache. Aktuell schreibt Claude in meinem Vault ordentlich, weil ich es ihm in jedem Chat neu sage. Das ist keine Lösung, das ist eine Gewohnheit. Die Regeln gehören in den Vault, nicht in meinen Kurzzeitspeicher.
Was offen ist und mich stört
Die Installer sind nach wie vor nicht signiert. macOS meldet einen unbekannten Entwickler, Windows wirft SmartScreen. Beides mit zwei Klicks zu umgehen, beides trotzdem eine Hürde, die genau die Leute abschreckt, denen ich Datenkontrolle verspreche. Code Signing steht in Meilenstein M5 offen. Auto-Update hängt daran mit dran, weil ein Updater ohne Signatur nur den nächsten unsignierten Build nachlädt.
Das WebDAV-Passwort lebt in der Session. Nach dem Neustart wieder eintippen. Speicherung im Schlüsselbund des Betriebssystems ist geplant, nicht gebaut.
Ähnliche Notizen sind lexikalisch, nicht semantisch. TF-IDF über den Vault, verglichen per Kosinus. Das findet Notizen mit denselben Wörtern, nicht Notizen mit derselben Bedeutung. Ich nenne das im README bewusst so, weil der Unterschied bei einer Funktion namens „ähnliche Notizen“ nicht in die Fußnote gehört. Der Vorteil: kein Modell-Download, keine Laufzeit, kein Netz.
Was du tun kannst
Magma läuft auf macOS als Universal Binary und auf Windows 10 und 11 in 64 Bit. Die Installer liegen bei den Releases auf GitHub, dazu die Anleitung, wie du an der Warnung des Betriebssystems vorbeikommst. Magma legt in deinem Ordner nur ein verstecktes .magma-Verzeichnis für den Versionsverlauf an und schreibt sonst nichts Proprietäres in deine Dateien.
Wer Claude erst einmal nur schauen lassen will, setzt MAGMA_MCP_ALLOW_WRITE=0. Dann liest der MCP-Server den Vault, schreibt aber nichts. Ich empfehle das für die erste Sitzung ausdrücklich, weil du dabei siehst, wie das Modell durch deine Verlinkungen navigiert, ohne dass etwas in deinen Dateien landet. Wenn du danach umschaltest, ist die Seite „Was Claude geschrieben hat“ dein Kontrollpunkt: Sie listet jede Notiz mit author: ai in der Frontmatter, die neueste zuerst.
Wenn du einen Vault mit mehreren tausend Notizen hast, bist du gerade die interessanteste Testperson, die ich haben kann. Zeig mir, wo es hakt. Wenn dir ein Bug auffällt, lies vorher kurz die offenen Issues, vielleicht steht er schon drin.
Ich baue kein Produkt, das fertig sein will. Ich baue ein Werkzeug, das ich täglich benutze und öffentlich repariere. Das nächste Stück Arbeit ist der synthetische Vault, mit dem ich Issue 18 endlich nachmessen kann.
