Von Logseq zu VaultBook wechseln: Die vollständige Schritt-für-Schritt-Anleitung

Elena Marsh beschloss, Logseq zu verlassen, nicht wegen einer Funktionsvergleichstabelle. Sie beschloss es an einem Dienstagmorgen, in ihrer Küche stehend, das Telefon in der einen Hand und eine Kundenfrist in der anderen, während sie zusah, wie sich eine kleine Synchronisationsanzeige einfach nicht bewegte.

Am Abend zuvor hatte sie lange gearbeitet. Elena ist freiberufliche Recherche-Analystin und Autorin. Unternehmen beauftragen sie, unübersichtliche Themen zu durchdringen – einen Markt, den sie noch nicht verstehen, einen Wettbewerber, den sie unterschätzt haben, einen Stapel aus Interviews, Berichten und halb erinnerten Entscheidungen, der zu einem Dokument werden muss, mit dem jemand tatsächlich etwas anfangen kann. Seit vier Jahren lebte fast all diese Arbeit an einem einzigen Ort: in ihrem Logseq-Graphen.

Ihr tägliches Journal war der Ort, an dem jeder Morgen begann. Ihre Kundenrecherche-Seiten enthielten die Interviewnotizen, die Quellenzusammenfassungen und die langsame Anhäufung von Verständnis, die zu bezahlter Arbeit wurde. Ihre Lesenotizen enthielten die Bücher und Aufsätze, zu denen sie immer wieder zurückkehrte. Projektseiten enthielten Aufgaben, Entwürfe in Gliederungsform und die kleinen, unscheinbaren Textblöcke, die es nie in einen Abschlussbericht schaffen, aber erklären, warum der Abschlussbericht sagt, was er sagt. Insgesamt war der Graph auf rund 3.800 Seiten angewachsen.

An jenem Montagabend war die Arbeit gut gelaufen. Sie hatte eine Kundenseite auf ihrem Laptop umstrukturiert, eine Reihe von Notizen auf ihrem Telefon hinzugefügt, während ihr die Gedanken fern vom Schreibtisch kamen, und alles mit dem Gefühl geschlossen, dem nächsten Morgen ausnahmsweise einmal voraus zu sein.

Am Dienstag erzählte ihr der Graph etwas anderes.

Der Synchronisationsstatus blieb hängen. Änderungen, von denen sie wusste, dass sie sie vorgenommen hatte, kamen nicht voran. Auf dem Telefon saß eine Bearbeitung, die sie zuversichtlich gemacht hatte, hinter einem Status, der nahelegte, alles sei in Ordnung – und doch war das Material nicht dort, wo sie es auf dem Laptop erwartete, als sie danach suchte. Nichts Dramatisches explodierte. Keine Fehlermeldung verkündete eine Katastrophe. Das war beinahe das Schlimmste daran. Das System tat einfach die stille, langweilige Sache nicht, von der sie sich darauf verlassen hatte, dass es sie tut: einen Bestand an Arbeit, denselben, an den Orten zu halten, an denen sie damit arbeitete.

Sie verlor den Morgen dadurch. Nicht den ganzen Graphen – bleiben wir präzise, denn Präzision ist in einem Migrationsleitfaden wichtig –, aber einen Morgen des Prüfens, Wiederöffnens, Vergleichens und Wiederaufbaus ihres Vertrauens darin, welche Version einer Seite die echte war. Eine freiberufliche Analystin verkauft keine Stunden im Abstrakten. Sie verkauft Vormittage wie diesen. Wenn ein Werkzeug einen davon frisst, hat es etwas Reales genommen.

Was den Morgen entscheidend machte, war nicht der Stillstand selbst. Synchronisationsprobleme passieren. Software hat schlechte Versionen. Elena hatte raue Kanten schon früher erlebt und war geblieben, weil der Kerndeal von Logseq so gut war. Man behielt reine Markdown-Dateien, in einem Ordner, der einem selbst gehörte, geschrieben in einem Format, das jeder taugliche Editor öffnen konnte. Man bekam einen Outliner, der dazu passte, wie Recherche tatsächlich entsteht – in Fragmenten, in Hierarchien, in Verbindungen, die sich erst später zeigen –, dazu tägliche Journale, Backlinks, verlinkte Referenzen, Blockreferenzen, Abfragen und eine Graphenansicht, die einem manchmal eine Beziehung zeigte, die man nicht bewusst hergestellt hatte. Für diesen Deal lohnte es sich, viel zu ertragen.

Als sie auf die festhängende Synchronisation blickte, wurde ihr klar, dass der Deal selbst in zwei Teile zerfallen war.

Das Logseq, das sie gewählt hatte – die dateibasierte Version, gebaut auf Markdown-Dateien in einem lokalen Ordner –, war nicht mehr die Zukunft des Produkts. Es würde weiter bestehen, aber im Wartungsmodus: Sicherheits- und Wartungsaktualisierungen, keine neuen Funktionen. Die Zukunft war ein anderes Logseq, eine Datenbankversion, die einen Graphen in einer lokalen SQLite-Datenbank speicherte statt in einem Ordner reiner Dateien. Diese Version war in der Beta, dort war die Entwicklungsenergie hingeflossen, und sie zu übernehmen bedeutete, genau die Eigenschaft aufzugeben, deretwegen sie Logseq ursprünglich gewählt hatte: Dateien, die sie öffnen, lesen, verschieben und verstehen konnte, ohne die Anwendung, die sie erstellt hatte.

Sie hasste die Datenbankversion nicht. Sie hielt die Menschen, die sie bauten, nicht für Schurken, und sie hielt auch niemanden, der zu ihr gewechselt war, für töricht. Wir werden die Menschen kennenlernen, die sie verteidigen, und sie gut verteidigen, später in diesem Leitfaden, denn jeder ehrliche Entscheidungsrahmen muss sie einbeziehen. Ihre Schlussfolgerung war enger und persönlicher: Das Produkt, für das sie sich angemeldet hatte, war nun die Alt-Edition seiner selbst, das an seiner Stelle gebaute Produkt verlangte einen Tausch, den sie nicht eingehen wollte, und der Synchronisationsfehler hatte ihr gezeigt, wie es sich anfühlte, wenn die Maschinerie um ihre Notizen herum aufhörte, langweilig zu sein.

Also beschloss sie zu migrieren – und, entscheidend, jetzt zu migrieren, zu ihren eigenen Bedingungen, solange die Entscheidung noch billig war.

Billig ist das richtige Wort, und es lohnt sich zu verstehen, warum. Weil ihr Graph noch ein Datei-Graph war, waren ihre Notizen noch Markdown. Jede Seite war eine Textdatei. Jeder Link war Text, den sie durchsuchen konnte. Jedes Asset war eine Datei in einem Ordner. Der Umzug würde Arbeit werden – dieser Leitfaden wird nichts anderes behaupten, und die folgenden Abschnitte werden genau zeigen, wo die Arbeit liegt –, aber es war Arbeit, die sie mit gewöhnlichen Werkzeugen erledigen konnte, in ihrem eigenen Tempo, mit dem ursprünglichen Graphen unberührt als Sicherheitsnetz daneben. Würde sie warten, aus Trägheit auf die Datenbankversion abdriften und ein Jahr später feststellen, dass sie hinauswollte, begänne derselbe Umzug mit einem Exportschritt, der bekanntermaßen unvollkommen ist, und sie würde von einem Ausdruck ihres Graphen migrieren statt vom Graphen selbst.

Dieser Leitfaden folgt ihrer Migration, Schritt für Schritt, hinein in VaultBook: eine HTML-Anwendung aus einer einzigen Datei, lokal-zuerst, die null Netzwerkanfragen stellt, ihre Arbeit in einer einzigen verschlüsselten Datei hält, die sie kontrolliert, mit Einträgen, Labels, Wiki-Links und vollständiger Suche, dazu einer Reihe eingebauter Dokument-, PDF- und Audio-Werkzeuge, die ihr Graph nie hatte. Es ist keine Ein-Klick-Geschichte. VaultBook hat keinen Logseq-Import, und Teil B dieses Leitfadens wird den ehrlichen manuellen Weg beschreiben – Markdown hineinkopieren, es zu Einträgen umstrukturieren, Links als Wiki-Links und Labels neu aufbauen –, ohne ihn als Automatisierung zu verkleiden. Es ist auch keine Geschichte über ein perfektes Ziel. VaultBook hat keine Graphenansicht, keinen Outliner, keine Blockreferenzen, keine Datalog-Abfragen und keine Plugins, und wenn diese Dinge der Mittelpunkt Ihres Arbeitslebens sind, wird dieser Leitfaden Ihnen unumwunden sagen, dass Sie bleiben sollten, wo Sie sind.

Doch wenn Sie Elenas Morgen wiedererkennen – oder, stiller, wenn Sie ihre Erkenntnis wiedererkennen –, dann ist dieser Leitfaden für Sie. Er wurde für die Logseq-Nutzerin geschrieben, die noch immer vieles an Logseq liebt, die keinen Kampf sucht und die die Notizen eines Arbeitslebens umziehen möchte, ohne die Teile zu verlieren, auf die es ankommt. Wir beginnen damit, warum so viele Menschen gleichzeitig ins Nachdenken kommen, bauen dann einen ehrlichen Rahmen für die Entscheidung, ob Sie überhaupt wechseln sollten, prüfen dann einen Graphen so, wie Elena ihren prüfte, und sichern dann Backups ab, bevor auch nur eine Datei berührt wird. Erst danach, in Teil B, beginnen die praktischen Migrationsschritte.

Warum Logseq-Nutzer jetzt neu nachdenken

Um zu verstehen, warum es in diesem Moment überhaupt Migrationsleitfäden für Logseq gibt, muss man zuerst verstehen, wie ungewöhnlich Logseqs ursprüngliches Versprechen war – und wie gut es dieses Versprechen lange Zeit gehalten hat.

Die meisten Notizprodukte verlangen, einem Container zu vertrauen. Die Notizen leben in deren Datenbank, hinter deren Kontosystem, erreichbar über deren Anwendung, exportierbar in der Form, die sie anzubieten belieben, nach dem Zeitplan, den sie dafür vorsehen. Logseqs Datei-Graph verlangte fast nichts von diesem Vertrauen. Ein Graph war ein Ordner. Seiten waren Markdown-Dateien – oder Org-mode-Dateien, für diejenigen, die diese bevorzugten –, die in diesem Ordner mit gewöhnlichen Dateinamen lagen. Man konnte den Ordner in einem Dateimanager öffnen und seine Wissensbasis als Stapel von Dokumenten sehen. Man konnte jede Seite in einem anderen Editor öffnen und lesen, denn es gab fast nichts Proprietäres zu entschlüsseln: Überschriften, eingerückte Blöcke, Links, als Text geschrieben, Eigenschaften, als Text geschrieben.

Auf diesen Dateien baute Logseq eine wirklich eigenständige Arbeitsweise auf. Es lohnt sich, ordentlich zu beschreiben, was die Menschen daran lieben, denn Autoren von Migrationsleitfäden beschreiben das Produkt, das verlassen wird, zu oft so, als wäre es ein Fehler seiner Nutzer gewesen. Es war kein Fehler. Für viele Forscher, Autorinnen, Studierende und Ingenieure passte Logseqs Modell besser zu ihrem Denken als alles andere, was sie versucht hatten.

Zuerst kam der Outliner. Recherche kommt nicht als fertige Prosa an. Sie kommt an als Satz aus einem Interview, als Zahl, die geprüft werden muss, als Widerspruch zwischen zwei Quellen, als Frage, die man noch nicht beantworten kann. Ein Outliner lässt einen diese Fragmente in der Größe erfassen, die sie tatsächlich haben, sie unter die Seite oder Überschrift schachteln, zu der sie gehören, zuklappen, woran man nicht arbeitet, aufklappen, woran man arbeitet, und die ganze Struktur neu ordnen, während sich das Verständnis verbessert. Elenas Kundenseiten waren keine Aufsätze; sie waren lebende Gliederungen, die langsam anderswo zu Aufsätzen wurden, und die Gliederung war der Ort, an dem das Denken geschah.

Als Zweites kam das tägliche Journal, und für viele Nutzer war es noch wichtiger. Jeder Tag öffnete eine neue Seite, datiert, bereit. Man musste nicht entscheiden, wohin ein Gedanke gehörte, bevor man ihn aufschreiben durfte. Man schrieb ihn ins heutige Journal, verlinkte ihn mit den Seiten, die er betraf, und vertraute darauf, dass Backlinks und verlinkte Referenzen ihn wieder versammeln würden, wenn man diese Seiten später besuchte. Die Erfassungsreibung sank nahe null, und ein durchsuchbares, verlinktes Tagebuch des eigenen Arbeitslebens häufte sich fast als Nebeneffekt an. Diesen Journal-Fluss neu aufzubauen ist einer der schwierigsten Teile beim Verlassen von Logseq, und Nutzer, die einen Wechsel erwägen, nennen ihn immer wieder – nicht als Funktion auf einer Checkliste, sondern als Gewohnheit, die in ihre Tage eingewoben ist.

Dann kamen die Verbindungen. Links waren in Logseq billig zu machen und zahlten sich in mehreren Währungen zurück: gewöhnliche Seitenlinks, automatisch aufgelistete Backlinks, verlinkte Referenzen, die Blöcke hereinzogen, die eine Seite erwähnen, Blockreferenzen, die einen bestimmten Block lebend innerhalb einer anderen Seite erscheinen ließen, und Block-Einbettungen, die noch weiter gingen. Eine Graphenansicht zeichnete das ganze Netz der Seiten, sodass man Cluster und Waisen sehen konnte. Abfragen ließen einen lebende Listen bauen – jede offene Aufgabe mit einer bestimmten Markierung, jeder Block mit einer bestimmten Eigenschaft, jede Seite, die diese Woche berührt wurde – mit einer Abfragesprache, hinter der echte Macht stand. Dazu kamen Aufgaben, die in den Notizen lebten statt in einer separaten Anwendung, PDF-Annotation, die die Lektüre an den Seiten befestigt hielt, Karteikarten, Whiteboards und ein Plugin-Ökosystem, das es den Menschen erlaubte, das Werkzeug in Richtung ihrer eigenen Berufe zu biegen – und man hatte etwas, das mit einem Ordner voller Dokumente oder einer herkömmlichen Notiz-App nicht wirklich austauschbar war. Open Source, unter der AGPL-3.0-Lizenz, lokal-zuerst, im Kern kostenlos. Kein Wunder, dass Menschen Jahre darin investierten.

Deshalb lässt sich der gegenwärtige Moment am besten nicht als Scheitern beschreiben, sondern als Gabelung.

Ein Produkt, zwei Logseqs

Logseq existiert heute in zwei Formen, die einen Namen teilen, eine Geschichte und einen großen Teil Code und Designsprache, die aber auf unterschiedlichen Antworten auf die grundlegendste Frage beruhen, die ein Notizwerkzeug stellen kann: Wo, physisch, leben Ihre Notizen?

In Logseq OG – der dateibasierten Version, derjenigen, die Elena wählte – lautet die Antwort: der Ordner. Die Anwendung ist, in einem wichtigen Sinn, eine sehr ausgefeilte Art, eine Menge Markdown-Dateien zu betrachten und zu bearbeiten, die weiterhin existieren würden, lesbar und vollständig, wenn die Anwendung gelöscht würde. Die Dateien sind die Wahrheit. Die Anwendung ist eine Interpretation von ihnen.

In der Datenbankversion – Logseq 2.0, derzeit in der Beta – lautet die Antwort: eine lokale SQLite-Datenbank. Ihr Graph lebt in dieser Datenbank. Die Datenbankversion ist weiterhin lokal-zuerst: Dies ist keine Geschichte darüber, dass Notizen gegen irgendjemandes Willen in die Cloud eines anderen verschoben würden. Aber eine SQLite-Datenbank ist eine andere Art von Zuhause als ein Ordner voller Textdateien. Man kann sie nicht in einem Dateimanager durchstöbern und seine Seiten lesen. Man kann eine Seite nicht in einem anderen Editor öffnen, denn es gibt keine Seitendatei, die man öffnen könnte. Um einen Datenbank-Graphen überhaupt in Markdown-Editoren nutzen zu können, muss man ihn exportieren – und Export, wie wir sehen werden, ist nicht dasselbe, wie dass die Dateien einfach da sind.

Die Arbeitsteilung zwischen den beiden Versionen ist es, die aus dieser Gabelung eine Entscheidung macht. Die dateibasierte Version läuft mit Wartungs- und Sicherheitsaktualisierungen weiter, aber ohne neue Funktionen. Sie wird nicht abgeschaltet, und niemand wird mit vorgehaltener Waffe von ihr vertrieben; Elenas Graph öffnet sich noch, funktioniert noch und hätte sich noch lange öffnen und funktionieren können. Aber ein Produkt, das nur gewartet wird, ist ein Produkt, dessen Zukunft eine langsame Verengung ist. Fehler, die keine Sicherheitsprobleme sind, warten. Integrationen altern. Die umgebende Welt – Betriebssysteme, Sync-Dienste, die Formate der Dinge, die man ausschneidet und anhängt – bewegt sich weiter, und ein Werkzeug, das stillsteht, passt allmählich schlechter zu ihr. Währenddessen erhält die Datenbankversion die Entwicklungsenergie: neue Datenmodell-Funktionen, neue Eigenschaften-Behandlung, Leistungsarbeit, die Aufmerksamkeit des Teams. Auf Dateien zu bleiben bedeutet daher nicht, bei dem Logseq zu bleiben, das man hat; es bedeutet, bei einer Momentaufnahme davon zu bleiben, während das lebende Produkt in eine Richtung wächst, die auf einem Speichermodell aufbaut, das man nicht gewählt hat.

Das ist die ehrliche Version der Spaltung, und dieser Leitfaden wird bei ihr bleiben. Es ist nicht so, dass die Datei-Version weggenommen wurde. Es ist so, dass sie umklassifiziert wurde – vom Produkt zum Vorgänger.

Warum die Datenbankfrage so tief schneidet

Würde die neue Version lediglich ein internes Implementierungsdetail ändern, würden sich wenige Menschen darum kümmern, und dieser Leitfaden würde nicht existieren. Nutzer prüfen im Allgemeinen nicht, wie ihre Software Daten speichert. Der Grund, warum der Datenbankschritt gerade unter Logseq-Nutzern so starke Reaktionen hervorruft, ist, dass Speicherung für diese Nutzerbasis nie ein Implementierungsdetail war. Sie war das Auswahlkriterium.

Menschen wählten Logseq, in großer Zahl, wegen der Dateien. Sie sagen es, durchgängig, wenn sie sich erklären: Sie kamen für reines Markdown, das jeder Editor öffnen kann, für einen Ordner, auf den sie zeigen und den sie ihren nennen konnten, für Freiheit von genau der Art von Container-Abhängigkeit, die sie andernorts erlebt hatten. Eine Datenbank – selbst eine lokale, gut verstandene, technisch respektable Datenbank wie SQLite – entfernt die Eigenschaft, die sie gekauft haben. Man kann seine Notizen nicht mehr ohne Werkzeuge lesen. Backups werden zu Backups eines einzigen undurchsichtigen Artefakts statt vieler lesbarer. Ein Korruptionsproblem, falls eines auftritt, bedroht einen einzigen Ausfallpunkt statt einer einzelnen ersetzbaren Seite. Ob diese Befürchtungen in jedem Fall verhältnismäßig sind, ist eine faire Frage, und Verteidiger der Datenbankversion argumentieren vernünftigerweise, dass eine Datenbank echte Vorteile bringt: ein reicheres Eigenschaftensystem, neue Organisationsfunktionen wie Supertags, schnellere Navigation in einem großen Graphen, sobald er geöffnet ist, und Erleichterung von einigen bekannten Kosten der Datei-Version, darunter die Art, wie die Datei-Version Seiten in eine eigene In-Memory-Datenbank lädt und schwer werden kann, wenn ein Graph komplex wird. Diese Argumente verdienen ihren Platz, und sie bekommen ihn im Entscheidungsrahmen unten. Aber selbst wenn man jedes einzelne davon zugesteht, bleibt der Tausch ein Tausch: Man tauscht Lesbarkeit und Editor-Unabhängigkeit gegen Fähigkeit und Struktur, und Nutzer, die das Werkzeug der Lesbarkeit wegen gewählt haben, dürfen das als grundlegende Veränderung erleben, nicht als routinemäßiges Upgrade.

Die Exportfrage schärft den Punkt. Ein Datenbank-Graph kann nach Markdown exportiert werden – die Tür ist nicht verschlossen. Aber nach mehreren Nutzerberichten öffnet sich die Tür nicht zurück auf dieselbe Landschaft. Der Export kann die Ordnerstruktur eines Graphen abflachen und Dateien in einem Ordner zusammenlegen statt dort, wo sie lebten. Assets – die Bilder, PDFs und Anhänge, die ein Graph ansammelt – wurden Berichten zufolge nicht zuverlässig mitgenommen. Ein Spiegelmodus, der eine Markdown-Kopie neben der Datenbank halten sollte, hat Berichten zufolge auf einigen Seiten Daten vermissen lassen. Und der Rundweg kann auch in der anderen Richtung ausfransen: Der Import eines Markdown-Graphen in die Datenbankversion hat bei einigen Nutzern lange Listen von Importfehlern hervorgebracht, Seiten, die als Tags ankamen, und Seiten, die gar nicht ankamen. Nichts davon bedeutet, dass Export nie funktioniert oder dass jeder Import ein Durcheinander ist; viele Graphen sind ohne Drama hinübergewechselt. Es bedeutet, dass Export am besten als Übersetzung zu verstehen ist, mit den Verlusten, die Übersetzungen haben, statt als bloßer Besitzerwechsel der Dateien. Wenn Ihre Notizen bereits Markdown sind, halten Sie den Originaltext. Wenn sie zuerst eine Datenbank werden, halten Sie für immer eine Übersetzung davon.

Elena kehrte in der Woche nach dem Sync-Stillstand immer wieder zu einer einfachen Formulierung zurück, und sie mag auch Ihnen helfen: Sie hatte nichts gegen Datenbanken. Ihr Arbeitsleben war voll von ihnen, und sie vertraute mehreren Dinge an, die ihr wichtig waren. Sie hatte etwas dagegen, dass ihre Notizen eine wurden – dass die Interpretationsschicht verpflichtend, dauerhaft und zu dem wurde, wovon sie abhängen musste.

Das Sync-Problem, ehrlich dargestellt

Die Speicherung ist der strategische Grund, warum Menschen Logseq jetzt überdenken. Sync ist sehr oft der praktische Auslöser – der schlechte Morgen, der ein Hintergrund-Unbehagen in eine Entscheidung verwandelt –, und er verdient eine ebenso ehrliche Behandlung, denn die Wahrheit ist hier in beide Richtungen ungleichmäßig.

Logseqs Kernanwendung ist kostenlos. Ihr offizieller Sync-Dienst ist das bezahlte Extra – während der Beta mit fünf Dollar im Monat im Backer-Tarif oder fünfzehn Dollar im Monat im Sponsor-Tarif bepreist, über Open Collective –, und viele Nutzer zahlen ihn nie, weil das dateibasierte Design dazu einlädt, den Ordner selbst zu synchronisieren, mit iCloud, Dropbox, Git, Syncthing oder was man ohnehin betreibt. Diese Freiheit ist real und Teil des Datei-Deals. Aber jeder Weg, offizielle wie selbstgebaute gleichermaßen, hat eine erkennbare Menge an Beschwerden von den Menschen hervorgebracht, die sich auf ihn verlassen, und das Muster über alle hinweg sagt mehr aus als jeder einzelne Vorfall.

Die Beschwerden ballen sich um ein Thema: Der Status, der einem gezeigt wird, und der Zustand, in dem sich die eigenen Daten befinden, können auseinanderfallen. Nutzer neuerer Versionen beschreiben Sync, der stillsteht – eine Anzeige, die nicht synchronisierte Änderungen zeigt, die nie vorankommen, eine mobile Sync-Steuerung, die nichts zu tun scheint –, wobei der einzige verlässliche Ausweg der drastische ist: den lokalen Graphen löschen und ihn erneut herunterladen, wonach das Problem zurückkehren kann. Ältere Berichte beschreiben Sync, der aktiv Schaden anrichtet: Blöcke verdoppelt, Blöcke unter andere Eltern verschoben, offline eingegebenes Material, das in der Zusammenführung verschwand, die es eigentlich verbinden sollte, sodass die Wahl zwischen einer beschädigten Version und einer verlorenen blieb. Ein mobiler Bericht ist in der Zusammenfassung besonders schwer zu lesen, weil nichts darin exotisch ist: eine neue Seite synchronisiert, Bearbeitungen vorgenommen, die Anwendung erneut geöffnet, ein Fehler erschien, während der Status darauf bestand, alles sei synchronisiert, und das praktische Heilmittel – das erzwungene Beenden – beseitigte den Fehler um den Preis, dass das jüngste Material dauerhaft verloren ging. Die Person in jenem Bericht war zahlender Sync-Kunde, auf der Markdown-Version, und das zugrunde liegende Problem galt als seit Langem offen. Andere Nutzer, die über Cloud-Laufwerke synchronisieren, beschreiben ständiges Neuindizieren, verdoppeltes Material und Links, die an Stellen brechen, an denen sie nicht brechen sollten.

Was sich fairerweise sagen lässt, ist dies: Für ein Werkzeug, dessen tiefster Reiz die Einfachheit von Dateien auf der Platte ist, führt Sync genau die Undurchsichtigkeit wieder ein, die die Dateien einem ersparen sollten. Wenn ein Ordner Markdown-Dateien vor einem liegt, kann man sehen, was man hat. Wenn ein Sync-System einem sagt, man sei synchronisiert, vertraut man einer Behauptung – und Elenas Dienstagmorgen war der Moment, in dem sie bemerkte, wie viel von ihrer Arbeitsruhe still auf Behauptungen dieser Art geruht hatte. Ihre Antwort war nicht, einen besseren Sync-Dienst zu finden. Sie lautete zu fragen, ob ihre Notizen überhaupt Sync-Maschinerie brauchten, oder ob sie ihre Arbeit um eine einzelne Datei herum organisieren konnte, die sie bewusst bewegte, auf Medien, die sie kontrollierte, wobei Verschlüsselung den Schutz übernahm, den früher ein Kontosystem leistete. Diese Frage, mehr als der Stillstand selbst, führte zu VaultBook.

Leistung, Komplexität und das Gewicht eines gewachsenen Graphen

Der dritte Grund, warum Nutzer neu nachdenken, ist langsamer und weniger dramatisch: Ein Graph, der herangewachsen ist, kann schwer darin zu leben werden, und schwer auf Arten, die weniger mit der Seitenzahl zu tun haben als mit dem, was in den Seiten steckt.

Berichte über Leistungsprobleme existieren bei überraschend bescheidenen Größenordnungen und fehlen auffällig bei viel größeren. Einige Nutzer beschreiben Graphen um tausend bis fünfzehnhundert Seiten, die langsam genug werden, um den Tag zu unterbrechen – träger Start, Verzögerung im gewöhnlichen Gebrauch, die Anwendung muss mehrmals täglich geschlossen werden. Andere beschreiben einen Graphen von ungefähr fünftausend Seiten, der lange zum Laden braucht, wo andere Werkzeuge nahezu sofort öffnen. Und dann, in denselben Diskussionen, berichten andere Nutzer von Graphen mit viertausend, siebentausend Seiten, die akzeptabel laufen, und sie meinen es ernst. Beide Berichtsgruppen sind glaubwürdig, denn Seitenzahl ist ein schlechter Stellvertreter für Gewicht. Was einen Graphen schwer zu machen scheint, ist Komplexität: tiefe Namespaces, verschachtelte Seiten, dichte Eigenschaften, viele Abfragen, viele Bilder und Anhänge, aufwendige Blockstrukturen. Die Gewohnheit der Datei-Version, den Graphen in eine eigene In-Memory-Datenbank zu laden, bedeutet, dass ein komplexer Graph viel von der Maschine verlangt, bevor man ein einziges Zeichen getippt hat. Die Datenbankversion verspricht auf einigen dieser Felder Erleichterung, und manche, die gewechselt sind, berichten genau davon – schnellere Bewegung im Graphen, sobald er geöffnet ist –, während andere berichten, dass die neue Version eigene Verzögerungen, Duplikate oder Korruption mitbringt. Es gibt keinen ehrlichen Satz der Form „Logseq ist jenseits von N Seiten langsam”, und dieser Leitfaden wird keinen anbieten. Es gibt nur eine Frage, die jeder Nutzer aus seinem eigenen Graphen beantworten muss: Hat Ihrer die Linie überschritten, an der das Gewicht des Werkzeugs eine tägliche Steuer auf die Arbeit ist, die es hält?

Für Elena lautete die ehrliche Antwort: beinahe, und steigend. Ihr Graph war nicht der größte, den irgendwer betreibt, aber er war dicht auf genau die teuren Arten – Kunden-Namespaces, Eigenschaften auf Recherche-Seiten, Abfragen, auf die sie sich verließ, um Statusansichten zusammenzustellen, Anhänge überall, vier Jahre Journale. Sie konnte die Startkosten spüren. Bedeutsamer als die reine Geschwindigkeit begann sie die Wartungskosten zu spüren. Ein gewachsener Logseq-Graph ist nicht nur Notizen; er ist ein kleines System. Sie hatte persönliche Konventionen aufrechtzuerhalten, eigenes Styling, Plugins, deren Verhalten sie brauchte und von denen manche den Datenbankwechsel voraussichtlich nicht überleben würden, und Abfragen – Dutzende davon über ihre Schlüsselseiten, über Jahre aufgebaut –, die ihre Dashboards hervorbrachten. Das System zu warten war zu einem zweiten Job unter dem ersten geworden, klein in den meisten Wochen, spitz in schlechten. Diese Erfahrung ist unter langjährigen Nutzern verbreitet genug, um ein eigenes Thema zu sein: Das Werkzeug belohnt Investitionen so reichhaltig, dass die Investition selbst irgendwann zur Belastung wird, ein Apparat, den nur seine Erbauerin vollständig versteht und nur seine Erbauerin reparieren kann.

Der ehrliche Entscheidungsrahmen: Wer bleiben sollte, wer wechseln sollte

Bevor Sie auch nur eine Seite prüfen, entscheiden Sie, ob Sie überhaupt migrieren sollten. Eine Migration aus den falschen Gründen wird Sie enttäuschen, egal wie sorgfältig Sie sie ausführen, denn kein Ziel reproduziert Logseq – und VaultBook versucht es insbesondere nicht. Es hat keinen Outliner, keine Blockreferenzen, keine Graphenansicht, keine Datalog-Abfragen und keine Plugins. Was es stattdessen bietet, ist ein anderer Schwerpunkt: ein verschlüsselter Tresor aus einer einzigen Datei, Einträge, organisiert mit Labels und Wiki-Links, eine Suche, die in Anhänge hineinreicht und Fragen über den ganzen Tresor hinweg beantwortet, und Werkzeuge für die Dokumente, PDFs, Audios, Bilder und Daten, die schriftliche Arbeit umgeben. Dieser Tausch ist für manche Logseq-Nutzer ausgezeichnet und für andere falsch. So erkennen Sie, welcher Sie sind.

Bleiben Sie, wenn der Outliner die Arbeit selbst ist

Bleiben Sie bei Logseq, wenn Ihr Denken wirklich auf Blockebene geschieht. Wenn Sie routinemäßig einzelne Blöcke von anderen Seiten aus referenzieren, sie einbetten, Abfragen bauen, die Ihren Tag aus über den Graphen verstreuten Eigenschaften zusammenstellen, und sich auf die Graphenansicht verlassen, um zu navigieren – wenn also die Funktionen ohne Äquivalent anderswo nicht Verzierungen Ihres Arbeitsablaufs sind, sondern seine tragenden Wände –, dann kostet Sie das Weggehen den Arbeitsablauf, nicht nur das Werkzeug. Nutzer in dieser Lage, die zu gehen versuchen, kehren tendenziell zurück, und das Zurückkehren ist kein Scheitern; es ist Information. Blockreferenzen sind durchgängig der am häufigsten genannte Verlust unter Menschen, die von Logseq weg migrieren, gerade weil nichts anderes sie auf dieselbe Weise macht. Abfragen und Eigenschaften lassen sich ebenfalls nirgendwohin sauber übertragen. Wenn Sie Hunderte von Abfragen in einem neuen Zuhause neu bauen müssten, das die meisten davon nicht ausdrücken kann, lautet die ehrliche Empfehlung zu bleiben und Ihr eigentliches Problem – das Sync sein kann, oder Leistung, oder Zukunftssorge – auf anderen Wegen zu lösen.

Bleiben Sie auch, wenn die Datenbankversion Ihnen wirklich liegt. Die Gegenstimmen hier sind echt, und dieser Leitfaden weigert sich, sie zu Karikaturen zu machen. Manche Nutzer sind zur Datenbankversion gewechselt und mögen sie lieber: Sie schätzen die reichere Eigenschaften-Behandlung und die Supertags, finden die Navigation in einem großen Graphen schneller, sobald er geöffnet ist, und die Datenbank beunruhigt sie nicht, weil sie ihren Backups der Datenbankdatei selbst vertrauen und andere Editoren an ihren Notizen kaum je benutzt haben. Manche von ihnen sind ungeduldig mit der Anhänglichkeit an reine Dateien und halten sie für Nostalgie für eine Einschränkung statt für einen Nutzen. Sie sind keine bezahlten Fürsprecher und nicht verwirrt über das, was sie getauscht haben; sie wogen Lesbarkeit gegen Fähigkeit ab und wählten Fähigkeit, für Arbeit, bei der Fähigkeit das ist, was sie täglich nutzen. Wenn das auch Ihre Abwägung ist, ist VaultBook – das noch mehr Leistungsfunktionen aufgibt als die Datenbankversion – mit Sicherheit nicht Ihr Ziel.

Bleiben Sie, wenn Ihr großer Graph gut läuft. Die Leistung in Logseq ist ungleichmäßig in der oben beschriebenen Weise: Manche Graphen straucheln bei fünfzehnhundert Seiten und manche gleiten bei siebentausend dahin. Wenn Ihrer zur zweiten Gruppe gehört, lassen Sie nicht die Verzögerung anderer Menschen zu Ihrem Grund werden, ein System aufzugeben, das Ihnen dient. Bleiben Sie ebenso, wenn Ihr Sync funktioniert. Wenn bezahlter Sync oder Ihre eigene Anordnung Ihren Graphen seit Jahren zwischen Maschinen und Telefon getragen hat, ohne etwas zu fressen, sind die Horrorgeschichten im vorigen Abschnitt ein Grund, Ihre Backups zu verifizieren, nicht notwendigerweise, Ihr Leben umzustellen. Und nehmen Sie den häufigsten Rat in der Community selbst ernst: Bleiben Sie auf der Version, die funktioniert. Die Datei-Version bleibt verfügbar und wird sicherheitsgewartet. Eine bekanntermaßen gute Version zu betreiben, mit guten Backups, während man beobachtet, wie die Datenbankversion reift, ist kein Aufschieben. Es ist eine legitime Strategie mit langer Ahnenreihe in jeder Ecke der Software, und für viele Nutzer ist sie die korrekte Antwort auf die Gabelung. Sie können die Entscheidung in einem Jahr mit mehr Informationen erneut prüfen und, falls Sie noch auf Dateien sind, zu keinen höheren Kosten, als Sie heute zahlen würden.

Wechseln Sie, wenn die Dateien der Punkt waren

Wechseln Sie, wenn Sie beim Blick auf Ihre eigene Geschichte feststellen, dass Sie Logseq so gewählt haben wie Elena: Dateien zuerst, Funktionen zweitens. Wenn der Ordner voller Markdown das Fundament Ihres Vertrauens war, dann ist der Nur-Wartungs-Status der Datei-Version kein Detail – er bedeutet, dass das Ding, das Sie gekauft haben, in seine lange Abenddämmerung eingetreten ist, und jedes Jahr, das Sie weiter in es investieren, ist ein Jahr, investiert in eine Plattform, deren lebender Nachfolger von Ihnen verlangt, das Fundament aufzugeben. Ein Wechsel ist auch angezeigt, wenn Sync Sie bereits Arbeit gekostet hat, oder wenn Sie sich bei Elenas Dienstagmorgen-Arbeit ertappt haben – Versionen mit bloßem Auge abgleichen, unsicher, welche Seite die echte ist –, denn diese Arbeit ist der Klang eines Kernversprechens, das versagt. Wechseln Sie, wenn die Komplexität Ihres Graphen zur Wartungslast geworden ist: Plugins zu pflegen, Styling zu reparieren, Abfragen neu zu bauen, ein System, das nur Sie verstehen. Wechseln Sie, wenn Ihre Arbeit in Richtung Langform-Schreiben, Dokumente, PDFs, Aufzeichnungen und Kundenlieferungen gedriftet ist – Material, das ein Outliner umständlich speichert und ein dokumentzentrierter Tresor nativ behandelt. Und wechseln Sie vor allem, wenn das, was Sie von Ihren Notizen brauchen, über die Jahre einfacher geworden ist. Viele reife Wissensbasen brauchen, bei genauer Betrachtung, ausgezeichnete Suche, klare Organisation, verlässliche Verschlüsselung und verlässlichen Zugang weit mehr, als sie lebende Abfragen brauchen. Wenn diese Betrachtung Sie beschreibt, ist die Macht, die Sie aufgeben würden, Macht, die Sie nicht mehr nutzen, und die Ruhe, die Sie gewinnen würden, ist echt.

Warum jetzt der billigste Moment ist, den Sie je bekommen werden

Wenn Sie sich zum Wechsel entscheiden, zählt der Zeitpunkt, und das Zeitpunkt-Argument ist der praktischste Einzelpunkt in diesem Leitfaden. Migrationskosten sind eine Funktion des Formats. Heute, wenn Sie auf der Datei-Version sind, ist Ihr Graph Markdown: menschenlesbar, editorunabhängig, durchsuchbar, vollständig. Jede Schwierigkeit in Teil B dieses Leitfadens – Gliederungen zu Einträgen umstrukturieren, Blockreferenzen von Hand umwandeln, Links neu aufbauen – ist eine Schwierigkeit der Form, nicht des Zugangs. Sie können alles, was Sie besitzen, in voller Länge, mit einem Texteditor sehen.

Stellen Sie sich nun vor, Sie schieben die Entscheidung auf, während Sie abdriften, wie die meisten Nutzer abdriften werden, auf die Datenbankversion, weil sie diejenige ist, die Aktualisierungen erhält, diejenige, die eine frische Installation anbietet, diejenige, die der Support voraussetzen wird. Ihre Notizen werden zu Zeilen in einer Datenbank. Dann zu gehen beschließen bedeutet, zuerst zu exportieren, und Export kann, wie die Berichte oben beschreiben, Ihre Ordner abflachen, Ihre Assets stranden lassen und Ihre Seiten durch eine Übersetzungsschicht schicken, deren Spiegelkopien Berichten zufolge unvollständig sind. Sie würden vom Export migrieren, nicht vom Graphen – und jeder Verlust in diesem Export würde zu einem dauerhaften Merkmal Ihres neuen Zuhauses werden, bevor Sie ein einziges Wort darin geschrieben hätten. Dieselbe Logik gilt im Kleinen auch für Aufschub auf der Datei-Version selbst: Jedes zusätzliche Jahr fügt Seiten, Anhänge, Eigenschaften und Gewohnheiten hinzu, die alle geprüft und mitgenommen werden müssen. Graphen werden durch Wachsen nicht billiger umzuziehen.

Die Regel ist also einfach: Wenn Sie gehen, gehen Sie von den Dateien. Migrieren Sie, solange der Originaltext noch in Ihren Händen ist, solange der Umzug eine Neuorganisation ist statt einer Rettung. Das meinte „zu ihren eigenen Bedingungen” für Elena – nicht Zorn, nicht Hast, sondern den Moment zu wählen, in dem die Tür am weitesten offen stand, und bewusst hindurchzugehen, mit dem ursprünglichen Graphen unberührt hinter ihr bewahrt, falls das neue Zuhause enttäuschte. Die nächsten zwei Abschnitte existieren, um diese Bewusstheit zu schützen: zuerst, wissen Sie genau, was Sie haben; dann, machen Sie es unmöglich zu verlieren.

Die Prüfung vor der Migration: Wissen, was Ihr Graph tatsächlich enthält

Beginnen Sie eine Migration nicht damit, Dateien zu kopieren. Beginnen Sie damit, Inventur zu machen. Ein Graph, der über Jahre organisch gewachsen ist, wird seinen Besitzer in beide Richtungen überraschen: Es wird von manchen Dingen weit mehr geben, als Sie erwarten, von anderen weit weniger, und Kategorien von Material, deren Existenz Sie vergessen hatten. Elenas Prüfung dauerte zwei Abende. Sie sparte ihr, nach ihrer eigenen späteren Schätzung, Tage – weil jede Entscheidung, die sie während des eigentlichen Umzugs traf, bereits getroffen war, in Ruhe, im Voraus, und niedergeschrieben.

Sie werden eine schriftliche Prüfung brauchen, keine gedankliche. Erstellen Sie ein einfaches Dokument außerhalb des Graphen – es wird Teil Ihres Migrationsprotokolls werden – und arbeiten Sie die Kategorien unten durch, wobei Sie Zählungen und Notizen für Ihren eigenen Graphen festhalten, wie Elena es für ihren tat. Wenn eine Zählung schwer exakt zu bekommen ist, ist eine ehrliche Annäherung in Ordnung; was zählt, ist, die Form der Aufgabe zu kennen, bevor Sie sie beginnen.

Seiten, Journale und die Form des Ganzen

Beginnen Sie mit den Seiten: wie viele, von welchen Arten? Listen Sie den Graphenordner auf und zählen Sie die Markdown-Dateien, dann sortieren Sie sie in die Familien, die Sie tatsächlich erkennen – Kunden- oder Projektseiten, Personenseiten, Lese- und Referenznotizen, Konzeptseiten, Vorlagen, Verwaltungsseiten und der lange Schwanz einmaliger Erfassungen, den jeder Graph ansammelt. Notieren Sie die Namespaces: Seiten, die unter einer Hierarchie organisiert sind, tragen ihre Struktur in ihren Namen, und diese Struktur muss bewusst in das übersetzt werden, was das neue Zuhause organisiert – in VaultBooks Fall Labels und Wiki-Links –, statt dass man annimmt, sie überlebe den Umzug. Notieren Sie auch die Seiten, die in Wahrheit verkleidet etwas anderes sind: die Seite, die eigentlich ein Dokumententwurf ist, die Seite, die eine Zahlentabelle ist, die Seite, die nur existiert, um eine Abfrage zu halten. Sie werden andere Behandlung brauchen als gewöhnliche Notizen, und es ist besser, jetzt zu wissen, welche es sind.

Behandeln Sie die Journale als separate Familie, denn das sind sie. Jahre täglicher Seiten bilden ein zusammenhängendes Tagebuch mit eigenem Wert und eigener Migrationslogik. Entscheiden Sie im Prinzip, wie Sie über sie denken: Sind sie Referenzmaterial, das Sie durchsuchen, ein Archiv, das Sie der Vollständigkeit halber behalten, oder eine lebende Praxis, die Sie am Ziel in irgendeiner Form fortsetzen wollen? Elenas Antwort – sie getreu archivieren, sie bei Bedarf durchsuchen und frische tägliche Notizen als gewöhnliche Einträge im neuen Tresor beginnen, statt zu versuchen, Logseqs Journal-Maschinerie nachzubauen – wird nicht jedermanns sein, aber jeder braucht eine Antwort vor dem Umzug, denn Journale sind zahlreich genug, um jede andere Entscheidung zu verzerren, wenn sie ad hoc behandelt werden.

Assets: das Gewicht, das man im Text nicht sieht

Als Nächstes inventarisieren Sie den Assets-Ordner, und tun Sie es physisch. Öffnen Sie ihn, sehen Sie sich seine Gesamtgröße an und zählen Sie nach Typ: Bilder, PDFs, Audiodateien, Video, alles andere. Anhänge sind die Stelle, an der Migrationen still scheitern, denn Markdown-Text verweist auf Assets, statt sie zu enthalten, und ein Umzug, der den Text mitnimmt und die Dateien stranden lässt, erzeugt Seiten voller zuversichtlicher Verweise auf Dinge, die nicht mehr da sind. Fragen Sie bei jedem Typ, wozu er da ist. Elenas Assets enthielten vom Kunden gelieferte PDFs, die sie vertraglich aufbewahren musste, Screenshots, die Belege für Behauptungen in ihren Berichten waren, Fotografien, die bloß illustrativ waren, und eine Schicht verdoppelter Bilder, zweimal eingefügt und einmal referenziert. Diese vier Arten verdienten vier verschiedene Schicksale – sorgfältig mitgenommen, mitgenommen, billig mitgenommen und aussortiert –, und in VaultBook würden mehrere von ihnen im Transit etwas gewinnen, da PDFs, Bilder und Audio Dinge sind, die der Tresor öffnen, indizieren und mit eingebauten Werkzeugen bearbeiten kann, statt sie bloß zu speichern. Aber nichts davon ist möglich für ein Asset, von dem Sie nicht wussten, dass Sie es haben. Halten Sie auch die Größe des ganzen Ordners fest: Sie bestimmt, wie lange das Kopieren dauert, welche Backup-Medien Sie brauchen und ob die Größe Ihres neuen Tresors aus einer einzigen Datei etwas ist, um das man planen muss.

Abfragen, Eigenschaften und Blockreferenzen: die Maschinerie

Nun die harten Kategorien – die Logseq-Maschinerie, die nicht mitreist. Gehen Sie zuerst wegen der Abfragen durch Ihren Graphen. Finden Sie die Seiten, die sie tragen, und listen Sie auf, was jede Abfrage in einfacher Sprache für Sie tut: nicht ihre Syntax, sondern ihre Aufgabe. „Stellt jede offene Kundenaufgabe zusammen” ist eine Aufgabe; der Code, der sie erledigt, ist Logseqs und bleibt zurück. Markieren Sie bei jeder, ob die Aufgabe am Ziel noch erledigt werden muss, und wenn ja, mit welchen einfacheren Mitteln – einem Label, einer Suche, einer gespeicherten Gewohnheit. Elena fand Abfragen, deren Bau sie vergessen hatte, die Aufgaben erledigten, die sie nicht mehr hatte, neben einer Handvoll, die sie wöchentlich nutzte. Die vergessenen zurückzulassen war befreiend. Die wöchentlichen wurden zu einer kurzen, ausdrücklichen Neuaufbau-Liste, und genau dazu sollte eine Abfrage vor einer Migration werden: eine Anforderung, auf Englisch aufgeschrieben.

Als Nächstes kommen die Eigenschaften. Seiten und Blöcke in einem reifen Graphen tragen Eigenschaften – Status, Typen, Daten, Bewertungen, Kundenkennungen –, die Sortierung, Filterung und Abfragen antreiben. Exportieren Sie die Liste der Eigenschaftsschlüssel, die Ihr Graph tatsächlich verwendet, und entscheiden Sie bei jedem, ob er Information ist (in welchem Fall er als Text, als Label oder als strukturierter Inhalt im neuen Eintrag überleben muss) oder Maschinerie (in welchem Fall er mit dem alten System stirbt). Das klassische Prüfungsversagen hier ist, nach dem Umzug zu entdecken, dass eine Tatsache, auf die Sie sich verließen, nur als Eigenschaftswert in einer Form existierte, die Ihr neues Zuhause still fallen ließ. Ihre Eigenschaften jetzt zu lesen, solange sie noch an ihren Seiten hängen, ist der einzige verlässliche Weg, das zu verhindern.

Schließlich Blockreferenzen und Einbettungen – der heikelste Posten in jeder Logseq-Prüfung. Durchsuchen Sie Ihre Seiten nach ihren Spuren und zählen Sie die Seiten, die von ihnen abhängen. Eine Blockreferenz bedeutet, dass Inhalt an einem Ort lebt und an einem anderen erscheint; in jedem Ziel ohne Blockreferenzen muss jede Erscheinung entweder ein Link zum neuen Zuhause des Inhalts oder eine Kopie des Inhalts selbst werden, und das sind unterschiedliche Entscheidungen mit unterschiedlichen Wartungsfolgen. Elenas Ansatz war unsentimental: Referenzen, die für echte Wiederverwendung existierten – ein standardmäßiger Kundenhintergrund-Absatz, eine kanonische Definition –, wurden zu einzelnen Einträgen, auf die andere Einträge mit Wiki-Links verlinken würden. Referenzen, die nur existierten, weil der Outliner das Querveröffentlichen leicht machte, wurden zu Kopien, als Kopien akzeptiert, in den Seiten, die sie brauchten. Was sie nicht tat, war so zu tun, als würden die Referenzen überleben, oder sie zurückzulassen, um nach dem Umzug zerbrochen entdeckt zu werden. Ihre Prüfung sollte mit einer Zahl enden: So viele Seiten enthalten Referenzen, so viele verschiedene Blöcke werden referenziert, dies sind die, auf die es ankommt. Diese Zahl ist die wahre Größe des schwierigsten Teils Ihrer Migration, und Teil B wird direkt von ihr ausgehen.

Die drei Stapel: mitnehmen, archivieren, zurücklassen

Mit vollständiger Inventur sortieren Sie den gesamten Graphen in drei Stapel. Diese Sortierung, nicht das Kopieren, ist der intellektuelle Kern der Migration.

Der erste Stapel ist das, was es verdient, als lebendes Material umzuziehen: die Seiten, die Sie wöchentlich öffnen, die aktuelle oder voraussichtlich zu konsultierende Kunden- und Projektarbeit, die Referenznotizen, die Sie wirklich durchsuchen, die Schreibarbeit, auf die Sie stolz sind, und die Recherche, die Sie bezahlt aufbewahren müssen. Dieser Stapel wird zu echten Einträgen, sorgfältig umstrukturiert, Links neu aufgebaut, Eigenschaften gewürdigt. Er wird kleiner sein, als Sie befürchten – bei Elena deutlich unter der Hälfte des Graphen nach Seitenzahl, obwohl er nahezu den gesamten Wert des Graphen hielt.

Der zweite Stapel ist das, was als rohes Markdown zu archivieren ist: vollständig, getreu und bewusst unverarbeitet. Journale sind hier die natürlichen Bürger, zusammen mit abgeschlossenen Projekten, historischer Kundenarbeit, die Sie behalten müssen, aber selten öffnen, und allem, dessen Wert Vollständigkeit ist statt Nutzung. Als Markdown archivieren bedeutet genau, was es sagt – die ursprünglichen Dateien, intakt behalten, in einer Ordnerstruktur, die Sie mit gewöhnlichen Werkzeugen für immer durchsuchen können –, und einiges davon kann auch als Referenzmaterial in den Tresor gebracht werden, ohne die teure Umstrukturierung, die der erste Stapel erhält. Die Disziplin liegt darin, die Stapel nicht zu verwechseln: Archivmaterial, das volle Migrationsbehandlung erhält, verbrennt die Stunden, die Ihr lebendes Material brauchte.

Der dritte Stapel ist das, was zurückzulassen ist, und jede ehrliche Prüfung findet einen: doppelte Erfassungen, tote Namespaces aufgegebener Projekte, Vorlagenreste, von Importen erzeugte und nie gelesene Seiten, Abfragen für Aufgaben, die Sie nicht mehr erledigen, das Gerüst von Plugins und die archäologischen Schichten von Systemen, die Sie im zweiten Jahr vierzehn Tage lang ausprobierten. Zurücklassen bedeutet nicht löschen – nichts in diesem Leitfaden wird Ihnen sagen, Ihren ursprünglichen Graphen zu löschen –, es bedeutet, Material vom Umzug auszunehmen, damit Ihr neues Zuhause sein Leben als Arbeitswerkzeug beginnt statt als perfekte Nachbildung des angesammelten Sediments Ihres alten. Elenas dritter Stapel war das, was die Moral ihrer Migration ausmachte: Jede Seite darin war eine Stunde, die sie nicht aufwenden musste, und der kleinere, sauberere Tresor am Ende war ein Ort, den sie öffnen wollte. Schreiben Sie Ihre drei Stapel auf, mit Zählungen. Teil B beginnt bei ihnen.

Backup- und Sicherheitsschritte, bevor irgendetwas berührt wird

Alles bisher war Denken. Dieser Abschnitt ist der letzte der Vorbereitung, und er ist nicht verhandelbar: Bevor irgendeine Datei kopiert, umgewandelt, umbenannt oder umstrukturiert wird, muss Ihr Graph vollständig und verifiziert an mehr als einem Ort existieren – und die Kopie, von der Sie migrieren, darf niemals die einzige Kopie sein, oder die Kopie, an der Sie experimentieren.

Erstens: Stoppen Sie die beweglichen Teile. Schließen Sie Logseq auf jedem Gerät. Pausieren Sie, welche Sync-Anordnung Sie auch nutzen – offiziellen Sync, ein Cloud-Laufwerk, Git, Syncthing –, damit nichts in den Graphenordner schreibt, während Sie ihn kopieren, und damit ein halb migrierter Zustand niemals getreu auf Ihre anderen Maschinen weitergegeben werden kann. Ein Backup, das erstellt wird, während sich der Ordner noch verändert, kann innerlich genau auf die Arten inkonsistent sein, derentwegen Sie gesichert haben. Elena tat dies bewusst an einem Freitagabend: keine Kundenarbeit ausstehend, keine Telefon-Erfassung, die sie nicht ein Wochenende lang in ihrem Posteingang halten konnte.

Zweitens: Kopieren Sie den ganzen Graphenordner – nicht die Seiten allein. Der vollständige Ordner bedeutet die Markdown- und Org-Dateien, den Assets-Ordner mit jedem Anhang und die eigene Konfiguration und Metadaten des Graphen, die unscheinbaren Verzeichnisse, die die meisten Menschen nie öffnen. Kopieren Sie ihn, wie er steht, ohne vorher aufzuräumen, umzubenennen oder irgendetwas zu „reparieren”; ein Backup ist eine Fotografie, kein Edit. Legen Sie diese erste Kopie auf ein anderes physisches Medium als das Original: ein externes Laufwerk, nicht einen anderen Ordner auf derselben Platte. Machen Sie dann eine zweite Kopie, wenn möglich auf einem anderen Weg – Elenas ging in ein verschlüsseltes Archiv auf separatem Speicher –, denn die Fehler, die eine Platte zerstören, und die Fehler, die einen Ordner löschen, sind unterschiedliche Fehler, und Sie wollen beide überleben.

Drittens: Verifizieren Sie die Kopien, denn ein unverifiziertes Backup ist eine Hoffnung, kein Backup. Vergleichen Sie Dateizahlen zwischen Original und Kopie, vergleichen Sie Gesamtgrößen, und machen Sie dann den Test, der tatsächlich etwas beweist: Öffnen Sie den kopierten Graphen – in Logseq, das auf die Kopie zeigt, oder öffnen Sie mindestens eine Stichprobe von Seiten in einem reinen Editor, darunter jüngste Journale, eine Seite voller Eigenschaften, eine Seite voller Blockreferenzen und mehrere Assets jedes Typs. Wenn sich die Kopie öffnet und die Anhänge sich auflösen, haben Sie ein Backup. Halten Sie in Ihrem Migrationsdokument fest, wo jede Kopie liegt und an welchem Datum sie erstellt wurde. Wenn Ihr Graph unter Versionskontrolle stand, committen und pushen Sie ebenfalls alles; wenn nicht, ist dieses Backup Ihre Versionskontrolle für die Dauer des Umzugs.

Viertens: Etablieren Sie die Arbeitsregel, die alles in Teil B bestimmt: Der ursprüngliche Graph ist von diesem Moment an schreibgeschützt. Sämtliche Migrationsarbeit geschieht an einer separaten Arbeitskopie. Nichts wird je an Ort und Stelle umgewandelt, umstrukturiert oder gelöscht. Wenn ein Experiment die Arbeitskopie ruiniert, werfen Sie sie weg und kopieren frisch vom Original, wobei Sie eine Stunde verlieren statt einer Geschichte. Behalten Sie das Original auch dann unberührt, wenn die Migration gelingt – Elena behielt ihres, archiviert genau so, wie es an dem Freitag war, an dem sie aufhörte, darin zu schreiben, als dauerhaften Rohdatensatz hinter allem in ihrem neuen Tresor. VaultBooks eigene Schutzmechanismen gehören zur Zielseite dieser Disziplin: Der Tresor ist eine einzelne Datei, die Sie so leicht kopieren können, wie der Graphenordner es war, einzelne Einträge können verschlüsselt werden, und der Versionsverlauf im Tresor schützt vor Ihren eigenen Bearbeitungen – aber nichts davon ersetzt, mit sauberen, verifizierten Kopien in der Hand anzukommen.

Schließlich schreiben Sie Ihren Rollback-Punkt in einem Satz auf: „Wenn die Migration scheitert, kehre ich zum unberührten Graphen an diesem Ort zurück, gesichert an diesem Datum, und verliere nichts als Zeit.” Wenn Sie diesen Satz nicht wahrheitsgemäß schreiben können, sind Sie nicht bereit zu beginnen. Wenn Sie es können – Prüfung abgeschlossen, drei Stapel entschieden, Backups verifiziert, Original versiegelt –, dann sind Sie es, und der nächste Teil dieses Leitfadens setzt genau hier an: die Arbeitskopie öffnen, die erste Seitenfamilie aus Elenas erstem Stapel nehmen und die praktische Arbeit beginnen, einen Logseq-Graphen in einen VaultBook-Tresor zu verwandeln, einen bewussten Schritt nach dem anderen.

Den Logseq-Graphen exportieren und vorbereiten

Die praktische Arbeit beginnt, bevor VaultBook überhaupt geöffnet ist. Sie beginnt in dem Ordner, den Elena Marsh bereits besitzt.

Das ist der Vorteil, den sie bewusst nutzt, solange sie ihn noch hat. Ihr Graph ist ein Datei-Graph: reine Markdown-Dateien in einem lokalen Ordner, lesbar in jedem Editor, kopierbar mit jedem Dateiverwaltungswerkzeug, verständlich, ohne dass Logseq überhaupt läuft. Diese Übertragbarkeit ist echt, und sie ist genau das, was Migrieren jetzt zum kostengünstigen Moment macht. Würde sie warten, bis ihr Arbeitsleben in der Datenbankversion lebte – Graphen, gespeichert in einer lokalen SQLite-Datenbank, die Export erfordern, bevor sie überhaupt in Markdown-Editoren genutzt werden können –, begänne sie von einem Export, den sie nicht kontrollierte, nicht von Dateien, die sie bereits hat.

Die erste Regel dieser Migration ist also einfach: Arbeiten Sie wo immer möglich von den ursprünglichen Dateien. Exportieren Sie nur, wenn Sie keine ursprünglichen Dateien haben, von denen Sie arbeiten könnten. Behandeln Sie einen Export niemals als Ihre Quelle der Wahrheit, wenn der Ordner auf Ihrer Platte noch intakt ist.

Wie ein Datei-Graph auf der Platte tatsächlich aussieht

Öffnen Sie Ihren Graphenordner in Ihrem Dateimanager, nicht in Logseq, und sehen Sie sich an, was wirklich da ist. Ein typischer Datei-Graph hat eine kleine Zahl von Ordnern auf oberster Ebene, die unterschiedliche Aufgaben erfüllen, dazu Konfiguration, die daneben verstaut ist.

Der pages/-Ordner hält das meiste von dem, was Sie für Ihre Notizen halten: eine Markdown-Datei pro Seite. Eine Seite namens Client Research — Hartwell ist eine Datei in diesem Ordner. Ebenso eine Lesenotiz, eine Projektseite, eine Personenseite und die weitläufige Referenzseite, an der Sie seit drei Jahren schreiben. Namespaces verkomplizieren die Dateinamen leicht – eine Seite in einem Namespace ist immer noch eine Datei, aber ihr Name kodiert die Hierarchie –, doch es ist immer noch eine lesbare Textdatei, die Sie ohne Logseq öffnen, durchsuchen und kopieren können.

Der journals/-Ordner hält Ihre täglichen Journale, eine Markdown-Datei pro Tag, nach Datum benannt. Diese Dateien sind das Rückgrat von Elenas vier Jahren: Kundenanrufe, schnelle Erfassungen, begonnene und beendete Aufgaben, Links hinaus zu den Seiten, auf denen die echte Arbeit geschah. Sie wirken weniger strukturiert als Seiten, weil sie schneller geschrieben wurden, unter Druck, im Moment. Lassen Sie sich davon nicht dazu verleiten, sie als weniger wichtig einzustufen. In den meisten langlebigen Graphen enthalten die Journale den einzigen Nachweis, warum eine Entscheidung an einem bestimmten Dienstag getroffen wurde.

Der assets/-Ordner hält die Anhänge, die Logseq in Ihrem Auftrag gesammelt hat: PDFs, die Sie annotiert haben, Bilder, die Sie eingefügt haben, Audio und Screenshots und alles andere, auf das ein Block zeigte, statt es zu enthalten. Die Markdown-Dateien verweisen auf diese Assets; sie enthalten sie nicht. Vergessen Sie den Assets-Ordner, und Sie werden Tausende von Seiten migrieren, die zuversichtlich auf Dateien zeigen, die nicht mehr da sind.

Um diese drei Ordner herum sitzt der Rest der Graphenmaschinerie – Konfiguration, Logseqs eigene Metadaten, etwaige eigene CSS- oder pluginbezogene Dateien, die Sie über die Jahre angesammelt haben. Sie müssen die Maschinerie nicht migrieren. Sie müssen wissen, dass sie existiert, damit Sie sie nicht für Inhalt halten, und damit Sie sie nicht löschen, bevor Sie fertig sind. Ihre eigenen Abfragen, Ihre Plugin-Einstellungen und Ihre Theme-Anpassungen gehören zu Logseqs Arbeitsweise. Einige ihrer Ergebnisse sind sehr wichtig und werden später in diesem Leitfaden neu aufgebaut. Die Dateien selbst reisen nicht mit.

Elenas Inventur dauerte weniger als eine Stunde und veränderte ihren ganzen Plan. Ihr pages/-Ordner hielt den Großteil ihrer rund 3.800 Seiten, ihr journals/-Ordner hielt vier Jahre täglicher Dateien, und ihr assets/-Ordner war größer, als sie erwartet hatte – Jahre von Kunden-PDFs, als Bilder gespeicherte Diagramme und in Logseq angehängte Interviewaufzeichnungen. Dateien nach Ordner zu zählen, bevor eine einzige bewegt wurde, sagte ihr, dass dies nicht eine Migration war, sondern drei kleinere – Seiten, Journale und Assets –, mit unterschiedlichen Risiken in jeder. Machen Sie diese Zählung für Ihren eigenen Graphen: Jede spätere Entscheidung hängt davon ab zu wissen, welcher Stapel für Sie tatsächlich groß ist.

Machen Sie zwei Kopien, bevor Sie irgendetwas ändern

Bereiten Sie Ihren Graphen nicht an Ort und Stelle vor. Kopieren Sie den gesamten Graphenordner zweimal: eine Arbeitskopie, die Sie sortieren, umbenennen und auseinandernehmen werden, und eine unberührte Archivkopie, die Sie überhaupt nicht zum Bearbeiten öffnen werden.

Das ist keine Paranoia. Es ist der Unterschied zwischen einer Migration, die Sie pausieren können, und einer Migration, die Sie in Panik zu Ende bringen müssen. Blockreferenzen werden von Hand entwirrt werden. Dateinamen werden bereinigt werden. Manche Seiten werden sich als Duplikate, Stümpfe oder Unfälle herausstellen. Diese ganze Chirurgie gehört auf die Arbeitskopie. Die Archivkopie ist, wie Sie Wochen später beweisen, was eine Seite sagte, bevor Sie sie berührten – und VaultBooks eigener Versionsverlauf wird Sie erst ab dem Moment schützen, in dem Inhalt in den Tresor eintritt, nicht für irgendetwas, das Sie vorher geändert haben.

Elena behielt ihre Archivkopie auf einem separaten Laufwerk, gezippt, mit dem Datum im Ordnernamen. Ihre Arbeitskopie saß neben ihrem neuen Tresor, während sie migrierte. Ihren lebenden Logseq-Graphen – denjenigen, den Logseq selbst noch öffnete – ließ sie bis ganz zum Schluss vollständig in Ruhe. Diese Dreifachtrennung, lebender Graph, Arbeitskopie, Archiv, klingt etwa einen Tag lang pingelig. Dann treffen Sie auf Ihre erste mehrdeutige Seite, gehen zum Archiv zurück, klären die Frage in zwei Minuten und stellen die Pingeligkeit nie wieder infrage.

Ein weiterer Vorbereitungsschritt gehört hierher. Klären Sie zuerst Ihren Sync-Zustand. Wenn Sie Logseq Sync oder eine Ordner-Synchronisation eines Drittanbieters wie iCloud Drive, Dropbox, Git oder Syncthing genutzt haben, oder sowohl auf einem Telefon als auch auf einem Computer bearbeitet haben, kopieren Sie keine Dateien, bis jedes Gerät denselben Graphen zeigt und keine Änderung noch unterwegs ist. Die wiederkehrende Geschichte in der Community ist ein Stillstand, der wie Erfolg aussieht: ein Status, der sagt, alles sei synchronisiert, während jüngste Bearbeitungen nicht angekommen sind. Von einem halb synchronisierten Graphen zu migrieren backt diese fehlende Arbeit als dauerhafte Abwesenheit in Ihren neuen Tresor ein. Bestätigen Sie, dass die Journale der letzten Tage auf allen Geräten übereinstimmen, lösen Sie etwaige Konfliktkopien auf, und nehmen Sie erst dann Ihre beiden Kopien.

Wenn Sie auf der Datenbankversion sind: zuerst exportieren, und wissen, was der Export verliert

Alles oben setzt voraus, dass Sie auf einen Ordner voller Markdown-Dateien zugehen können. Wenn Sie bereits zur Datenbankversion gewechselt sind, können Sie das nicht. Ihr Graph lebt in SQLite, und der erste Schritt Ihrer Migration ist ein Export – und Sie müssen in diesen Export mit klaren Augen darüber gehen, was er Ihnen nicht zurückgibt.

Nach dem, was Nutzer der Datenbankversion durchgängig berichten, führt ein Export nach Markdown den ursprünglichen Graphen nicht im Kreis zurück. Dateien kommen abgeflacht in einem einzigen Ordner heraus, sodass die Ordnerstruktur, die Sie oder Logseq pflegten – die Trennung von Seiten, Journalen und Assets, die einen Datei-Graphen lesbar macht –, verloren geht oder aus Dateinamen und Inhalt durch Rückschluss rekonstruiert werden muss. Assets sind der schärfere Verlust: Der Export konzentriert sich auf den Text, und angehängte Dateien werden nicht verlässlich mit herausgetragen, was exportierte Seiten zurücklässt, die auf PDFs und Bilder verweisen, die im Export gar nicht vorhanden sind. Spiegelartige Exporte haben Berichten zufolge ebenfalls auf einigen Seiten Daten vermissen lassen, ohne zu kennzeichnen, welche, und Importe in die andere Richtung – Markdown in die Datenbankversion – haben bei manchen Nutzern Fehler in Masse hervorgebracht, Seiten, die als Tags ankamen, und Seiten, die gar nicht ankamen.

Nichts davon macht Export nutzlos. Es macht Export zu einer Rettungsaktion statt zu einer ordentlichen Übergabe, und Sie sollten ihn entsprechend behandeln, auf drei bestimmte Arten.

Erstens: Exportieren Sie, und prüfen Sie dann den Export gegen den Datenbank-Graphen, solange Sie noch beide haben. Zählen Sie die exportierten Dateien. Durchsuchen Sie den Export nach Seiten, von denen Sie wissen, dass sie wichtig sind – Ihre am stärksten verlinkten Projektseiten, jüngste Journale, eine Seite in einem Namespace, eine Seite voller Anhänge, eine Seite mit Eigenschaften, Aufgaben und einem PDF –, und öffnen Sie jede einzelne, um zu bestätigen, dass der Inhalt vollständig ist, nicht abgeschnitten oder auf einen Titel reduziert. Sie stellen fest, ob die Fehler des Exports, falls es welche gibt, zufällig oder gemustert sind: Ein gemusterter Fehler lässt sich systematisch ausgleichen, während ein zufälliger bedeutet, dass Sie während der gesamten Migration stichprobenartig prüfen müssen.

Zweitens: Gleichen Sie die verlorene Ordnerstruktur aus, indem Sie die drei Stapel manuell neu aufbauen, bevor Sie irgendetwas migrieren: Journaldateien zusammen an ihren Datumsnamen, Asset-Verweise zusammen, gewöhnliche Seiten zusammen. Das ist mühsam, und es ist in einem Durchgang am Anfang, mit dem geöffneten Datenbank-Graphen daneben, weit leichter als auf halbem Weg durch VaultBook. Elenas Datei-Graphen-Route ersparte ihr diesen Schritt vollständig – der konkrete, gegenwärtige Wert davon, zu migrieren, solange die Markdown-Dateien noch die Originale sind.

Drittens: Jagen Sie Ihre Assets separat. Sie mögen noch im Speicher des Datenbank-Graphen existieren, in einem Backup, in dem Ordner, den Sie vor dem Versionswechsel synchronisierten, oder dort, wo Sie sie ursprünglich heruntergeladen haben. Listen Sie jedes Asset auf, auf das Ihre exportierten Seiten verweisen, prüfen Sie, welche Sie tatsächlich haben, und behandeln Sie die fehlenden als benannte Problemliste: Laden Sie die öffentlichen erneut herunter, fordern Sie die des Kunden erneut an, solange die Beziehung lebt, und kennzeichnen Sie wirklich Unwiederbringliche in den betroffenen Seiten während der Migration, damit ein künftiger Leser weiß, dass das Diagramm weg ist und warum, statt auf eine stille Lücke zu treffen.

Halten Sie auch den Fairness-Punkt fest: Die Datenbankversion hat echte Verteidiger – Eigenschaften und Supertags sind dort strukturierter, und manche Nutzer finden die Navigation schneller, sobald ein großer Graph geöffnet ist. Wenn das Ihre Erfahrung ist, mag Ihr Export sauberer sein als die schlimmsten Berichte. Prüfen Sie ihn trotzdem; die Methode ändert sich mit Optimismus nicht, sie endet nur schneller.

Die Arbeitskopie bereinigen — leicht, und nur, wo es sich lohnt

Mit erstellten Kopien und, falls nötig, geprüftem Export können Sie die Arbeitskopie aufräumen. Die Disziplin hier ist Zurückhaltung. Sie renovieren den Graphen nicht. Sie entfernen die bestimmten Arten von Unordnung, die sich vervielfachen, wenn sie mit einer Migration vervielfacht werden.

Reparieren Sie Dateinamen, die Ihnen im Weg stehen werden: voran- oder nachgestellte Leerzeichen, Zeichen, mit denen Ihre anderen Werkzeuge schlecht umgehen, und doppelte Namen, die sich nur in der Groß-/Kleinschreibung unterscheiden. Führen Sie echte Duplikate zusammen – dieselbe Kundenseite, zweimal unter zwei Schreibweisen erstellt, ist in einem vier Jahre alten Graphen üblich –, indem Sie ihren Inhalt in der Arbeitskopie in einer Datei vereinen und die Zusammenführung in einer Notizliste festhalten, damit Sie, wenn beide Namen anderswo als Links auftauchen, wissen, dass sie jetzt einen Ort meinen. Löschen Sie nichts anderes auf Verdacht. Leere Stumpfseiten, Ein-Zeilen-Seiten und Seiten, die wie Unfälle aussehen, erweisen sich oft als Linkziele, die einen Namespace zusammenhalten, oder als datierte Notiz, deren Bedeutung in ihren Backlinks lebt. In VaultBook-Begriffen werden sie zu sehr kurzen Einträgen, was harmlos ist. Ein Stumpf, den Sie löschten und auf den vierzig Blöcke zeigten, ist nicht harmlos.

Schließlich schreiben Sie sich ein einseitiges Migrations-Notizblatt — außerhalb des Graphen, in irgendeinem reinen Dokument — mit vier laufenden Listen, die Sie durchgehend ergänzen werden: zusammengeführte Seiten, fehlende Assets, Blockreferenzen, auf die es ankommt (Sie werden ihnen im Abschnitt über die harten Fälle unten ordentlich begegnen), und Abfragen, die einen Neuaufbau wert sind. Elenas Notizblatt begann während dieser Vorbereitungsphase mit elf Zusammenführungen und zwei fehlenden Assets, und es wurde zum nützlichsten Einzeldokument ihrer Migration. Jede spätere Verifikationsprüfung in diesem Leitfaden ist letztlich eine Prüfung gegen Listen, die hier begannen.

Logseq-Strukturen in VaultBook-Strukturen übersetzen

VaultBook ist kein Outliner, und dieser Leitfaden wird nichts anderes vortäuschen. Es gibt keine Blockebenen-Struktur, in die man übersetzen könnte, keine Graphenansicht, die auf der anderen Seite wartet, und keine Abfragesprache, in der man seine Abfragen neu ausdrücken könnte. Was VaultBook stattdessen bietet, ist eine andere, einfachere Menge von Strukturen — Einträge, Labels, Wiki-Links, Notizen, ein eingebauter Kalender, Kanban, Fällig- und Ablaufend-Verfolgung, vollständige Suche mit semantischer Frage-Antwort-Funktion, OCR und Anhangsindizierung sowie Versionsverlauf für alles — innerhalb einer einzigen verschlüsselten Datei mit null Netzwerkanfragen. Die Übersetzungsarbeit unten ist daher keine Formatumwandlung. Sie ist eine Reihe kleiner, ausdrücklicher Entscheidungen: Dieses Logseq-Ding wird zu jenem VaultBook-Ding, aus diesem Grund, unter Inkaufnahme dieses Unterschieds. Durchgearbeitet an Elenas Graphen, Struktur für Struktur, sehen diese Entscheidungen so aus.

Seiten werden zu Einträgen

Eine Logseq-Seite wird zu einem VaultBook-Eintrag. Der Markdown-Text der Seite wird zum Haupttext des Eintrags, der Seitenname wird zum Eintragstitel, und das Ganze wird aus Ihrer Arbeitskopie hineinkopiert oder eingefügt, Seite für Seite oder in kleinen Bündeln verwandter Seiten, die Sie auf einmal im Kopf behalten können. Das ist der ehrliche manuelle Weg, und es lohnt sich, unumwunden zu sagen, was er nicht ist: VaultBook hat unter seinen eingebauten Werkzeugen einen Obsidian-Import, aber es gibt keinen Ein-Klick-Logseq-Import, und nichts in diesem Leitfaden stützt sich auf einen solchen. Dass die Dateien reines Markdown sind, macht den manuellen Weg überhaupt erst gangbar — Sie entschlüsseln nie ein proprietäres Format, Sie beheimaten lediglich lesbaren Text neu.

In der Praxis braucht der Umzug drei Durchgänge über jede Seite. Erstens der Text: Kopieren Sie das Markdown hinein, dann lesen Sie es einmal als Prosa statt als Gliederung — ein Aufzählungspunkt, der in Wahrheit eine Überschrift war, wird zu einer Überschrift, untergeordnete Punkte, die in Wahrheit ein Absatz waren, werden zu einem Absatz, ein Block, der wirklich listenförmig ist, bleibt eine Liste. Sie schreiben keinen Inhalt um; Sie lassen ihn die Form annehmen, die er immer meinte. Zweitens das Mobiliar: Eigenschaften, Aufgabenmarkierungen und Abfrageblöcke werden herausgezogen statt blind mitkopiert, denn jedes übersetzt sich unten separat. Drittens die Verbindungen: Links, Tags und Asset-Verweise werden mit den als Nächstes behandelten Strukturen neu aufgebaut, während die ursprüngliche Seite noch neben dem neuen Eintrag geöffnet ist.

Elenas durchgearbeitetes Beispiel ist ihre Seite Hartwell — Q3 Pricing Research: sechs Wochen Interviewnotizen, Wettbewerberzahlen und eine laufende Synthese, gebaut als verschachtelte Blöcke unter datierten Überschriften. Als Eintrag wurden die datierten Überschriften zu echten Überschriften, die Interviewnotizen blieben als strukturierte Listen unter der Person, von der sie stammten, und die Synthese-Punkte — die sie immer als Prosa gelesen hatte, während sie an den Aufzählungszeichen vorbeischielte — wurden zu drei ordentlichen Absätzen. Nichts Wesentliches wurde hinzugefügt oder entfernt. Was sich änderte, war, dass jeder, der kalt an dieses Material kam, es von oben nach unten lesen konnte, ohne zuerst zu lernen, ihre Gliederungsgewohnheiten zu lesen. Die erste Seite in einer neuen Kategorie ist langsam; die zehnte ist Routine.

Namespaces und Tags werden zu Labels

Logseq gibt Ihnen zwei Organisationsmittel, die sich in der Praxis überschneiden: Namespaces, wobei ein Seitenname wie client/hartwell/research die Seite in eine Hierarchie stellt, und Tags, wobei #research oder eine Seite-als-Tag Seiten über Hierarchien hinweg versammelt. VaultBooks entsprechendes Mittel ist das Label, auf Einträge angewandt, und die Übersetzungsregel lautet, Labels beide Aufgaben erledigen zu lassen — flach, ausdrücklich und ohne zu versuchen, die Hierarchie als Ordner-Theater nachzubauen.

Nehmen Sie den Namespace an seinen Schrägstrichen auseinander. Jede bedeutsame Ebene wird zu einem Label. client/hartwell/research ergibt die Labels client, hartwell und research — oder, wo eine Ebene so breit ist, dass sie den halben Tresor etikettieren würde, trägt ein kombiniertes Label wie client-hartwell die Paarung, ohne den Rest zu fluten. Tags übersetzen sich eins zu eins: Ein Logseq-Tag, der Dinge wirklich versammelte, wird zum selben Wort als VaultBook-Label. Ein Logseq-Tag, das in Wahrheit ein Status, ein Datum oder ein übrig gebliebenes Experiment war, wird zum Kandidaten für das Notizblatt statt zu einem automatischen Label, denn Labels, nach denen Sie nie filtern, sind bloß Lärm in Uniform.

Elenas Beispiel zeigt das erforderliche Urteilsvermögen. Ihr Graph nutzte einen research/-Namespace für alles von Kundenarbeit bis zu persönlicher Lektüre, dazu Tags für Methoden — interview, desk-research, data — plus eine Handvoll Tags, die sie für ein Projekt im Jahr 2023 erfunden und nie wieder benutzt hatte. Ihr Label-Schema für den Tresor behielt die Methoden-Tags exakt so, wie sie waren, denn sie suchte wirklich nach ihnen. Der Namespace wurde zu zwei Labels, research und dem Kunden- oder Themennamen, sodass ein Eintrag nach Art, nach Besitzer oder nach beidem zusammen gefunden werden konnte. Die Ein-Projekt-Tags von 2023 wurden überhaupt nicht zu Labels; die fünf betroffenen Einträge bekamen eine Zeile in ihrem Text, die die alte Gruppierung notierte, und die Gruppierung selbst durfte in Rente gehen. Ihre Regel, die es wert ist, übernommen zu werden, war eine Frage: Werde ich je bewusst alles mit dieser Markierung hervorholen, für sich allein? Ja bedeutet Label. Nein bedeutet eine Erwähnung im Text, oder nichts.

[[Links]] werden zu Wiki-Links, und Backlinks werden zu verwandten Notizen

Dies ist die getreuste Übersetzung der ganzen Migration, denn die zugrunde liegende Idee ändert sich nicht. Ein Logseq-[[link]] zeigt per Name auf eine Seite. Ein VaultBook-Wiki-Link zeigt per Titel auf einen Eintrag. Wo die Seite zu einem Eintrag mit demselben Titel geworden ist, wird der Link als Wiki-Link zu diesem Eintrag neu aufgebaut, und er funktioniert so, wie man es erwartet: eine benannte Verbindung, im Text, der man folgen kann.

Die Arbeit ist daher vor allem Reihenfolge. Ein Link kann nur zuversichtlich neu aufgebaut werden, sobald sein Ziel als Eintrag existiert — ein Grund, warum die Phasenreihenfolge am Ende dieses Teils aktive Projekte, dichte Cluster stark verlinkter Seiten, zuerst stellt: Innerhalb eines Clusters entstehen Ziele schnell, und Links können unterwegs fertiggestellt werden. Für Links, die aus dem aktuellen Cluster hinauszeigen, lassen Sie den Linktext sichtbar und exakt — den Titel, in Klammern — und fügen ihn einer laufenden Linkliste auf Ihrem Notizblatt hinzu. Ein sichtbarer Platzhalter, den Sie später auflösen, ist gute Praxis; ein Link, der still gelöscht wird, weil sein Ziel unbequem war, ist ein kleiner Akt archivarischer Unehrlichkeit, an den Sie sich bei 3.800 Seiten nicht erinnern werden.

Backlinks verdienen ein eigenes Wort, denn Logseq-Nutzer stützen sich stark auf verlinkte Referenzen. VaultBook reproduziert Logseqs Panel verlinkter Referenzen nicht als solches, aber das Bedürfnis, dem es diente — was zeigt sonst noch hierher, und womit ist dies verbunden? — wird aus zwei Richtungen bedient: vollständige Suche, die jeden Eintrag findet, der einen Titel oder einen Satz erwähnt, auch durch OCR und indizierte Anhänge hindurch, und verwandte Notizen, die Verbindungen neben einem Eintrag an die Oberfläche bringen. Zusammen beantworten sie die praktischen Fragen: Wer zitiert diese Quelle, welche Projekte berührten diesen Kunden, wo sonst tauchte diese Zahl auf. Was sie Ihnen nicht geben, ist das automatische, erschöpfende, blockgenaue Panel — und die Einträge, bei denen diese Genauigkeit zählte, sind gewöhnlich diejenigen, die Blockreferenzen tragen, behandelt im nächsten Hauptabschnitt.

Elenas Beispiel ist eine Quelle, die sie ständig zitierte: eine einzelne Seite für einen Branchenpreisbericht, auf die Dutzende von Kundenseiten verlinkten. Im Tresor wurde sie zu einem Eintrag mit ihrem getreuen Titel, früh migriert, obwohl sie zu keinem aktiven Projekt gehörte, gerade weil so viel auf sie zeigte. Jeder Kundeneintrag baute, als er erstellt wurde, seinen Wiki-Link zum Berichtseintrag bei Sichtkontakt neu auf. Als alle Kundencluster fertig waren, durchsuchte sie den Tresor nach dem Titel des Berichts und verglich die Trefferzahl mit der Zahl verlinkter Referenzen, die sie sich vor Beginn aus Logseq notiert hatte. Die Zahlen stimmten überein. Dieser Vergleich — Backlink-Zahl vorher notiert, Suchtrefferzahl nachher geprüft — ist die billigste starke Verifikation in diesem ganzen Leitfaden, und es lohnt sich, ihn für Ihre fünf oder zehn am stärksten verlinkten Seiten durchzuführen, wer immer Sie sind.

Tägliche Journale werden zu datierten Einträgen plus dem Kalender

Journale sind die Stelle, an der Logseq-Nutzer am meisten fürchten, der Fluss lasse sich nicht nachbauen, und die Furcht verdient eine direkte Antwort: Die einzelnen Journaltage übersetzen sich vollkommen gut, und was neu aufgebaut werden muss, sind nicht die Tage, sondern die Gewohnheit um sie herum, was Gegenstand von Teil C ist. Für die strukturelle Übersetzung hier wird jede Journaldatei zu einem datierten Eintrag — der Titel trägt das Datum in einem konsistenten Format, das Sie einmal wählen und nie variieren —, der den Text jenes Tages mit derselben Drei-Durchgänge-Behandlung wie jede Seite hält: Gliederung an die Oberfläche geholt in lesbare Struktur, Mobiliar zur separaten Übersetzung herausgezogen, Links als Wiki-Links neu aufgebaut.

Die Konsistenz des Datumsformats ist nicht kosmetisch. Datierte Einträge plus VaultBooks eingebauter Kalender und seine Ansicht der zuletzt bearbeiteten Einträge sind der Weg, auf dem das Journal navigierbar wird: Der Kalender gibt Ihnen die Monatsform auf einen Blick, die Logseqs Journal-Strom Ihnen gab, die Zuletzt-Ansicht gibt Ihnen die gerade geschriebenen Tage der Reihe nach, und die Suche über datierte Titel gibt Ihnen jedes Journal, das einen Kunden, eine Person oder eine Entscheidung erwähnt. Wählen Sie ein Format, das beidem gerecht wird — Elena benutzte das ISO-Datum gefolgt von einem kurzen Label aus dem dominanten Thema des Tages, sodass ein Tag, der meist mit einem Kunden verbracht wurde, als Datum plus Name dieses Kunden liest —, und wenden Sie es ohne Ausnahme an, auch auf langweilige Tage. Ein Journalsystem mit Ausnahmen ist ein Ablagesystem; ohne sie ist es eine Zeitleiste.

Elenas durchgearbeitetes Beispiel ist ein gewöhnliches Donnerstagsjournal mitten im Projekt: eine Zusammenfassung eines Kundenanrufs, vier Aufgabenblöcke in verschiedenen Zuständen, ein eingefügter Absatz aus einem Bericht, den sie weiterverfolgen wollte, und eine zweizeilige Notiz über eine Rechnung. Als datierter Eintrag behielt es die Anrufzusammenfassung in voller Länge — mit Namen, Zahlen und der Entscheidung, exakt wie geschrieben —, wandelte die Rechnungsnotiz in einen verfolgten Posten nach den Regeln des nächsten Schritts um, behielt den eingefügten Absatz mit einem Wiki-Link zum Berichtseintrag, aus dem er stammte, und einer Zeile, warum sie ihn gespeichert hatte, und schickte seine vier Aufgaben ans Kanban. Zurückgelesen war der Eintrag kürzer als die Journaldatei und enthielt mehr brauchbare Information, was sich als das Muster für Journale überhaupt herausstellte: Gliederungserfassung überzeichnet den Prozess, und Übersetzung ist der Ort, an dem sich der Datensatz vom Prozessrauschen trennt.

TODO- und Aufgabenblöcke werden zu Kanban — und zu Fällig/Ablaufend

Logseq-Aufgaben leben als Blöcke, markiert TODO, DOING, DONE und ihre Verwandten, oft mit geplanten und Fristdaten, verstreut über Journale und Projektseiten, genau dort, wo die Arbeit gedacht wurde. VaultBooks lebende Aufgabenstruktur ist sein Kanban, unterstützt vom Kalender und der Seitenleiste mit Zuletzt/Fällig/Ablaufend, die zusammen die Aufgabe erledigen, die Logseqs Aufgabenansichten und Abfragen erledigten: zeigen, was offen ist, was sich bewegt und was gleich beißen wird.

Übersetzen Sie nach Zustand, nicht nach Ort. Jeder offene Aufgabenblock — TODO, DOING, wartend, wie immer Sie Nicht-Fertiges markiert haben — wird zu einer Kanban-Karte, betitelt mit dem eigenen Text der Aufgabe, platziert in der Spalte, die seinem Zustand entspricht, und mit einem Wiki-Link zurück zu seinem Quelleintrag verknüpft, damit Aufgabe und Begründung einander nie verlieren. Sein Frist- oder Plandatum wird zu einem Fälligkeitsdatum, das Fällig/Ablaufend an die Oberfläche bringen kann — dies zählt mehr als das Board selbst, denn ein Board, an dessen Besuch man sich erinnern muss, ist eine Liste, während ein ablaufender Posten, der sich selbst präsentiert, ein System ist. Fertige DONE-Blöcke werden meist überhaupt nicht zu Karten: Sie sind Geschichte, bewahrt als Text im Journal oder Projekteintrag, wo sie bereits sitzen. Vier Jahre abgeschlossener Aufgaben auf ein Board zu migrieren würde das eine neu erschaffen, was ein Board niemals sein darf: ein Archiv, an dem man vorbeiscrollt, um die heutige Arbeit zu sehen.

Elenas Beispiel verdichtet sich hübsch. Über ihr aktives Hartwell-Projekt verteilt fand sie Aufgabenblöcke auf der Projektseite und in elf verschiedenen Journalen: sechsundzwanzig offene in irgendeiner Form, über hundert abgeschlossene. Die sechsundzwanzig wurden zu einundzwanzig Karten — fünf erwiesen sich beim Lesen als gegenseitige Duplikate, geschrieben an stressigen Tagen, was das Notizblatt festhielt —, sortiert über ihr Board als zu tun, in Arbeit und auf Kunden wartend, mit den zwei harten Fristen als Fälligkeitsdaten gesetzt. Die abgeschlossenen hundert blieben, wo sie hingehörten, in den datierten Einträgen und dem Projekteintrag, als Gedächtnis des Projekts. Ihr Test, ob die Übersetzung funktioniert hatte, war brutal praktisch: Am ersten Montag nach dieser Phase zeigte ihr Fällig/Ablaufend die Hartwell-Zwischenfrist, ohne dass sie das Board öffnete, das Board oder ein einziges Journal. In Logseq hatte das Hervorholen derselben Tatsache still von einer Abfrage abgehangen, die sie vor zwei Jahren geschrieben hatte und sich halb erinnerte zu pflegen — was die Übersetzung zu ihrem heikelsten Posten bringt.

Eigenschaften werden zu Eintragsfeldern und Labels

Logseq-Eigenschaften — die Schlüssel-Wert-Paare am Kopf einer Seite oder angehängt an einen Block, client::, status::, source-type:: und ihre Verwandten — tragen in einem reifen Graphen echte Information, und sie tragen auch eine Menge Ritual. Die Übersetzung sortiert sie in drei Schicksale.

Eigenschaften, die klassifizieren, werden zu Labels. client:: hartwell ist ein Label in Schlüssel-Wert-Kleidung; source-type:: interview ebenso — wenn Sie je nach dem Wert filtern würden, ist es ein Label. Eigenschaften, die eine Tatsache feststellen, werden Teil des Eintrags selbst, als kurzer Faktenblock in lesbarer Prosa oder als ordentliche Liste: ein Interviewdatum, der volle Name hinter einer Abkürzung, die vereinbarte Vergütung, der Status in Worten. Innerhalb des Eintrags ist diese Tatsache durchsuchbarer reiner Text, den ein Mensch beim Öffnen lesen kann, keine Metadaten, die nur ein eigenschaftsbewusstes Werkzeug sehen kann. Eigenschaften, die in Wahrheit Aufgabenmaschinerie waren — Prioritäten, Planungsmarkierungen —, gehen mit den Aufgaben ans Kanban oder verfallen, wenn die Aufgabe erledigt ist. Eigenschaften, die alle drei Tests nicht bestehen, hinzugefügt, weil eine Vorlage sie hinzufügte, und nie ein einziges Mal konsultiert, kommen als fallengelassen aufs Notizblatt. Sie fallen zu lassen ist kein Datenverlust; es ist Gerüst, das von einem stehenden Gebäude abfällt.

Elenas Hartwell-Seite trug acht Eigenschaften. Drei wurden zu Labels: der Kunde, die Projektphase und die Rechercheart. Drei wurden zu einem Faktenblock am Kopf des Eintrags: Mandatsdaten, vereinbartes Lieferergebnis und der Hauptkontakt — Informationen, die sie zuvor ohne Logseqs Eigenschaften-Darstellung nicht hatte sehen können, nun schlicht das Erste, was der Eintrag sagt. Eine, eine Prioritätsmarkierung, ging auf die Kanban-Karte für die wichtigste offene Aufgabe des Projekts. Eine, ein Alt-Feld aus einer Vorlage, die sie 2022 aufgegeben hatte, wurde fallengelassen und verzeichnet. Acht Eigenschaften, vier Schicksale, keine Information unverbucht: Diese Verbuchung — jede Eigenschaft entweder etikettiert, eingeschrieben, ans Board getragen oder bewusst auf der Liste fallengelassen — ist der Maßstab für jede Seite, auf der Eigenschaften Gewicht tragen. Auf den Hunderten von Seiten, auf denen Eigenschaften trivial oder abwesend sind, dauert dieselbe Verbuchung Sekunden. Lassen Sie sich von der trivialen Mehrheit nicht davon abbringen, sie für die gewichtige Minderheit ordentlich zu tun, denn die gewichtige Minderheit ist definitionsgemäß der Graph, von dem aus Sie Ihre Arbeit tatsächlich betreiben.

Die harten Fälle ehrlich behandeln

Jeder Migrationsleitfaden hat einen Abschnitt, den er lieber überspringen würde. Dies ist jener Abschnitt, und er ist der Grund, warum dieser Leitfaden auf dem Wort ehrlich in seiner Herangehensweise besteht. Drei Logseq-Strukturen haben in VaultBook kein gleichartiges Zuhause: Blockreferenzen und Einbettungen, Abfragen und das Paar aus Whiteboards und Karteikarten. Etwas anderes vorzutäuschen würde einen Tresor erzeugen, der migriert aussieht und sich kaputt verhält. Sie gut zu behandeln bedeutet, für jede einzelne zu entscheiden, was die Struktur tatsächlich für Sie getan hat — und diesem Bedürfnis dann anders zu begegnen, sie bewusst zu archivieren oder sie aktenkundig ziehen zu lassen.

Blockreferenzen und Einbettungen: von lebenden Spiegeln zu ausdrücklichen Links und kopiertem Kontext

Blockreferenzen sind der am häufigsten genannte Verlust, wenn Logseq-Nutzer das Weggehen beschreiben, und die Berichte haben recht: VaultBook hat keine Blockreferenzen, keine Block-Einbettungen und keine Outliner-Struktur, auf die sie sich beziehen könnten. Eine Logseq-Blockreferenz tat zwei Dinge zugleich. Sie zeigte — dieser Gedanke gehört zu genau jenem Block dort drüben — und sie spiegelte, zeigte den Inhalt des Blocks in seinem neuen Zuhause an und aktualisierte überall, wenn sich das Original änderte. Nichts in VaultBook spiegelt. Was VaultBook verlässlich kann, ist die ehrliche Version des Zeigens: ein ausdrücklicher Wiki-Link, begleitet von genug kopiertem Kontext, dass der neue Ort für sich allein Sinn ergibt.

Übersetzen Sie jede Referenz, die Sie zu behalten beschließen, in dieser Form: die Notiz im neuen Eintrag, so neu formuliert, dass sie für sich allein steht; die Schlüsselzeile oder Zahl aus dem referenzierten Block, hineinkopiert als Zitat oder schlichte Feststellung; und ein Wiki-Link zum Eintrag, der nun den ursprünglichen Block hält, platziert dort, wo die Behauptung verwendet wird. Eine Einbettung übersetzt sich auf dieselbe Weise in größerem Maßstab: Kopieren Sie den Abschnitt hinein, wenn der empfangende Eintrag ihn wirklich enthalten muss, oder ersetzen Sie sie durch einen Zeige-Absatz, der zusammenfasst, was sie sagt, und darauf verlinkt. Was Sie verlieren, ist automatische Aktualisierung — kopierter Kontext folgt späteren Änderungen nicht. Was Sie gewinnen, ist, dass jeder Eintrag selbstgenügsam wird: lesbar, durchsuchbar und verständlich, ohne eine Kette von Verweisen in einen Outliner hinein aufzulösen, den es nicht mehr gibt. Der Versionsverlauf deckt Veränderungen ehrlich ab: Wenn ein Quelleintrag überarbeitet wird, suchen Sie nach der zitierten Zeile, um die Einträge zu finden und zu aktualisieren, die sie zitierten, als bewusste Bearbeitung statt als stille Verbreitung.

Sie können dies nicht für jede Referenz tun, und Sie sollten es nicht versuchen. Ein vier Jahre alter Graph enthält Tausende von Blockreferenzen, die meisten davon Arbeitsbequemlichkeiten des Moments — eine Journalzeile, für eine Woche in eine Projektseite gezogen, ein Block, gespiegelt, während sich ein Entwurf formte —, deren Spiegelungsaufgabe längst endete. Also triagieren Sie, mit einer Regel, die einfach genug ist, um sie im Tempo anzuwenden: Eine Referenz zählt, wenn die empfangende Seite ohne den referenzierten Inhalt falsch, irreführend oder unverständlich wäre. Wenden Sie drei schnelle Tests an, während Sie jeder begegnen. Würde ein Leser dieses Eintrags, allein, ohne ihn etwas missverstehen? Trägt er eine Zahl, eine Entscheidung oder eine Verpflichtung, auf die sich andere Arbeit stützt? Ist der ursprüngliche Block der einzige Ort, an dem dieser Inhalt existiert? Ja zu irgendeinem bedeutet, die Referenz gehört zu den wenigen, die zählen: Bauen Sie sie als Link plus kopierten Kontext neu auf und notieren Sie sie auf Ihrem Notizblatt. Nein zu allen dreien bedeutet, die Referenz war Gerüst: Lassen Sie den empfangenden Eintrag auf seinem eigenen Text stehen, behalten Sie den sichtbaren Titel des Referenzierten als schlichte Erwähnung, wo das hilft, und gehen Sie ohne Schuld weiter.

Elenas Triage ist in ihren Proportionen lehrreich. Bei der Stichprobe ihrer aktiven Projekte und eines Monats Journale fand sie Blockreferenzen überall — und weniger als eine von zehn bestand irgendeinen der drei Tests. Die, die bestanden, waren konzentriert und vorhersehbar: Zahlen aus Quellenseiten, zitiert in Kundensynthesen, Entscheidungen aus Journalen, eingebettet in Projektseiten, und eine kleine Menge von Definitionsblöcken, die sie über ihre ganze Praxis hinweg wiederverwendet hatte. Diese baute sie sorgfältig neu auf. Den Rest — die tägliche Klempnerei eines Outliners bei der Arbeit — ließ sie in einem einzigen Durchgang gehen, und nichts, was sie seitdem produziert hat, hat sie vermisst. Wo sie den Verlust spürte, spürte sie ihn ehrlich und konkret: Eine lebend aktualisierende Zahl wäre im folgenden Monat zweimal bequem gewesen, und jedes Mal dauerte das Hineinkopieren der überarbeiteten Zahl von Hand Minuten und hinterließ einen Versionsdatensatz der Änderung. Verzeichnen Sie diesen Tausch in Ihrem eigenen Kopf auf dieselbe Weise. Blockreferenzen sind ein echter Verlust mit einem gangbaren Ersatz für die Minderheit, die zählte, kein Grund, warum die Migration scheitert.

Abfragen: Bauen Sie die wenigen als gespeicherte Suchen und Label-Ansichten neu auf — und lassen Sie den Rest absichtlich fallen

Eine Logseq-Abfrage ist ein kleines Programm: Zeige mir Blöcke oder Seiten, die diesen Eigenschaften, diesen Tags, dieser Datumslogik, diesem Aufgabenzustand entsprechen. VaultBook hat keine Datalog-Abfragen und keine Abfragesprache, und kein Trick mit gespeicherten Suchen in diesem Abschnitt sollte als Äquivalent verkleidet werden. Was VaultBook hat, ist eine Kombination, die das meiste von dem abdeckt, was Abfragen im Alltag tatsächlich lieferten: vollständige Suche — einschließlich semantischer Frage-Antwort-Funktion, sodass Sie Material nach Bedeutung ebenso wie nach exakter Wortwahl erbitten können — plus Labels, die Einträge zu Ansichten versammeln, plus Kalender, Zuletzt, Fällig/Ablaufend und Kanban für die Datums- und Zustandsfragen. Die meisten Arbeitsabfragen waren, genau gelesen, stehende Fragen weniger wiederkehrender Arten, und jede Art hat in jener Kombination ein Zuhause.

Eine Abfrage, die alles über X versammelte — einen Kunden, ein Thema, eine Quelle —, wird zu einer Label-Ansicht, wenn X ein Label nach der früheren Regel verdient, oder zu einer gespeicherten Suchgewohnheit, wenn nicht: Suchen Sie nach dem Titel oder Begriff, und lassen Sie OCR und Anhangsindizierung das Netz weiter werfen, als die Abfrage je sehen konnte, denn die Abfrage sah nie in Ihre PDFs hinein. Eine Abfrage, die fragte, was braucht mich — offene Aufgaben, nahende Fristen —, wird überhaupt nicht neu aufgebaut, denn Kanban und Fällig/Ablaufend beantworten sie strukturell. Eine Abfrage, die fragte, was habe ich jüngst über Y erfasst, wird zu Zuletzt plus einem Suchbegriff. Und eine Abfrage, deren Antwort Sie ohne die Abfragesyntax nicht in schlichten Worten beschreiben können — die verwickelten Konstruktionen, die Langzeitnutzer ansammeln, manchmal zu Hunderten, und dann wie ein zweites System über ihren Notizen pflegen —, ist fast immer ein Kandidat zum Fallenlassen: Eine stehende Frage, die Sie nicht schlicht formulieren können, ist gewöhnlich eine, die Sie tatsächlich aufgehört haben zu stellen.

Sortieren Sie Ihre Abfragen so, wie Elena die ihren sortierte, auf dem Notizblatt, in drei ausdrückliche Listen, bevor Sie irgendeine von ihnen neu aufbauen. Als Label oder Suche neu aufbauen: stehende Fragen, die Sie wöchentlich oder öfter stellten und in einem Satz formulieren können. Strukturell beantwortet: die Aufgaben-, Datums- und Aktualitätsfragen, die Board, Kalender und Seitenleiste jetzt erledigen. Absichtlich fallengelassen: alles andere, benannt mit einem Wort darüber, was es einst tat, damit die Entscheidung verzeichnet ist. Ihr Muster entsprach dem, was andere Nutzer beim Prüfen ihrer eigenen Systeme beschreiben: ein kleiner Kern neu aufgebaut, ein solides Band strukturell beantwortet, ein langer Schwanz fallengelassen, ohne vermisst zu werden. Beziehen Sie das Gegengewicht ein: Manche Nutzer schätzen das Abfragesystem selbst und erhalten präzise, blockgenaue Antworten, denen keine Label-Ansicht gleichkommen wird. Wenn das in diesem Monat wirklich Sie sind — nicht historisch Sie —, sind jene verlorenen Abfragen ein echter Preis, der in der Migrationsentscheidung selbst abzuwägen ist. Bauen Sie Abfragen erst neu auf, nachdem das Material, über das sie sich erstreckten, migriert ist; eine gespeicherte Suche, getestet an einem halbleeren Tresor, lehrt die falsche Lektion.

Whiteboards und Karteikarten: kein Äquivalent — archivieren, exportieren oder ziehen lassen

Sagen Sie es ohne Ausschmückung: VaultBook hat keine Whiteboards und keine Karteikarten. Es gibt keine räumliche Leinwand, die ein Logseq-Whiteboard aufnehmen könnte, und kein System verteilter Wiederholung, das ein Karteikarten-Deck aufnehmen könnte. Jeder Leitfaden, der eine gleichwertige Umgehung andeutet, führt Sie in die Irre, also ist die Entscheidung hier eine archivarische, getroffen Board für Board und Deck für Deck, solange Logseq Ihnen noch zeigen kann, worüber Sie entscheiden.

Fragen Sie bei jedem Whiteboard, wozu es da war. Ein Board, das eine Denksitzung war — ein Kundenproblem, einmal kartiert, eine Struktur, für einen Artikel skizziert —, hat seine Arbeit gewöhnlich getan, und seine Schlussfolgerung lebt in den Seiten, die es formte: Exportieren Sie es als Bild, legen Sie dieses Bild als Anhang an seinen Eintrag (anschaubar im Photo/Video Explorer), und lassen Sie das Board in Rente gehen. Ein Board, das noch als lebende Referenz benutzt wird, verdient einen Schritt mehr: Exportieren Sie das Bild, und schreiben Sie seinen Inhalt außerdem als strukturierten Text in seinen Eintrag aus, wobei Überschriften und Listen die Gruppierungen tragen, die das Board räumlich trug — ein Bild bewahrt, wie es aussah, Text bewahrt, was es sagte, durchsuchbar und verlinkbar. Ein Board, das reiner Prozess war, braucht nur eine Zeile auf dem Notizblatt. Bei Karteikarten ist die Logik kälter. Ein Deck, das Sie aktiv wiederholten, ist eine Lernpraxis, kein Dokument, und Praktiken migrieren nicht in einen Tresor ohne Wiederholungssystem: Behalten Sie diese Praxis entweder in einem eigenen Werkzeug außerhalb des Tresors — eine Wahl, die viele glücklich treffen —, oder exportieren Sie den Inhalt des Decks in einen Eintrag als Frage-Antwort-Datensatz, wobei Sie akzeptieren, dass Sie das Wissen archiviert und das Abfragen beendet haben. Ein Deck, dessen Wiederholung Sie eingestellt hatten, braucht nur die zweite Hälfte dieser Wahl: seinen Inhalt als Text, wenn das Wissen zählt, nichts, wenn nicht.

Elena hatte sechs Whiteboards und ein Lesenotizen-Deck, das sie seit über einem Jahr nicht geöffnet hatte. Zwei Boards wurden zu Bild-plus-Text-Einträgen (eine Marktkartierung, die sie noch konsultiert, und das Strukturboard für eine lange Artikelserie). Drei wurden zu Nur-Bild-Anhängen. Eines wurde zu einer Notizblatt-Zeile. Das Deck wurde zu einem einzigen Frage-Antwort-Eintrag unter ihren Lese-Labels — noch nützlich als Referenz, ehrlicherweise kein Deck mehr. Gesamtzeit: ein konzentrierter Nachmittag. Gesamtverlust, schlicht benannt: das räumliche Gefühl der lebenden Boards und die Abfragegewohnheit, die sie in Wahrheit schon verloren hatte, bevor sie migrierte.

Assets umziehen: PDFs, Bilder und Audio

Assets sind der Teil des Graphen, auf den Ihre Markdown-Dateien nur zeigen, und sie sind der Ort, an dem VaultBook aufhört, Ihr altes Material bloß zu empfangen, und anfängt, Dinge damit zu tun, die Logseq nie tat. Ziehen Sie sie bewusst um, Typ für Typ, nachdem die Einträge existieren, die auf sie verweisen — damit jedes Asset in einem Zuhause landet, nicht auf einem Haufen.

PDFs: konsolidieren, teilen, komprimieren — und dann die Indizierung arbeiten lassen

Sammeln Sie jedes PDF aus Ihrem assets/-Ordner und von dort, wo die Datenbank-Export-Jagd die Streuner fand. Für jedes ist der empfangende Eintrag die Seite, die es annotierte oder zitierte. VaultBooks eingebaute PDF-Werkzeuge verändern die Hauswirtschaft um diesen Umzug herum. Jahre der Logseq-Nutzung hinterlassen charakteristische Unordnung: derselbe Bericht, dreimal in drei Größen gespeichert, ein 200-seitiges Dokument, von dem ein Kapitel zählte, drei Anhänge, die in Wahrheit ein Dokument sind. Die Werkzeuge zum Zusammenführen, Teilen und Komprimieren beheben das an der Tür, statt die Unordnung getreu zu importieren: Führen Sie die Anhänge zusammen, teilen Sie die lange Datei, damit das zitierte Kapitel als eigener Anhang dasteht, komprimieren Sie aufgeblähte Scans, damit ein Tresor aus einer einzigen Datei eine vernünftige Größe behält. Tun Sie es pro Eintrag, während Sie ihn erreichen — welchen Teil dieses PDFs braucht dieser Eintrag? lässt sich nur mit geöffnetem Eintrag beantworten.

Dann lassen Sie den Tresor in sie hineinsehen. VaultBooks Suche deckt OCR und Anhangsindizierung ab, was bedeutet, dass ein an einen Eintrag gehängtes PDF keine tote Datei mit hoffnungsvollem Dateinamen ist: Sein Text wird von derselben Suche auffindbar, die Sie für Einträge nutzen, und die semantische Frage-Antwort-Funktion kann ihn neben Ihren Notizen heranziehen. Für Elena, deren Kundenarbeit auf langen Berichten ruhte, die sie zuvor durchsuchte, indem sie sie einen nach dem anderen in Logseqs Annotationsansicht wieder öffnete, veränderte dies still den Wert ihres Archivs: Eine Zahl, begraben auf Seite 140 eines angehängten Berichts, taucht nun aus einer tresorweiten Suche auf, angehängt an den Eintrag, der erklärt, warum sie zählt. Ihre PDF-Annotationen aus Logseq brauchen hier einen ehrlichen Satz: Annotationen, die innerhalb von Logseq gemacht wurden, leben in Logseqs Strukturen, nicht in der PDF-Datei selbst in irgendeiner Form, auf die Sie sich verlassen sollten, also gehört die Substanz der Annotationen, die zählen — der hervorgehobene Befund, in Ihren Worten — in den Text des empfangenden Eintrags, geschrieben während der Migration, während das annotierte Original neben Ihnen geöffnet ist. Das PDF reist. Das Denken über das PDF reist als Prosa. Keines von beiden bleibt auf ein Werkzeug zeigen, das Sie nicht mehr öffnen.

Bilder: Photo/Video Explorer und EXIF

Bilder ziehen als Dateien um, angehängt an ihre empfangenden Einträge, wobei ein VaultBook-Werkzeug die Organisationsarbeit erledigt, die Logseqs Assets-Ordner nie konnte: der Photo/Video Explorer, der Ihre Bilder und Videos visuell durchstöbert und ihre EXIF-Daten liest. Das zählt für einen Recherche-Graphen mehr, als es klingt. Screenshots, Fotografien von Dokumenten und Whiteboards (einschließlich der exportierten Boards aus dem vorigen Abschnitt), als Bilder gespeicherte Diagramme und Fotografien von Ortsbesuchen kommen in den meisten Graphen als undatierte, unetikettierte Dateien mit kameragenerierten Namen an. Im Explorer geben Ihnen die EXIF-Daten und -Details eine echte Chance, ein Bild wieder an dem Tag und Ort zu verankern, von dem es stammte, und das visuelle Durchstöbern lässt Sie auf einen Blick bestätigen, welches von drei nahezu identischen Diagrammbildern die endgültige Fassung ist, die ein Eintrag halten sollte. Eingebaute Player decken die Videoseite auf dieselbe Weise ab: Ein an einen Eintrag gehängter Clip spielt dort, wo er sitzt, statt Sie in einen Ordner zu schicken.

Audio: Schneider, Verbinder und lokale Transkription

Audio ist der Punkt, an dem die Migration am sichtbarsten Fähigkeit hinzufügt. Interviewaufzeichnungen, Besprechungsmitschnitte und Sprachnotizen in einem assets/-Ordner sind in Logseq abspielbare Anhänge und nichts weiter — undurchsuchbar, ohne manuelle Transkription nicht zitierfähig, für den Rest des Graphen faktisch unsichtbar. In VaultBook kann jede Aufzeichnung, an ihren Eintrag gehängt, eingebettet abgespielt, mit dem eingebauten MP3 Cutter & Joiner (MP3-Schneider & -Verbinder) beschnitten oder kombiniert werden — ein zweiteiliges Interview wird zu einer Datei, die toten Eröffnungsminuten einer langen Aufzeichnung kommen herunter — und mit der eingebauten Whisper-Transkription lokal transkribiert werden, vollständig auf Ihrer Maschine, im Einklang mit einem Tresor, der null Netzwerkanfragen stellt. Das Transkript kommt in den Eintrag (oder in einen eigenen Eintrag, in beide Richtungen per Wiki-Link verknüpft), wo es zu dem wird, was Audio in einem Notizsystem immer hätte sein sollen: durchsuchbarer, zitierfähiger und belegbarer Text, mit der Aufzeichnung als Autorität dahinter bewahrt.

Seien Sie präzise über den Arbeitsablauf, denn er ist manuell wie der Rest dieser Migration: Es gibt keine automatische Transkription Ihres ganzen Assets-Ordners. Sie wählen die Aufzeichnungen, die zählen — für eine Forscherin die Interviews und Besprechungen, in denen Entscheidungen gesprochen statt geschrieben wurden — und transkribieren diese, Eintrag für Eintrag, während ihre Phase eintrifft. Elena transkribierte elf ihrer rund vierzig Aufzeichnungen im ersten Durchgang: jedes Kundeninterview für aktive Projekte, keine der Umgebungsaufnahmen, die sie bereits vollständig in Journalen niedergeschrieben hatte; diese blieben als reine Audio-Anhänge, ihr Inhalt bereits als datierte Einträge im Tresor. Diese Regel — transkribieren, was nirgends als Text existiert; bloß anhängen, was es bereits tut — hielt die Audio-Phase bei Tagen statt Wochen, und sie zahlte sich das erste Mal aus, als eine Suche die eigene Formulierung eines Kunden aus einem Interview an die Oberfläche brachte, das sie sonst hätte langwierig erneut anhören müssen.

Schließen Sie die Asset-Phase mit der Liste fehlender Assets von Ihrem Notizblatt ab, Zeile für Zeile erneut besucht: gefunden und angehängt, von seiner Quelle ersetzt oder in seinem Eintragstext als fehlend gekennzeichnet. Eine Asset-Migration ist nicht fertig, wenn der Ordner leer ist, sondern wenn jeder Verweis in jedem migrierten Eintrag entweder auf eine Datei im Tresor zeigt oder einen ehrlichen Vermerk trägt, der erklärt, warum nicht.

Eine Phasenreihenfolge der Arbeit — und wie jede Phase zu verifizieren ist

Niemand migriert 3.800 Seiten in einer Sitzung, und der Versuch, sie in Ordnerreihenfolge zu migrieren — Seite eins bis Seite dreitausendachthundert, Journale, wann immer Sie sie erreichen — ist der verlässlichste einzelne Weg, eine Migration bei Seite vierhundert zu blockieren, ohne auf irgendeiner Seite etwas Brauchbares. Ordnen Sie die Arbeit stattdessen nach Nützlichkeit. Der Tresor sollte nach der ersten Phase für Ihre wichtigste Arbeit echt lebendig sein und nach jeder folgenden Phase bloß unvollständig. Elenas Reihenfolge, verallgemeinert, hat vier Phasen, und die Journale — kontraintuitiv für ein journalzentriertes Werkzeug — kommen zuletzt.

Phase eins: aktive Projekte zuerst. Migrieren Sie die Seiten, Aufgaben, Assets und Personen der Arbeit, die Sie in diesem Monat tun, als vollständige Cluster: Die Projektseite wird ihr Eintrag, ihre Kinder in Namespaces und verlinkten Quellen folgen, ihre offenen Aufgaben werden zu Kanban-Karten mit Fälligkeitsdaten, ihre PDFs und Aufzeichnungen ziehen um und werden indiziert und nach Bedarf transkribiert. Aktive Arbeit zuerst bedeutet, dass jede Übersetzungsregel in diesem Leitfaden sofort an Material getestet wird, dessen Richtigkeit Sie beurteilen können — Sie wissen, was die Hartwell-Synthese sagen sollte —, und es bedeutet, dass der neue Tresor seinen Platz in Ihrem Tag zu verdienen beginnt, während der alte Graph noch daneben existiert. Verifizieren Sie Phase eins hart (die Prüfungen unten), denn jede spätere Phase wiederholt ihre Muster.

Phase zwei: stehende Referenz. Ihre am stärksten verlinkten Seiten, Ihre wiederkehrenden Quellen, Ihre Personen- und Organisationsseiten, Ihre zu Referenz gewordenen Vorlagen, das Rückgrat Ihres Label-Schemas. Vieles davon wird während Phase eins bereits als Linkziele angekommen sein; Phase zwei vollendet es als Einträge eigenen Rechts und regelt die Labels über den ganzen Kern hinweg. Phase drei: jüngere Geschichte. Journale und Projektmaterial aus ungefähr dem letzten Jahr — jung genug, um konsultiert zu werden, alt genug, um Geschichte zu sein —, mit abgeschlossenen Aufgaben als Text zurückgelassen, Assets angehängt und den wenigen Blockreferenzen, die die Triage bestehen, neu aufgebaut. Phase vier: Journale in Masse und das tiefe Archiv. Die verbleibenden Journale, ältesten Seiten und der lange Schwanz, schneller und leichter migriert: datierte Einträge mit getreuem Text und funktionierenden Wiki-Links, per Liste fallengelassen die Abfragen und Referenzen, die die Tests nicht bestehen, kurze Einträge für Stumpfseiten akzeptiert. Tiefes Archivmaterial verdient Geschwindigkeit statt genauer Prüfung, denn seine realistische Zukunft ist, gelegentlich durchsucht zu werden, nicht erneut gelesen — und die Suche arbeitet auf getreuem Text, egal wie schnell er bewegt wurde.

Führen Sie nach jeder Phase dieselben fünf Verifikationsprüfungen durch, bevor Sie die nächste beginnen. Erstens, Zählungen: in der Phase erwartete Seiten gegen erstellte Einträge, jede Differenz erklärt durch eine Zusammenführung oder ein Fallenlassen auf dem Notizblatt — keine unerklärte Arithmetik, jemals. Zweitens, Linkintegrität: Suchen Sie nach Platzhaltermarkierungen und unaufgelösten eingeklammerten Titeln, lösen Sie jeden auf oder listen Sie ihn bewusst, und wiederholen Sie die Prüfung der am stärksten verlinkten Seiten — Backlink-Zahl aus Logseq notiert gegen Suchtrefferzahl im Tresor — für jeden Hub, den die Phase berührte. Drittens, Assets: Öffnen Sie eine Stichprobe von Einträgen und folgen Sie jedem Anhang, dann suchen Sie nach einer unverwechselbaren Formulierung aus dem Inneren eines angehängten PDFs und einer transkribierten Aufzeichnung, und beweisen Sie, dass OCR, Indizierung und Transkription tatsächlich ankamen. Viertens, Systeme: Bestätigen Sie, dass die Aufgaben der Phase auf dem Board mit Fälligkeitsdaten stehen, Fällig/Ablaufend und der Kalender zeigen, was sie sollten, und die neu aufgebauten Label-Ansichten oder gespeicherten Suchen der Phase sich am nun vorhandenen echten Inhalt wie erwartet verhalten. Fünftens, Stichprobenlesen auf Wahrheit: Wählen Sie drei Einträge zufällig und einen, von dem Sie wissen, dass er heikel ist — eine zahlenreiche Synthese, einen Entscheidungsdatensatz —, und lesen Sie sie vollständig gegen die Archivkopie, wobei Sie Zahlen, Namen, Daten und Zitate Zeichen für Zeichen prüfen. Eine Migration scheitert nicht in Masse; sie scheitert an einer falschen Zahl, die niemand erneut prüfte.

Verriegeln Sie jede fertige Phase auf die schlichteste verfügbare Weise: Notieren Sie ihre Vollendung und ihre Prüfergebnisse auf dem Notizblatt, und verlassen Sie sich von hier an auf VaultBooks Versionsverlauf für den Inhalt im Tresor, während die unberührte Archivkopie des Graphen die Autorität für alles davor bleibt. Elena führte vier Phasen über drei Wochen Abende aus, mit ihrer aktiven Kundenarbeit am Ende der ersten Woche vollständig lebendig im Tresor und ihren Journalen — dem vierjährigen Rückgrat ihres Logseq-Lebens — zuletzt ankommend, in einem System, dessen Labels, Links, Board und Suche bereits bewiesen waren und auf sie warteten. Der Graph, dessen Verlust sie fürchtete, wurde, Phase für verifizierte Phase, zu einem Tresor, dem sie bereits vertrauen konnte, bevor er auch nur vollständig war. Was blieb, war überhaupt kein Umziehen mehr, sondern das Leben dort: die tägliche Journalgewohnheit, die Erfassungsroutinen und die Arbeitsrhythmen neu aufzubauen, die ein Graph still bereitstellte — und es diesmal in Strukturen zu tun, die sie eine nach der anderen gewählt hatte.

Die täglichen Arbeitsabläufe in VaultBook neu aufbauen

Die Dateien umzuziehen ist nur eine halbe Migration. Die andere Hälfte — die Hälfte, die entscheidet, ob Sie das neue System im März noch benutzen — ist, ob Ihre Morgen noch funktionieren.

Diese Furcht ist nicht allein ihre. In Faden nach Faden von Menschen, die erwogen haben, Logseq zu verlassen — oder gegangen und zurückgekommen sind — wird der Journal-Fluss als eines der am schwersten anderswo nachzubauenden Dinge benannt. Nicht das Dateiformat. Nicht die Links. Der Fluss. Das Gefühl, dass der heutige Tag eine Seite hat, dass diese Seite bereits auf einen wartet und dass alles, was man hineintippt, da sein wird, wenn man auf einem anderen Gerät zurückkommt, oder nach dem Mittagessen, oder nach einem Absturz. Diesen Fluss neu aufzubauen, ehrlich und ohne vorzutäuschen, VaultBook sei ein Outliner, ist der Punkt, an dem Teil C beginnt.

Die Journalgewohnheit: datierte Einträge, der Kalender und die Zuletzt-Seitenleiste

Ihre neu aufgebaute Gewohnheit sieht so aus. Jeden Morgen erstellt sie — oder öffnet sie — einen Eintrag, datiert auf heute. Der Titel trägt das Datum und ein kurzes Arbeitslabel: der Tag plus der Kunde oder das Projekt, das ihn dominieren wird. Das zählt mehr, als es klingt. In Logseq war das Datum allein der Titel, und der Inhalt musste einem sagen, worum an dem Tag gegangen war. In VaultBook kann sie eine Woche von Eintragstiteln in der Seitenleiste überfliegen und die Form der Woche auf einen Blick sehen: welche Tage Kundenliefertage waren, welche Lesetage, welche Verwaltung. Der Eintrag selbst ist ein Dokument, keine Gliederung. Sie schreibt die morgendliche Gedankenausleerung als gewöhnliche Absätze oben, lässt Nachfasspunkte als einfache Liste darunter fallen und verlinkt unterwegs mit Wiki-Links hinaus zu den relevanten Kundeneinträgen.

Der eingebaute Kalender ist, wie sie rückwärts und vorwärts navigiert. Statt durch einen Journal-Strom zu scrollen oder ein Datum in ein Suchfeld zu tippen und zu hoffen, dass die Seite existiert, öffnet sie den Kalender, wählt den Tag und sieht, was an ihm hängt. Die Entscheidungen des letzten Dienstags vor einem Kundenanruf zu überprüfen dauert Sekunden. Die nächste Woche zu planen bedeutet, die datierten Einträge im Voraus zu erstellen, mit den Fragen, die sie an jedem Tag beantwortet haben möchte, bereits wartend darin. Es ist eine kleine Verschiebung der Mechanik — Kalender zuerst, statt Journal-Strom zuerst —, aber das zugrunde liegende Versprechen ist identisch: Jeder Tag hat einen Ort, und sie kann zum Ort jedes Tages gelangen, ohne über Dateipfade oder Ordnerstruktur nachzudenken.

Die Zuletzt-Seitenleiste erledigt die stille Arbeit, die Logseqs Journal-Strom früher aus Versehen erledigte. In Logseq bedeutete die Rückkehr ins Journal, dass die Seiten von gestern und heute immer nahe an der Oberfläche ihres Bewusstseins waren, und von dort zogen die verlinkten Referenzen den Rest des Tages ins Bild. In VaultBook erfüllt Zuletzt dieselbe Wiedereintrittsfunktion. Das Kundenbriefing, das sie um 18 Uhr geöffnet hatte, die Lesenotiz, die sie halb beendete, der Journaleintrag von heute Morgen — sie sind in der Reihenfolge aufgelistet, in der sie sie zuletzt berührte. An einem Montagmorgen, nach einem Wochenende weg vom Tresor, baut sie mit Zuletzt den Kontext in unter einer Minute neu auf. Sie öffnet die letzten drei oder vier Posten, überfliegt sie, und sie weiß, wo sie aufgehört hatte. Kein Neuberechnen der Indizierung. Kein Sich-Fragen, ob die Version auf dieser Maschine die Version ist, die sie zuletzt sah.

Erfassen ohne Sync-Angst

Hier war Elenas Verhältnis zu Logseq wirklich zerbrochen, und ihre Erfahrung entspricht einem Muster, das andere Nutzer wiederholt beschreiben. Sync, der stillsteht und nie vorankommt, eine Statusanzeige, die zeigt, dass alles in Ordnung ist, während jüngste Bearbeitungen in Wahrheit verloren sind, eine Telefonbearbeitung, die hinter einer beruhigenden Mitteilung verschwindet, das vorgeschlagene Heilmittel, einen lokalen Graphen zu löschen und ihn erneut herunterzuladen — nur damit der Stillstand zurückkehrt. Andere Nutzer beschreiben ältere Versionen derselben Wunde: von Sync verdoppelte oder verschobene Blöcke, offline eingegebenes Material, das weggewischt wurde, bevor eine Zusammenführung es schützen konnte, Datei-Sync von Drittanbietern, der ständiges Neuindizieren, Duplikate und gebrochene Links in Suchergebnissen verursachte. Mobil kommt immer wieder als der Schwachpunkt vor — nicht die Erfassungsoberfläche, sondern die Verlässlichkeit darunter. Menschen können eine ungeschickte App ertragen. Sie können es nicht ertragen, etwas Wichtiges in eine App zu tippen und später zu entdecken, dass die App die Zuversicht behielt und die Worte verlor.

VaultBook entfernt die gesamte Problemkategorie, indem es Sync vollständig aus dem Erfassungspfad entfernt. VaultBook ist eine HTML-App aus einer einzigen Datei — ungefähr 1,5 MB —, die null Netzwerkanfragen stellt. Es gibt keinen Server, an dem man stillstehen könnte, kein Konto, bei dem man sich anmelden müsste, bevor man schreiben kann, kein Statussymbol, dessen Aufgabe es ist, einen über einen Prozess zu beruhigen, der irgendwo anders geschieht. Man öffnet die Datei, man tippt, die Notiz ist im Tresor. Der Tresor ist die Datei, und die Datei ist auf der Maschine vor einem.

Der Kompromiss ist echt und gehört in diesen Abschnitt, nicht ans Ende versteckt: VaultBook hat keinen eigenen Cloud-Sync. Den Tresor zwischen Ihren eigenen Maschinen zu bewegen ist Ihre Aufgabe — kopieren Sie die einzelne Datei mit welcher Methode Sie ohnehin vertrauen, auf dieselbe Weise, wie Sie jedes wichtige Dokument bewegen würden. Für Elena war das eine Erleichterung, verkleidet als Mühsal. Eine Datei, bewusst kopiert, zu Momenten, die sie wählt, gegenüber einem Graphenordner, der undurchsichtig im Hintergrund synchronisiert. Sie weiß genau, welche Kopie aktuell ist, weil sie sie dorthin legte. Nutzer, deren bezahlter Logseq Sync gut funktioniert — und manche berichten genau das, und ihre Erfahrung zählt —, werden dies anders empfinden. Wenn nahtloser Sync über mehrere Geräte das Herz Ihres Arbeitsablaufs ist und Ihrer wirklich funktioniert, wägen Sie das sorgfältig im Limits-Abschnitt unten ab. Doch wenn Sync der Teil Ihres gegenwärtigen Aufbaus ist, dem Sie nicht mehr vertrauen, verstehen Sie, worauf Sie zutauschen: Gewissheit darüber, wo Ihre Worte sind, im Austausch dafür, dass Sie eine Datei selbst bewegen.

Dinge finden: Suche, semantische Frage-Antwort-Funktion und verwandte Notizen statt Graphen-Durchstöbern

Für bewusstes Finden ist VaultBooks Suche das Arbeitstier, und sie geht erheblich weiter als Titel abzugleichen. Die Suche deckt den Volltext der Einträge ab, und der Tresor indiziert auch Anhänge, so ist eine Tatsache, begraben in einem PDF, das Sie vor Monaten ablegten, aus demselben Suchfeld auffindbar wie Ihre eigene Prosa. Optische Zeichenerkennung bedeutet, dass auch Text in gescannten Bildern und Screenshots durchsuchbar ist — das fotografierte Whiteboard, der gescannte Brief, der Screenshot einer Tabelle, die ein Kunde als Bild statt als Dokument schickte. Für eine Recherche-Analystin verändert diese letzte Fähigkeit still, was „ablegen und vergessen” bedeutet. Elenas Graph hatte immer ein Schattenarchiv gehabt: Bilder und PDFs, an Seiten gehängt, vorhanden, aber für die Suche faktisch unsichtbar, nur auffindbar, wenn sie sich erinnerte, an welcher Seite sie hingen. Im Tresor schlossen sich diese Anhänge dem durchsuchbaren Datensatz an. Material, das sie in ihrem ersten Jahr abgelegt hatte — und geistig als verloren abgeschrieben, sofern sie nicht graben ging —, tauchte in ihrer zweiten Woche in gewöhnlichen Suchen wieder auf.

Auf der Volltextsuche sitzt die semantische Frage-Antwort-Funktion. Statt die perfekte Schlagwortsuche zu konstruieren, stellen Sie dem Tresor eine Frage in gewöhnlicher Sprache, und er antwortet aus Ihren Einträgen. Dies ist das Werkzeug, zu dem Elena greift, wenn sie sich an die Substanz einer Notiz erinnert, aber an keine einzige ihrer Formulierungen — das Argument, das eine Quelle vorbrachte, nicht die Begriffe, die sie dafür benutzte. Die Schlagwortsuche scheitert an dieser Aufgabe, wann immer Ihre Erinnerung und Ihre vergangene Formulierung auseinandergehen, was für jeden Forscher oft der Fall ist. Die Frage direkt zu stellen und eine Antwort zu bekommen, die in ihrem eigenen Material gründet, ersetzte eine ganze Kategorie frustrierten Suchens: die Fünf-Varianten-Schlagwortspirale, das Scrollen durch Beinahe-Treffer-Ergebnisse, das schließliche resignierte Wiederlesen einer langen Seite. Es ersetzt nicht das Lesen des Quelleintrags — sie öffnet den Eintrag, auf dem die Antwort ruht, immer noch, bevor sie einem Kunden gegenüber irgendetwas zitiert —, aber es bricht die Distanz zwischen „Ich weiß, ich habe das aufgeschrieben” und der Seite selbst zusammen.

Exploratives Finden ist die Stelle, an der Ehrlichkeit erforderlich ist, denn VaultBook hat keine Graphenansicht. Es gibt kein visuelles Netz von Knoten, durch das man wandern könnte. Was es stattdessen bietet, sind verwandte Notizen: Von jedem Eintrag aus bringt der Tresor andere Einträge an die Oberfläche, die in der Sache verbunden sind, sodass der Seitwärtsschritt — von dieser Quelle zum Projekt, das sie benutzte, von dieser Kundennotiz zum früheren Mandat mit demselben Problem — ein Klick bleibt, nur ohne das Bild. Kombiniert mit Labels, die sie jeden Eintrag mit einem gemeinsamen Thema hervorholen lassen, unabhängig davon, wo er sitzt, und Wiki-Links, die die bewussten Verbindungen bewahren, die sie von Hand baute, decken verwandte Notizen das meiste von dem ab, wozu Elena Graphen-Durchstöbern tatsächlich benutzte. Beachten Sie die Einschränkung, denn sie zählt: das meiste, und tatsächlicher Gebrauch. Als sie ihre eigenen Gewohnheiten ehrlich prüfte, war Graphenwandern selten der Weg, auf dem sie Dinge fand, die zählten. Es war der Weg, auf dem sie angenehm abschweifte und gelegentlich eine Verbindung bemerkte. Verwandte Notizen liefern das Bemerken. Suche und Frage-Antwort liefern das Finden. Das angenehme Wandern ist fort, und der Limits-Abschnitt wird es sagen, ohne es auszuschmücken.

Langform schreiben ohne Outliner-Reibung

Der Outliner ist ein hervorragendes Denkwerkzeug und ein umständliches Schreibwerkzeug, und die Spannung zwischen diesen beiden Wahrheiten zieht sich durch Jahre der Diskussion unter Logseq-Autoren. Blöcke strukturieren Gedanken wunderschön: atomar, umordenbar, verlinkbar. Aber Prosa ist keine Blöcke. Prosa sind Absätze, die fließen, Argumente, die sich über eine Seite aufbauen, Entwürfe, die gelesen werden müssen, wie ein Leser sie lesen wird. Autoren beschreiben, wie Überschriften und Blockstruktur dem Entwurfschreiben im Weg stehen, und die unscheinbare Arbeit, blockstrukturiertes Material in übergeordnete, fließende Dokumente in großem Maßstab umzuwandeln — über Hunderte oder Tausende von Seiten —, bevor es als Schreibarbeit genutzt werden kann. Wenn Ihr Graph in erster Linie ein Denkraum ist, beißt nichts davon. Wenn Ihr Graph wie bei Elena allmählich zum Ort wurde, an dem Kundenberichte und Artikel entworfen ebenso wie recherchiert wurden, beißt es jeden Arbeitstag.

In VaultBook ist ein Eintrag ein Dokument. Sie entwirft einen Kundenbericht als Dokument vom ersten Satz an: Überschriften, wo das Argument sie braucht, Absätze, die so lang laufen, wie der Gedanke es verlangt, Listen nur, wo eine Liste wirklich die richtige Form ist. Es gibt keinen Zwischenumwandlungsschritt zwischen „Notizen zum Bericht” und „dem Bericht” — die Rechercheeinträge sitzen neben dem Entwurf, verknüpft durch Wiki-Links und Labels, und der Entwurf selbst ist in der Form geschrieben, in der er geliefert werden wird. Dynamische Tabs unterstützen dies mehr, als ihre bescheidene Beschreibung vermuten lässt. Recherchieren und Schreiben zugleich bedeutet, mehrere Einträge offen zu halten und ständig zwischen ihnen zu wechseln: der Entwurf in einem Tab, zwei Quellennotizen in anderen, das Kundenbriefing in einem vierten. Tabs, die bestehen bleiben und sich umordnen lassen, während sie arbeitet, verwandeln den Tresor von einem Notizbuch, eine Seite nach der anderen, in einen Schreibtisch mit Papieren, die darüber ausgebreitet liegen — was, nicht zufällig, die Art ist, wie sie ein Jahrzehnt lang auf Papier arbeitete, bevor irgendeine dieser Apps existierte.

Der Reader ist die zweite Hälfte des Schreibarbeitsablaufs: das Zurücklesen. Jeder Autor kennt den Entwurf, der im Editor gut aussah und beim kalten Lesen auseinanderfällt. Der Reader präsentiert Einträge sauber für genau dieses kalte Lesen — und für die langen Lesesitzungen, die ihre Recherche verlangt, das Durcharbeiten abgelegter Quellen und ihrer eigenen älteren Notizen ohne das visuelle Durcheinander des Bearbeitens. Sie liest einen Entwurf im Reader, notiert die schwachen Abschnitte, schaltet zurück und repariert sie. Es ist eine kleine Schleife, viele Male pro Woche getan, und jeder Durchlauf macht ein Lieferergebnis auf eine Weise besser, die ein Kunde spüren kann, selbst wenn er nie den Namen des Werkzeugs erfährt.

Fristen: Fällig und Ablaufend statt Abfragepflege

VaultBooks Antwort ist bewusst einfacher: eine Seitenleiste Fällig und Ablaufend. Einträge tragen Daten, die zählen — eine Lieferfrist, eine Vertragsverlängerung, ein Lizenz- oder Dokumentenablauf, eine Nachfassung, versprochen für einen bestimmten Tag —, und die Seitenleiste bringt das, was fällig ist und was abläuft, der Reihe nach an die Oberfläche, ohne dass sie eine einzige Abfrage konstruiert oder pflegt. Ihre Morgenroutine nahm es in einem Tag auf: Journaleintrag zuerst, dann die Fällig-Liste, dann Arbeit. Der Kundenbericht, der am Donnerstag fällig ist, ist da. Die Quelle, deren Zugang in diesem Monat abläuft, ist da. Die Nachfassung, die sie einem Interessenten versprochen hat, ist da, an dem Tag, an dem sie sie versprochen hat, nicht drei Wochen zu spät entschuldigend in einer alten Journalseite entdeckt.

Das Sicherheits-Upgrade: von einem Ordner reinen Texts zu einem verschlüsselten Tresor

Es gibt einen Satz, den Elena sich während vier Jahren in Logseq nie ganz gesagt hatte, und die Migration zwang sie, ihn auszusprechen: Ihr gesamtes berufliches Leben — jedes Kundenmandat, jedes Stück unveröffentlichter Recherche, jede offene Notiz über eine Verhandlung — saß in einem Ordner reiner Markdown-Textdateien, den jedes Programm, jede Person und jedes Schadprogramm mit Zugang zu ihrer Maschine vollständig lesen konnte, sofort, ohne irgendjemandes Erlaubnis zu erfragen.

Verschlüsselung pro Eintrag für die Seiten, die sie brauchten

VaultBooks Verschlüsselung erfolgt pro Eintrag, mit AES-256-GCM und PBKDF2-Schlüsselableitung über die Web Crypto API, und der Teil „pro Eintrag” ist, was sie benutzbar statt bloß beeindruckend macht. Verschlüsselung des ganzen Tresors erzwingt eine Wahl zwischen alles zu sperren — und die Entsperrreibung bei jeder Einkaufsliste und Lesenotiz zu zahlen — und nichts zu sperren. Die Verschlüsselung pro Eintrag lässt sie die Linie dort ziehen, wo die Empfindlichkeit tatsächlich ist.

In der Praxis hat ihr Tresor nach der Migration drei Stufen, obwohl sie sie nie förmlich benannte. Die offene Stufe ist der Großteil des Tresors: Lesenotizen, öffentliche Recherche, Entwürfe veröffentlichter Arbeit, das gewöhnliche Geschäft des täglichen Journals. Diese Einträge sind unverschlüsselt, sofort durchsuchbar, null Reibung. Die empfindliche Stufe ist Kundenarbeit: Mandatsnotizen, Interview-Niederschriften, alles, was die unveröffentlichten Zahlen, Pläne oder internen Politiken eines Kunden enthält. Diese Einträge sind einzeln verschlüsselt. Einen zu öffnen erfragt die Passphrase; der Rest des Tresors kümmert sich nicht darum. Die kleine, höchste Stufe ist die Handvoll Einträge, die auf eine andere Weise empfindlich sind — persönliche Finanznotizen, Informationen zur Zugangswiederherstellung, die offenen Einschätzungen, die sie nach schwierigen Mandaten schreibt —, auf dieselbe Weise verschlüsselt und wenige genug, dass sie sie aus dem Gedächtnis aufzählen kann.

Was sich änderte, ist nicht theoretisch. Vor der Migration hätten ein gestohlener Laptop, ein achtlos geteilter Ordner, ein Backup-Laufwerk, das am falschen Ort zurückgelassen wurde, oder ein kompromittiertes Sync-Konto Kundenmaterial in lesbarer Form demjenigen ausgesetzt, der es aufhob. Nach der Migration setzt derselbe Vorfall ihre Lesenotizen aus und lässt die Kundenarbeit als Chiffretext zurück. Das ist ein materiell anderes Gespräch, das man mit einem Kunden zu führen hat, und mit sich selbst. Es ist auch, nicht zufällig, das erste Mal, dass ihre Werkzeuge der Vertraulichkeitssprache in ihren eigenen Verträgen entsprachen.

Zwei Disziplinen machen Verschlüsselung echt statt dekorativ. Die erste ist die Passphrase: lang, einzigartig, nirgendwo wiederverwendet und außerhalb des Tresors gespeichert — ihre lebt in ihrem Passwortmanager, und eine versiegelte Kopie existiert bei ihren Papierunterlagen, denn ein verschlüsselter Tresor mit vergessener Passphrase ist nicht sicher, er ist schlicht weg. Die zweite ist Ehrlichkeit im Umfang: Verschlüsseln Sie die Einträge, die es brauchen, in dem Moment, in dem Sie sie erstellen oder migrieren, als Gewohnheit, statt ein großes Verschlüsselungswochenende zu planen, das nie geschieht. Elena verschlüsselte die Kundeneinträge, während sie sie während der Migration neu aufbaute, solange ihr Urteil über jeden frisch war. Fünfzehn Minuten Entscheidungen, einmal getroffen, Eintrag für Eintrag, genau in dem Moment, in dem sie jede Seite bereits mit kritischem Auge las.

Versionsverlauf: das Rückgängig, das Wochen überspannt

Fragen Sie Menschen, die Jahre von Arbeit in irgendeinem Notizsystem aufbewahren, was ihr schlimmster Moment war, und eine überraschende Zahl wird dieselbe Form von Verlust beschreiben: keine Panne, kein Sync-Versagen, sondern eine Bearbeitung. Eine Seite, überschrieben mit der falschen Version. Eine lange Notiz, ersetzt durch ein Fragment. Eine Umstrukturierung, die mehr löschte, als sie meinte, Tage später entdeckt, als das gewöhnliche Rückgängig längst fort war und das tägliche Backup — falls es eines gab — bereits an der guten Version vorbeirotiert war.

VaultBook führt einen Versionsverlauf für Einträge, und im Migrationszusammenhang verdient er sich seinen Unterhalt zweimal. Das erste Mal ist während der Migration selbst. Das Umstrukturieren des Materials von 3.800 Seiten ist Bearbeiten in großem Maßstab: Einträge geteilt, zusammengeführt, umbetitelt, neu aufgebaut. Fehler sind kein Risiko, sondern eine Gewissheit, und die einzige Frage ist, ob ein Fehler eine Unannehmlichkeit oder ein Verlust ist. Mit Versionsverlauf konnte Elena aggressiv umstrukturieren — die drei überlappenden Quellennotizen zu einer vereinen, den Zusammenfassungs-Eintrag des Kunden von Grund auf neu schreiben — im Wissen, dass der frühere Zustand jedes Eintrags wiederherstellbar blieb. Dieses Wissen veränderte, wie sie arbeitete: schneller, weniger ängstlich, weniger vorsorgliche Doppeleinträge, die den Tresor „nur für den Fall” verstopften, denn „nur für den Fall” war jetzt eine Funktion, keine Ablagegewohnheit.

Der Passwortgenerator und die kleinen Werkzeuge, die Schleifen schließen

Ein eingebauter Passwortgenerator klingt nach einer kleinen Bequemlichkeit, bis man ihn in Elenas tatsächliche Arbeit versetzt. Recherche-Analysten sammeln Konten so, wie Reisende Adapter sammeln: Datenbank-Testzugänge, Quellenplattformen, Kundenportale, Umfragewerkzeuge, jedes verlangt Zugangsdaten, jedes eine kleine Sicherheitsentscheidung unter Zeitdruck. Der vorhersehbare Fehler — ein starkes Passwort wiederverwenden oder ein schwaches neues erfinden — geschieht genau in diesen Momenten. Ein Generator innerhalb des Werkzeugs, das bereits auf ihrem Schreibtisch geöffnet ist, entfernt die Reibung im Moment der Entscheidung. Neues Kundenportal, neues generiertes Passwort, direkt in ihren Passwortmanager, Tresor nie geschlossen. Kleines Werkzeug, echte Schleife geschlossen.

Dieselbe Logik zieht sich durch den Rest von VaultBooks eingebauten Werkzeugen, und es lohnt sich, sie als Sicherheits- und Arbeitsablaufoberfläche zu sehen statt als Funktionsliste. Die PDF-Werkzeuge — zusammenführen, teilen, komprimieren — bedeuten, dass Kundendokumente im Tresor zusammengestellt werden, statt zu einem kostenlosen Online-PDF-Dienst unbekannter Herkunft hochgeladen zu werden, wohin jeden Arbeitstag erstaunlich viel vertrauliches Material beiläufig geschickt wird. Die lokale Whisper-Transkription bedeutet, dass Interview-Audio auf ihrer Maschine transkribiert wird, statt zu einem Cloud-Transkriptionsdienst hochgeladen: Die Stimmen und Worte ihrer Interviewten verlassen das Gebäude nie, was für aufgezeichnete Kundengespräche keine Vorliebe ist, sondern eine Verpflichtung, der sie zuvor mit einem separaten, umständlichen Offline-Verfahren nachkam. Der MP3-Schneider bedeutet, dass sie die relevanten neunzig Sekunden einer langen Aufzeichnung für ihre eigenen Notizen ausschneiden kann, ohne die ganze Datei irgendwohin zu versenden. Der Datei- und Ordner-Analysator lässt sie prüfen, was tatsächlich in einem Ordner mit Material steckt, den ein Kunde schickt, bevor sie Dinge aufs Geratewohl öffnet. Der Photo and Video Explorer, mit EXIF-Daten, hält das Wann und Wo visueller Belege am Beleg befestigt. Keines davon rechtfertigt für sich eine Migration. Zusammen beschreiben sie ein Muster: Die Arbeiten, die ihr empfindlichstes Material früher hinaus zu einer Streuung von Cloud-Dienstprogrammen schoben, geschehen nun innerhalb einer einzigen lokalen Datei, und Material, das die Maschine nie verlässt, kann nicht auf der eines anderen gebrochen werden.

Was null Netzwerkanfragen um 9 Uhr an einem Dienstag bedeuten

Um 9 Uhr öffnet Elena ihren Tresor. Nichts meldet sich an. Nichts prüft einen Lizenzserver, synchronisiert einen Status, lädt eine entfernte Konfiguration oder telefoniert mit Nutzungs-Telemetrie nach Hause, denn die App stellt null Netzwerkanfragen — nicht „keine Anfragen außer ein paar harmlosen”, sondern keine. Die Datei, die sie öffnet, ist das ganze System: eine einzige HTML-Datei von ungefähr 1,5 MB, die die Anwendung selbst und ihre Daten enthält und lokal in ihrem Browser läuft. Wenn ihre Internetverbindung um 8:59 Uhr stürbe, verliefe ihr 9 Uhr in jeder Einzelheit identisch. Es gibt keine Statusseite zu prüfen, keinen Störungs-Feed, über den man sich wundern müsste, keinen Moment des Schielens auf ein Symbol, um zu entscheiden, ob es die Wahrheit darüber sagt, ob ihre Notizen sicher sind.

Das ist das Sicherheits-Upgrade in einem Satz: von Vertraulichkeit, die davon abhing, dass niemand sich die Mühe machte, in einen Ordner reinen Texts hineinzusehen, zu Vertraulichkeit, durchgesetzt durch Verschlüsselung auf den Einträgen, die sie brauchen, Verlauf auf den Einträgen, die sich ändern, und eine Architektur, in der die gewöhnlichste Weise, wie modernes Wissen heute exponiert wird — die Server von jemand anderem — vollständig aus ihrem Arbeitsleben herauskonstruiert wurde.

Wenn der Vorfall eines anderen Ihr Wissen offline nimmt: der GitBook-Vorfall

Dieser Abschnitt existiert wegen etwas, das diese Woche geschah, einem anderen Unternehmen, anderen Kunden — und weil er mit unbequemer Genauigkeit das Risiko veranschaulicht, dessen Beseitigung ein Offline-Tresor konstruiert ist.

GitBook, eine weitverbreitete Plattform für Dokumentation und Wissensbasen, hat eine offizielle Nachbetrachtung (Post Mortem) eines schweren Sicherheitsvorfalls veröffentlicht. Die Nachbetrachtung ist auf Mittwoch, den 4. November 2026 datiert, und sie betrifft ein Ereignis am 2. November 2026. Sie können sie vollständig an der Quelle lesen: https://www.gitbook.com/status/security-incident-2026-11-03

Nach GitBooks eigener Darstellung nutzte ein Angreifer eine Schwäche im Single Sign-on aus, um Zugang zu Mitarbeiter-Sitzungen zu erlangen, und von dort — über eine fehlkonfigurierte GitHub-App und einen Cloudflare-API-Schlüssel — Zugang zur Produktionsinfrastruktur. Der Zugang kam in zwei Fenstern, eines von ungefähr zwei Stunden und fünfundvierzig Minuten und ein weiteres von ungefähr vierzig Minuten. GitBooks Antwort, wiederum in seiner eigenen Erzählung, ging von einer strengen und verantwortungsvollen Annahme aus: Alle Kundendaten wurden als exponiert behandelt. Zu den genannten Kategorien gehören API-Tokens, Integrations-Tokens und Geheimnisse, Sitzungs-Signaturgeheimnisse, Fragen, die dem GitBook Assistant gestellt wurden, authentifizierte Dokumentation und Inhalte. GitBook nahm seine eigene Anwendung als Teil der Antwort bewusst offline; der Dienst war vom 2. November um 20:32 UTC bis zum 3. November um 11:56 UTC unten — ungefähr sechzehn Stunden. Jedes Geheimnis wurde rotiert und alle API-Tokens ungültig gemacht, was bedeutet, dass jeder Kunde, der die API nutzt, neue Tokens erstellen und seine Integrationsgeheimnisse rotieren muss. Die Nachbetrachtung verzeichnet auch, was nicht kompromittiert wurde — Rechnungsinformationen, Passwörter und geistiges Eigentum in dem Sinn, den die Mitteilung definiert — und dass das Unternehmen keine Hinweise fand, dass Inhalte anderer Kunden verändert wurden.

Lesen Sie diese Zusammenfassung noch einmal vom Stuhl des Kunden, denn das ist der Stuhl, auf dem Elena früher saß — und der Stuhl, auf dem jeder sitzt, dessen Wissen in erster Linie in der Cloud eines Anbieters lebt. Ohne eigenes Verschulden, ohne irgendetwas Ungewöhnliches zu tun, wachten GitBooks Kunden mit drei gleichzeitigen Tatsachen auf: Material, das sie der Plattform anvertraut hatten, musste als exponiert angenommen werden; Integrationen, von denen sie abhingen, hatten aufgehört zu funktionieren, weil jedes Token auf einmal ungültig gemacht worden war; und für ungefähr sechzehn Stunden war die Wissensbasis selbst schlicht nicht verfügbar — abgeschaltet, bewusst und korrekterweise, vom Anbieter, als Teil der Eindämmung des Angriffs einer fremden Partei. Jede dieser Entscheidungen GitBooks war vertretbar. Die Offline-Zeit verhinderte wahrscheinlich Schlimmeres. Genau das ist der Punkt: Wenn Ihr Wissen in der Infrastruktur eines anderen lebt, können selbst gute Entscheidungen, gut getroffen, von einem verantwortungsvoll handelnden Unternehmen, Ihr Material exponieren und Ihren Zugang nach einem Zeitplan entfernen, den Sie nicht kontrollieren, aus Gründen, die nichts mit Ihnen zu tun haben.

Stellen Sie nun Elenas Tresor dieser Gestalt eines Vorfalls gegenüber, konkret statt rhetorisch. Ihr Tresor ist eine einzige HTML-Datei auf ihren eigenen Maschinen. Es gibt keine VaultBook-Infrastruktur, die ihre Recherche hält, also gibt es keinen Infrastruktur-Einbruch, der ihre Daten als exponiert behandeln kann. Es gibt keine API-Tokens für ihren Tresor — keine Tokens, die ungültig zu machen wären, keine Integrationsgeheimnisse, die an einem Dienstagmorgen in Eile zu rotieren wären, keine nachgelagerten Automatisierungen, die still durch eine Massenwiderrufung gebrochen wären, von der sie auf einer Statusseite erfährt. Es gibt keinen Anbieter, der ihr Wissen offline nehmen kann, um einen Vorfall einzudämmen, denn es gibt kein Online, von dem es genommen werden könnte: Die App stellt null Netzwerkanfragen, und ihr Zugang zu ihrer eigenen Arbeit hängt von ihrem Laptop und ihrer Passphrase ab und von nichts anderem auf der Welt. Ein Angreifer, der ihr Kundenmaterial will, kann es nicht erreichen, indem er ein Dokumentationsunternehmen, einen Sync-Anbieter oder eine Cloud-Region kompromittiert. Er müsste sie kompromittieren, gezielt, auf ihrer Hardware — und dort trifft er auf Verschlüsselung pro Eintrag mit AES-256-GCM auf allem Empfindlichen, statt auf einen Ordner reinen Texts oder den lesbaren Inhalt eines Servers.

Nichts davon macht GitBook zum Schurken dieses Leitfadens, und der Vorfall sollte nicht über das hinaus aufgeblasen werden, was die Nachbetrachtung sagt. Cloud-Wissensplattformen existieren aus guten Gründen: Zusammenarbeit, Veröffentlichung, Integrationen — echte Fähigkeiten, die der Limits-Abschnitt unten ehrlich erörtert. Die Lektion dieser Woche ist enger und nützlicher. Sie lautet, dass „meine Notizen sind in der Cloud” nicht eine Entscheidung ist, sondern zwei: eine Entscheidung über Funktionen und eine Entscheidung darüber, wessen Vorfälle zu Ihren Vorfällen werden. Für einen persönlichen beruflichen Tresor — die Recherche, Kunden und das Arbeitsgedächtnis einer einzelnen Person, die kein Publikum und keine Mitarbeiter brauchen — verdient die zweite Entscheidung, bewusst getroffen zu werden. Elena traf sie, als sie migrierte. GitBooks Nachbetrachtung, vor zwei Tagen veröffentlicht, ist das Aussehen des nicht genommenen Wegs, wenn er eine schlechte Woche hat.

Ehrliche Grenzen: Was VaultBook nicht tut, und wer nicht migrieren sollte

Es gibt keine Graphenansicht. Wenn der visuelle Graph die Art ist, wie Sie denken — wenn Sie ihn öffnen, um zu planen, Cluster zu erspähen, zu lehren, Ihren Weg zu finden —, bietet VaultBook nichts an seiner Stelle. Verwandte Notizen bringen Verbindungen als Liste an die Oberfläche, nützlich und unglamourös. Es gibt keine Karte. Für manche Nutzer ist dies eine Fußnote; für visuelle Denker ist es das ganze Produkt, und keine Menge an Suchqualität gleicht eine Weise des Sehens aus, die schlicht abwesend ist.

Es gibt keinen Outliner, und es gibt keine Blockreferenzen oder Block-Einbettungen. Dies ist der tiefste Unterschied, und er ist der Verlust, den Migranten von Logseq am häufigsten nennen, wenn sie beschreiben, was bei früheren Umzügen zu anderen Werkzeugen zerbrach. Wenn Ihr Graph auf Blockebene zusammengewoben ist — Absätze, referenziert und wiederverwendet über Dutzende von Seiten, transkludiert in Briefings und Dashboards, ein echtes Netz auf Blockebene bildend —, überträgt sich dieses Netz nicht. Nicht nach VaultBook, und ehrlicherweise auch nirgendwo anders hin; es muss von Hand entwoben werden, Blockreferenzen in gewöhnliche Links und umgeschriebene Passagen umgewandelt, und ein Teil der feinen Struktur geht in der Umwandlung schlicht verloren. Elenas Graph benutzte Blockreferenzen leicht, weshalb ihre Migration in Tagen gemessen wurde. Ein Graph, der schwer auf ihnen gebaut ist, ist ein anderes Projekt — Wochen, mit echten Verlusten zum Abwägen. Zählen Sie Ihre Abhängigkeit von Blockreferenzen, bevor Sie irgendetwas anderes zählen. Wenn die Zahl „mein ganzes System” lautet, ist dieser Leitfaden nicht für Sie, und er sagt es unumwunden.

Es gibt keine Datalog-Abfragen. VaultBooks Seitenleiste Fällig und Ablaufend, Labels, Suche und semantische Frage-Antwort-Funktion decken die Alltagsfragen ab — was ist fällig, was halte ich zu diesem Thema, was schrieb ich über jenes Argument. Sie decken keine beliebigen strukturierten Fragen über benutzerdefinierte Eigenschaften ab, die Art, aus der fortgeschrittene Logseq-Nutzer ihre Dashboards und Arbeitsabläufe bauen. Wenn Ihre Praxis auf handgebauten Abfragen läuft, würden Sie ein programmierbares System gegen ein festes, einfacheres tauschen. Manche Menschen erleben das als Erleichterung. Die Menschen, die die Abfragen bauten, selten.

Es gibt keine Plugins. Logseqs Plugin-Ökosystem, Themes und eigene Skripte lassen Nutzer das Werkzeug zu ihrer exakten Praxis biegen — und, wie Nutzer selbst anmerken, kommt diese Macht mit Wartung: Plugins zu aktualisieren, eigenes CSS zu pflegen, Erweiterungen, die brechen, wenn die Plattform sich bewegt. VaultBook ist eine feste Anwendung aus einer einzigen Datei. Was es tut — Einträge, Labels, Wiki-Links, Suche und Frage-Antwort, OCR und Anhangsindizierung, Kalender und Seitenleisten, Kanban-Boards, Reader, Datenvisualisierung, die PDF- und Audio-Werkzeuge, Photo and Video Explorer, Datei- und Ordner-Analysator, Passwortgenerator, Versionsverlauf, Verschlüsselung —, tut es ohne Erweiterung, und was es nicht tut, können Sie nicht hinzufügen. Die Decke ist niedriger. Die Instandhaltung ebenso: Es gibt nichts, das bei einer Aktualisierung brechen könnte, denn das Modell ist bewusst geschlossen.

Es gibt keine Echtzeit-Zusammenarbeit. VaultBook ist ein persönlicher Tresor im wörtlichen Sinn. Sie können keine Kollegin in einen Eintrag einladen, keine Seite gemeinsam bearbeiten, nicht in den Rändern kommentieren oder aus dem Tresor an ein Team veröffentlichen. Teams, deren Wissensarbeit wirklich geteilt ist — eine Forschungsgruppe, die in einen Graphen schreibt, ein Unternehmen, das gemeinsam dokumentiert —, brauchen ein dafür gebautes Werkzeug, und dies ist es nicht. Elenas Fall funktionierte, weil ihre Praxis solo ist: Kunden erhalten fertige Dokumente, keinen Zugang zu ihrem Prozess. Wenn Ihr Prozess das geteilte Produkt ist, bleiben Sie, wo Teilen nativ ist.

Es gibt keinen eigenen Cloud-Sync. Früher als Erfassungsfrage behandelt, gehört er auch hierher als Grenze. Wenn Sie ständig zwischen Geräten wechseln und Ihr gegenwärtiger Sync wirklich funktioniert — und manche Nutzer berichten genau das mit Logseq, bezahlt oder anders —, verlangt VaultBook von Ihnen, eine Datei selbst zu tragen, und das wird sich jeden einzelnen Tag wie ein Rückschritt anfühlen. Eine Grenze hört nicht auf, eine Grenze zu sein, weil sie auch ein Designprinzip ist.

Also: Wer sollte nicht migrieren? Graphendenker. Blockreferenz-Architekten. Abfragebauer. Plugin-Erweiterer. Zusammenzuarbeitende Teams. Glückliche Sync-Nutzer. Das ist eine große und ehrenwerte Liste — plausiblerweise die Mehrheit von Logseqs ergebensten Nutzern, was zum Ton der Diskussionen unter Menschen passt, die ein Weggehen erwogen: liebevoll, zögernd, oft beschließend, auf der Version zu bleiben, die für sie funktioniert. Und es gibt Verteidiger von Logseqs Datenbankrichtung, deren Erfahrung in jeder ehrlichen Darstellung ihren gebührenden Platz verdient: Nutzer, die die Navigation der neuen Version schnell finden, ihre Supertags und Eigenschaften echt besser, ihre großen Graphen gut laufend. Die Leistung in der Datei-Version ist ungleichmäßig statt schlicht schlecht — manche Graphen von wenigen tausend Seiten straucheln, andere von vier bis siebentausend Seiten laufen gut, wobei die Komplexität der Namespaces, Eigenschaften, Abfragen und Bilder den Unterschied macht. Wenn Ihr Graph in der glücklichen Hälfte dieser Verteilung ist und Ihr Sync hält, sind Ihre Gründe zu wechseln schwach und Ihre Gründe zu bleiben stark.

Wer sollte also migrieren? Das Profil ist enger und spezifisch: eine allein arbeitende Wissensarbeiterin, deren Graph in erster Linie aus Dokumenten, Notizen und Journalen besteht statt aus einem Blocknetz; deren Kunden- oder persönliches Material über reinen Text hinausgewachsen ist; die von Sync-Unzuverlässigkeit, undurchsichtigen Status und hinter beruhigenden Mitteilungen verlorenen Bearbeitungen gebissen wurde — oder plausibel fürchtet, gebissen zu werden —; die beunruhigt ist, wie viele, von einer Roadmap, die ihre tragbaren Dateien auf eine Datenbank zubewegt, deren Export zurück nach Markdown Ordnerstruktur und Assets verliert und nicht sauber im Kreis zurückführt; und die lieber einen kleineren Satz von Werkzeugen hätte, die vollständig ihre sind, als einen größeren, der zu den Bedingungen eines anderen gepflegt wird. Wenn dieser Absatz Sie beschreibt, lesen Sie weiter. Die nächsten dreißig Tage sind der Unterschied zwischen einer Migration, die klebt, und einem Tresor, der zu einem weiteren aufgegebenen Experiment wird.

Die ersten 30 Tage nach der Migration

Die meisten Migrationen scheitern nicht am Tag des Umzugs. Sie scheitern in Woche drei, still, wenn das neue System seinen ersten wirklich schlechten Tag erlebt — eine Fristenklemme, ein Schrecken über eine verlorene Notiz, ein Moment der Reibung um 23 Uhr — und das alte System, das noch immer dasitzt, wie Zuhause aussieht. Der Dreißig-Tage-Plan, der folgt, ist Elenas, verallgemeinert. Sein Zweck ist kein Produktivitätstheater. Er soll den neuen Tresor mit intaktem Vertrauen über jene dritte Woche tragen und Ihnen genau sagen, wann der alte Graph ehrenhaft in Rente gehen kann.

Tage 1 bis 7: Parallelbetrieb, mit VaultBook vorn

Betreiben Sie in der ersten Woche beide Systeme — aber mit einer strengen Regel darüber, welches echt ist. VaultBook ist der Ort, an den neue Arbeit geht: der Journaleintrag von heute, die Kundennotizen von heute, die Erfassungen von heute. Logseq bleibt nur als Referenzbibliothek geöffnet, konsultiert, wenn ein Arbeitsstück Material braucht, das noch nicht migriert ist oder das Sie bewusst zurücklassen. Diese Asymmetrie ist der ganze Trick. Parallelbetrieb, bei dem beide Systeme neue Notizen empfangen, ist keine Erprobung; er ist eine Gabelung, und Gabelungen im persönlichen Wissen sind der Weg, auf dem Menschen mit zwei halb vertrauten Archiven enden und einer dauerhaften, leisen Angst, welches von beiden die wahre Version von irgendetwas hält. Eine Schreiberin, eine Leserin. Neue Tinte nur im Tresor.

Erwarten Sie diese Woche Reibung, und vergeben Sie ihr im Voraus. Sie werden nach Blockoperationen greifen, die nicht existieren. Sie werden aus Gewohnheit eine Abfrage tippen, bevor Sie sich erinnern, dass die Seitenleiste existiert. Sie werden einen Eintrag mit einem leicht falschen Label erstellen und ihn an Tag vier reparieren. Nichts davon ist ein Signal darüber, ob die Migration richtig war; es sind die gewöhnlichen Kosten von vier Jahren Muskelgedächtnis, die einem neuen Schreibtisch begegnen. Was Signal ist: ob sich das Erfassen sicher anfühlt, ob die Suche findet, worum Sie bitten, ob die Morgenroutine — Journal, Zuletzt, Fällig — ohne Umgehung abschließt. Diese drei sind die tragenden Wände. Elenas Urteil über Woche eins ruhte vollständig auf ihnen.

Tage 8 bis 21: im Tresor leben, auf Anforderung migrieren

Material wird noch fehlen; planen Sie dafür, statt jede Lücke als Versagen zu behandeln. Elenas Regel war Migration auf Anforderung: Wenn echte Arbeit nach einer Seite griff, die noch im alten Graphen gestrandet war, migrierte sie jene Seite ordentlich in jenem Moment — umstrukturiert als Eintrag, etikettiert, Links als Wiki-Links neu aufgebaut, verschlüsselt, wenn sie Kundenmaterial trug — und verzeichnete sie in einer laufenden „noch in Logseq”-Liste, wann immer sie sich entschied, es nicht zu tun. Die Liste zählte. Sie verwandelte einen unbekannten Rest („da hinten ist Zeug, irgendwo”) in eine endliche, sichtbare Warteschlange, die jede Woche schrumpfte. Das meiste davon wurde, wie sie feststellte, überhaupt nie angefragt, was an sich Information ist: Ein Graph sammelt zeremonielle Seiten an, aus Ordnungsgefühl behalten statt aus Nutzung, und eine Migration ist die eine ehrliche Prüfung dessen, woraus Ihr Wissen tatsächlich besteht.

Behalten Sie die Gegenstimmen während dieser Phase im Kopf, besonders an den schlechten Tagen. Manche Migranten gehen zurück. Die Diskussionen sind voll von Gehen-und-Zurückkehren, und Zurückkehren ist kein Scheitern — es sind Daten, dass das Ding, das Sie verließen, auf eine Weise tragend für Sie war, die kein Leitfaden hätte wissen können. Wenn Sie an Tag einundzwanzig täglich nach der Graphenansicht greifen oder Ihre Arbeit zweimal an fehlenden Blockreferenzen blockiert ist, lesen Sie diese Daten ehrlich. VaultBook hält keine Geisel: Ihr Markdown-Archiv ist intakt, Ihr alter Graph öffnet sich exakt so, wie Sie ihn verließen, und die Ausgangstür ist dieselbe Tür, durch die Sie hereinkamen. Eine Migration, die Sie umkehren können, ist eine Migration, die Sie wahrheitsgemäß bewerten können, denn niemand — Sie eingeschlossen — muss so tun, als hätte sie funktioniert, um die Kosten zu rechtfertigen.

Tage 22 bis 30: den alten Graphen in Rente schicken — ohne irgendetwas Wichtiges zu löschen

In Rente schicken als Arbeitssystem bedeutet drei bestimmte Dinge. Erstens erreicht die „noch in Logseq”-Liste null oder wird bewusst geschlossen: Jeder verbleibende Posten wird entweder migriert oder förmlich als nicht migrationswert abgeschrieben — im Protokoll abgeschrieben, beim Namen, damit die Entscheidung eine Entscheidung ist und keine Drift. Zweitens läuft das tägliche Leben nicht mehr durch die alte App: keine Referenz-Nachschlagungen, kein „nur mal prüfen”, denn jede beiläufige Rückkehr öffnet die Frage erneut, die die dreißig Tage klären sollten. Drittens erhält der Tresor seine erste vollständige Backup-Disziplin-Prüfung: Versionsverlauf an einigen Einträgen stichprobenartig geprüft, um zu bestätigen, dass er hält, was Sie erwarten, eine externe Kopie der einzelnen Datei erstellt und datiert, die Passphrase an ihrem Aufbewahrungsort verifiziert. Vertrauen, aber erst nach Verifikation.

Das Roharchiv zu behalten bedeutet etwas ebenso Bestimmtes, und es ist der leichteste Schritt in diesem ganzen Leitfaden, den man falsch machen kann, also achten Sie genau: Räumen Sie es nicht auf. Strukturieren Sie es nicht um, benennen Sie seine Ordner nicht um, beschneiden Sie seine Duplikate nicht und „beenden” Sie es auf keine Weise. Exportieren oder kopieren Sie die Markdown-Dateien des Graphen exakt so, wie sie sind — dieselbe Ordnerstruktur, dieselben Assets, dasselbe alles — an einen klar benannten Archivort, und lassen Sie es dann in Ruhe, für immer, als eingefrorenen Datensatz von vier Jahren Arbeit in seiner ursprünglichen Form. Sein Wert besteht gerade darin, dass es uneditiert ist: Wenn in zwei Jahren eine Frage auftaucht, was eine Notiz sagte, bevor die Migration sie umstrukturierte, beantwortet das Archiv sie. Wenn Sie je zu Logseq zurückkehren oder weiter zu einem anderen Markdown-basierten Werkzeug ziehen müssen, ist das Archiv der saubere Ausgangspunkt, unmodifiziert von Ihrer Begeisterung wie von Ihrem Bedauern. Elenas Archiv sitzt in einem datierten Ordner, den sie seit seiner Erstellung zweimal geöffnet hat — beide Male, um genau jene Art von Frage zu beantworten, in Minuten. Dafür ist ein gutes Archiv da: nicht für Nostalgie, sondern für Belege.

Häufige Migrationsfragen — und Elena, drei Monate später

Wie lange dauert der Umzug tatsächlich? Für einen Graphen von Elenas Größe — rund 3.800 Seiten, leicht an Blockreferenzen, schwer an Dokumenten und Lesenotizen — lautet die ehrliche Antwort: ein konzentriertes Wochenende für den Kernumzug, plus die oben beschriebenen dreißig Tage dafür, dass die Migration wahr wird. Das Wochenende deckt den strukturierten Durchgang ab: das Markdown exportieren und kopieren, das Material, das zählt, zu Einträgen umstrukturieren, die wichtigen Links als Wiki-Links neu aufbauen, Labels anwenden und die Kundeneinträge verschlüsseln. Dann erledigt die Migration auf Anforderung den langen Schwanz während echter Arbeit, wenige Seiten auf einmal, über die folgenden Wochen. Skalieren Sie die Schätzung an der Form Ihres eigenen Graphen, nicht allein an seiner Seitenzahl. Tausend Seiten, gebaut auf Blockreferenzen und Abfragen, können länger dauern als viertausend Seiten Dokumente. Und seien Sie misstrauisch gegenüber jeder Schätzung, auch dieser, die den Parallelbetriebsmonat nicht einschließt: Der Dateiumzug ist ein Problem von einem Nachmittag bis zu einem Wochenende, aber eine Migration ist nicht beendet, wenn die Dateien ankommen. Sie ist beendet, wenn die Morgen funktionieren.

Was bricht? Benennen Sie es, ohne zu zucken. Blockreferenzen und Einbettungen brechen — sie werden zu gewöhnlichem Text und Links oder werden von Hand umgeschrieben. Abfragen brechen; ihre Alltagsaufgaben werden von Suche, Labels und der Seitenleiste Fällig und Ablaufend aufgenommen, aber die Abfragen selbst übertragen sich nicht. Seiteneigenschaften tragen sich nicht als strukturiertes System hinüber; alles, was eine Eigenschaft meinte, muss als Label, als Datum oder als Worte im Eintrag neu ausgedrückt werden. Der Journal-Fluss ändert seine Form, von einem automatischen Strom zu datierten Einträgen mit Kalender und Zuletzt. Die Graphenansicht endet. Das Plugin-Verhalten endet. Wenn irgendein Posten auf dieser Liste ein tragender Teil Ihrer Praxis ist, lesen Sie den Limits-Abschnitt erneut, bevor Sie fortfahren, denn keine Technik in diesem Leitfaden stellt diese Dinge wieder her, und etwas anderes vorzutäuschen würde Ihr Wochenende und Ihren guten Willen verschwenden. Was nicht bricht, zählt auch: Ihr Text. Jedes Wort, das Sie schrieben, kommt an, denn Markdown ist tragbar und VaultBook-Einträge sind daraus gebaut. Das Schreiben überlebt den Umzug intakt; es ist die Maschinerie um das Schreiben, die sich ändert.

Was ist mit der Datenbankfrage — sollte ich vor oder nach dem Ausprobieren von Logseq 2.0 migrieren? Dieser Leitfaden bezieht keine Position zu den Verdiensten der Datenbankversion; manche Nutzer berichten von echten Gewinnen durch sie, und ihre Graphen und ihr Urteil sind ihre eigenen. Die Zeitpunkt-Beobachtung ist enger, und sie ist die, nach der Elena handelte: Von der dateibasierten Version zu migrieren bedeutet, von reinen Markdown-Dateien zu migrieren, die jedes Werkzeug heute lesen kann, in einem Moment, in dem diese Tragbarkeit auf ihrem Maximum ist. Die Diskussionen unter Nutzern sind sich über die Mechanik des anderen Wegs einig — Export aus der Datenbankversion zurück nach Markdown verliert Ordnerstruktur und Assets, und Material, das in Spiegelmodi als fehlend berichtet wurde, bedeutet, dass der Rundweg Sie nicht dorthin zurückbringt, wo Sie begannen. Wenn es irgendeine Chance gibt, dass Sie Ihren Graphen eines Tages wieder als saubere Dateien wollen, ist der kostengünstige Moment, diese Option zu sichern, jetzt, solange die Dateien bereits Dateien sind. Machen Sie die oben beschriebene Archivkopie, auch wenn Sie sich zu bleiben entscheiden: Eine unberührte Markdown-Momentaufnahme, heute gemacht, ist billige Versicherung unter jedem künftigen Szenario, einschließlich desjenigen, in dem Sie die Datenbankversion glücklich ein Jahrzehnt lang nutzen und sie nie brauchen.

Kann ich zurück? Ja — sauber, und konstruktionsbedingt. Dies ist die Eigenschaft, auf der Elena bestand, bevor sie begann, und die Eigenschaft, auf der auch Sie bestehen sollten. Weil die in diesem Leitfaden beschriebene Migration den ursprünglichen Graphen nie verändert und weil Sie das rohe Markdown-Archiv unberührt behalten, ist Zurückgehen keine Rettungsaktion. Öffnen Sie Logseq, zeigen Sie es auf den archivierten Graphen, und Ihre vier Jahre sind exakt dort, wo Sie sie verließen. Die Einträge, die Sie während der Erprobung in VaultBook bauten, sind die einzige versunkene Kostenstelle, und selbst sie sind keine Geisel: Die Arbeit, die Sie während eines Monats echter Nutzung im Tresor leisteten, ist echte Arbeit, lesbar und als Dokumente exportierbar, was immer Sie über das Werkzeug entscheiden. Nach einer ehrlichen Erprobung zurückzugehen, weil sich die Graphenansicht oder Blockreferenzen als tragend für Sie herausstellten, ist ein erfolgreiches Experiment mit klarem Ergebnis — keine gescheiterte Migration. Das einzige wirklich schlechte Ergebnis, das es hier gibt, ist dasjenige, dessen Verhinderung die Dreißig-Tage-Disziplin existiert: nie vollständig in irgendeinem System anzukommen, Ihr Wissen über zwei Werkzeuge zu gabeln, bis keinem von beiden zugetraut werden kann, die ganze Geschichte zu halten.

Sollte ich alles verschlüsseln, um sicher zu gehen? Nein. Verschlüsseln Sie die Einträge, deren Exponierung Ihnen oder jemandem, der Ihnen vertraute, schaden würde: Kundenmaterial, zugangsdatennahe Notizen, die persönlichen Datensätze, die Sie nicht laut vorlesen würden. Lassen Sie den gewöhnlichen Großteil des Tresors offen, damit Suche, Frage-Antwort und Ihre eigene Morgenroutine reibungslos bleiben. Sicherheit, die das Werkzeug unangenehm macht, wird von müden Menschen in geschäftigen Momenten still abgeschaltet, und eine müde Person in einem geschäftigen Moment ist diejenige, für die all dies letztlich da ist. Die Verschlüsselung pro Eintrag existiert gerade, damit die Linie vernünftig gezogen werden kann — nutzen Sie sie, um die Linie dort zu ziehen, wo das Risiko tatsächlich lebt.

Drei Monate später

Elenas Tresor, drei Monate nach dem Ende der Parallelwoche, ist kein Monument. Er ist eine Arbeitsdatei mit den Gewohnheiten einer arbeitenden Person darin, was ein besseres Ergebnis ist als ein Monument.

Ihre Morgen sind vier Handgriffe lang: der datierte Eintrag von heute, die Zuletzt-Seitenleiste, um die Fäden von gestern wieder aufzunehmen, die Liste Fällig und Ablaufend, überflogen beim Kaffee, und dann die erste echte Aufgabe — die nun öfter neben ihren Quellennotizen in einem Tab sitzt, als dass sie es nicht täte. Die Journalgewohnheit überlebte den Umzug, in der Mechanik verändert und in der Funktion intakt. Das Erfassen ist langweilig geworden, und langweilig ist das höchste Lob, das sie für Infrastruktur hat: Sie tippt, es ist da, der Gedanke endet. Sie hat seit elf Wochen nicht über Sync nachgedacht, außer einmal — als eine Kollegin, mit der besonderen Müdigkeit, die die Leser dieses Leitfadens vielleicht erkennen, einen Morgen beschrieb, der an einen stillstehenden Graphen und einen erneuten Download verloren ging — und sie die kleine, unglamouröse Erleichterung eines Problems spürte, das nicht mehr wie ihr Leben geformt ist.

Die Kundenarbeit ist die Stelle, an der sich die Veränderung verzinst hat. Zwei neue Mandate wurden von ihren ersten Einträgen an verschlüsselt eingerichtet, als Routineangelegenheit statt als Vorsatz. Ein Interview wurde lokal transkribiert, noch am selben Nachmittag, an dem es aufgezeichnet wurde, und der Ausschnitt, den sie brauchte, wurde aus dem Audio geschnitten, ohne dass die Aufzeichnung je ihre Maschine verließ. Als ein Kunde in der sorgfältigen Sprache, die Kunden gebrauchen, fragte, wie ihr Material gespeichert werde, hatte sie eine kurze Antwort, die vollständig wahr war: in einem verschlüsselten Tresor, auf ihrer Hardware, unter der Kontrolle keines Dritten, mit Versionsverlauf und datierten Backups. Die Vertragssprache und die Wirklichkeit stimmten zum ersten Mal in ihrer Praxis überein, und sie bemerkte, dass der Kunde es bemerkte.

Das ist, am Ende, das ganze Argument dieses Leitfadens, entkleidet seiner Tausende von Worten. Migrieren Sie, wenn Ihr Graph zu einem Bestand von Dokumenten geworden ist, der mehr Empfindlichkeit trägt, als reiner Text tragen sollte, auf einer Plattform, deren Richtung und Sync Sie nicht mehr vollständig vertrauen — und tun Sie es jetzt, bewusst, solange Ihre Markdown-Dateien das Gehen leicht und das Archiv es umkehrbar machen. Bleiben Sie, wenn der Graph, die Blöcke und die Abfragen das Denken selbst sind; kein ehrlicher Leitfaden würde sie Ihnen nehmen. Machen Sie in jedem Fall heute die Archivkopie. Zukünfte sind für jedes Werkzeug in dieser Geschichte ungewiss. Ein Ordner Ihrer eigenen Worte, in Dateien, die Sie lesen können, an einem Ort, den Sie kontrollieren, ist die eine Absicherung, die unter allen von ihnen auszahlt.