Import, Herkunft und Weitergabe

Import: was geschrieben wird, was es niemals ist

Das Importieren eines Matches, einer Stellung oder einer anderen Datenbank fügt hinzu, was fehlt; es ersetzt nicht, was bereits da ist.

Eine Stellung wird niemals dupliziert. Ihre Identität — Steine, Doppler, Würfel, Spielstand — erkennt sie, niemals die Datei, aus der sie stammt: Dieselbe in zwei Matches angetroffene Stellung bleibt eine einzige Zeile.
Der Import einer Datenbank liest alles ein, was ein Export schreibt. Die Positionen mit ihren Analysen und Kommentaren, aber auch die Matches (einschließlich Partien und Züge), die Turniere mit ihrer Leitung und ihrer Begegnung, die Transkriptionsentwürfe, die Aliasse, die Sammlungen, die Lektionen und die Anki-Stapel: siehe Datenbank zusammenführen. Nichts wird überschrieben: Ein bereits vorhandenes Match wird nicht erneut kopiert, ein gleichnamiges Turnier erhält die Matches, ohne das Datum des Ereignisses zu ändern (sein Datum der letzten Änderung rückt vor, da es neue Matches erhält), ein Turnier, das bereits seine Leitung hat, behält sie und bleibt außerhalb der importierten Begegnung, ein bereits in einem anderen Turnier oder an einer anderen Stelle der Tabelle abgelegtes Match bleibt dort, und was die Datenbank bereits entschieden hatte, bleibt von ihr entschieden. Die vom Import angelegten Turniere, Leitungen, Begegnungen, Transkriptionsentwürfe und Aliasse behalten ihre ursprünglichen Daten; die angelegten Sammlungen, Lektionen und Anki-Stapel nicht.
Eine Analyse pro Engine. eXtreme Gammon, GNUbg, BGBlitz und der eingebaute Evaluator koexistieren auf derselben Stellung, und das Analyse-Panel gibt die Herkunft jeder einzelnen an. Das Importieren der einen löscht die andere nicht.
Eine importierte Analyse wird nie neu berechnet. blunderDB legt sie unverändert ab, mit ihrer Stufenbezeichnung („3-Ply“, „XG Roller++“, „Book“), ihren Equities, ihren Fehlern, ihren Wahrscheinlichkeiten und dem Würfelglück. Die Regel lautet „eine Bewertung füllt nur eine Lücke“: Die automatische Analyse nach dem Import besucht nur die Stellungen ohne jede Analyse, und die Neuanalyse veralteter gammonNet-Analysen lässt jede Stellung mit importierter Analyse unangetastet (siehe Konfiguration).
Ein bereits vorhandenes Match erneut zu importieren bringt nur Tieferes. Das Match wird an seinem Spiel erkannt (Spieler, Länge, Würfe, Züge, Doppler), nicht an seiner Analyse: Kein Match, keine Partie und kein Zug wird neu geschrieben. Die in der Ursprungssoftware gesetzten Markierungen werden hinzugefügt, und eine tiefere Analyse als die gespeicherte ersetzt diese, Position für Position — eine Roller++-Version desselben Matches ersetzt die 3-ply-Version, unabhängig von der Importreihenfolge; bei gleicher oder geringerer Tiefe bleibt die gespeicherte Analyse. Dieselbe Datei erneut zu importieren schreibt also nichts neu. Der Importbericht unterscheidet Duplikate, die nichts brachten, von denen, die Analysen vertieft haben. In der Kommandozeile überspringt --skip-duplicates ein Duplikat und übernimmt davon nur die Markierungen. Ein abgeschnittenes und später vervollständigtes Match (mehr Partien) ist nicht dasselbe Match: Es wird als zweites Match importiert.
Eine unlesbare Analyse verhindert den Import des Matches nicht. Eine Entscheidung, deren Analyse einen Wert enthält, der keine endliche Zahl ist (NaN oder unendlich, wie manche XG-Dateien sie enthalten), wird ohne diese Analyse importiert; der Rest des Matches wird normal übernommen, und der Importbericht zählt die betroffenen Entscheidungen.
Ein bereits unter anderen Namen vorhandenes Match wird gemeldet, nie zusammengeführt. Die beiden Match-Fingerabdrücke enthalten die Spielernamen: „Martin A.“ und „Alice Martin“ ergeben zwei Matches. Der Import vergleicht auch die Würfel (Länge, Anfangsstand, Würfel jedes Spiels) und meldet unter der Zeile der Datei und im Bericht das bereits unter anderen Namen in der Datenbank vorhandene Match, dessen Würfel es hat. blunderdb repair --duplicates listet diese Paare in einer bestehenden Datenbank auf, ebenso abgebrochene Matches und ihre längere Version.
Ein unter anderer Schreibweise bekannter Name wird unter seinem kanonischen Namen gespeichert. Ein Alias besagt, dass „Martin A.“ eine andere Schreibweise von „Alice Martin“ ist (oder dass ein Veranstaltungsname eine andere von einem anderen ist). Beim Import werden die Namen der Spieler und der Veranstaltung durch ihren kanonischen Namen ersetzt, und das Match wird im Turnier der kanonischen Veranstaltung abgelegt. Die Fingerabdrücke des Matches behalten die Namen der Datei: Eine Datei, die importiert wurde, bevor ihr Alias existierte, wird daher weiterhin erkannt. Ein Match, dessen Würfe die eines vorhandenen Matches sind und dessen Namen sich nur durch bekannte Aliasse unterscheiden, ist kein zweites Match: Seine Analysen bereichern das abgelegte.

Die Aliasse werden in der Registerkarte Korpus der Einstellungen verwaltet: Spieler oder Veranstaltungen wählen, den Alias und den kanonischen Namen eingeben oder einen Alias aus der Liste entfernen. Vorschlagen listet die Namen auf, die sich nur in Groß-/Kleinschreibung, Akzenten, Zeichensetzung oder Wortreihenfolge unterscheiden; nichts wird ohne Klick auf Übernehmen angewendet. Dieselbe Registerkarte enthält das Kontrollkästchen Duplikate beim Import überspringen (das Äquivalent von --skip-duplicates, für die Sitzung) und die Suche nach den wahrscheinlichen Duplikaten einer vorhandenen Datenbank, die von blunderdb repair --duplicates: Jedes Paar wird durch seine Matchnummern angegeben, nichts wird zusammengeführt. Unter einem Paar mit denselben Würfeln legt Diese Aliasse erstellen mit einem Klick die Spieler-Aliasse an, mit denen beide Matches dieselben Spieler nennen würden, wobei die Schreibweise des neueren Matches zum Alias wird: nur ein Vorschlag, wenn ein Name beiden gemeinsam ist, sonst zwei — Sitz für Sitz, dann über Kreuz —, von denen man den wählt, der sagt, wer wer ist. Auf der Kommandozeile: blunderdb players alias und blunderdb events alias.

Ein Ordner wird parallel importiert. Die Dateien werden auf mehreren Kernen gleichzeitig gelesen und in Gruppen geschrieben, stets in der Reihenfolge des Ordners: Die Matchnummern hängen nicht von der Maschine ab. Eine Datei, die Byte für Byte mit einer bereits gelesenen Datei desselben Ordners übereinstimmt, wird nicht erneut gelesen: Sie zählt als Duplikat. Abbrechen stoppt den Import bei der laufenden Gruppe; was bereits geschrieben wurde, bleibt.
Der Fortschritt wird in Positionen pro Sekunde gemessen. Das Importfenster zeigt den gelesenen Prozentsatz, den Durchsatz, die geschätzte Restzeit und die laufenden Zähler (importiert, Duplikate, fehlerhaft). Minimieren legt es in die Statusleiste, wo ein Chip es wieder öffnet: Der Import läuft weiter, während Sie arbeiten, und das Fenster kehrt am Ende von selbst mit dem Bericht zurück. Die ersten hundert Fehler werden aufgelistet; die übrigen werden gezählt, und das Anwendungsprotokoll nennt sie alle. Auf der Kommandozeile zeigt blunderdb import --type batch denselben Fortschritt auf der Standardfehlerausgabe, und --format json gibt ihn im abschließenden Objekt zurück (progress).
Jede Datei eines Imports wird protokolliert, und ein unterbrochener Import lässt sich fortsetzen. Für jede Datei speichert das Stapeljournal den Pfad, die Größe, das Änderungsdatum, den SHA-256-Fingerabdruck und das Ergebnis: neues Match (mit seiner Nummer), Duplikat (mit dem Match, das es abdeckt), angereichertes Match oder Fehler (mit der Meldung). Ein abgebrochener oder unterbrochener Import wird fortgesetzt, ohne das bereits Entschiedene zu wiederholen: Eine Datei mit gleichem Pfad, gleicher Größe und gleichem Datum wird übersprungen, ohne gelesen zu werden; eine Datei mit gleichem Inhalt wird gelesen, aber nicht analysiert; eine fehlerhafte Datei wird erneut versucht. In der Anwendung listet das Fenster am Ende des Imports das Journal auf (eine Datei pro Zeile, mit ihrem Ergebnis und der Meldung bei einem Fehler; eine erneut versuchte Datei zeigt ihr letztes Ergebnis), und eine Zeile, die ein Match ergeben hat, öffnet es. Ein abgebrochener Import lässt das Fenster mit der Schaltfläche Fortsetzen geöffnet. In der Befehlszeile setzt blunderdb import --type batch --dir <Ordner> --resume <Stapel> den Stapel fort, dessen Nummer beim Start des Imports angezeigt wurde, und --format json gibt das Journal im Endobjekt aus (journal). Der Server akzeptiert resume in der Anfrage von imports.batch und liefert das Journal über imports.files. Das Journal ist ein Datum des Imports: Das Öffnen oder Lesen einer Datenbank schreibt nichts hinein.
Ein durch das Beenden der Anwendung unterbrochener Import wird über das Fenster fortgesetzt. Der Befehl :resume listet die Importe auf, die nichts beendet hat; man wählt den fortzusetzenden aus und gibt dann Ordner oder Dateien erneut an, wie --dir auf der Kommandozeile. Das Journal des Stapels entscheidet, was nicht erneut gelesen wird.
Ein großer Ordner wird im Massenmodus importiert. Ab 200 Dateien schreibt blunderDB mit einem größeren Cache und weniger Checkpoints. Enthält die Datenbank noch keine Position, geht es weiter: Die Suchindizes werden erst am Ende neu aufgebaut, und die Schreibvorgänge werden nicht mehr mit der Festplatte synchronisiert. Ein Stromausfall während eines solchen Imports kann die Datenbank dann beschädigen: Sie muss neu angelegt und der Import erneut gestartet werden. Ein Absturz des Programms hinterlässt dagegen nur fehlende Indizes, die beim nächsten Öffnen neu aufgebaut werden (das Protokoll meldet es).
Was blunderDB nie schreibt: ein neu berechnetes Glück — es wird aus der Quelldatei gelesen oder bleibt unbekannt — und ein Rollout, das es nicht selbst gestartet hat: Die Rollout-Daten in einer .xg-Datei werden nicht geöffnet. Nur die Rollouts, die blunderDB selbst erzeugt (Rollouts), werden neben der Analyse gespeichert.

Metadaten-Panel

Das Panel Metadaten (STRG-M) zeigt die allgemeinen Informationen der aktuellen Datenbank an: Benutzer, Erstellungsdatum (Erstellt), Version des Schemas und Beschreibung. Benutzer, Datum und Beschreibung werden an Ort und Stelle bearbeitet und beim Verlassen des Feldes gespeichert; die Version ist schreibgeschützt. Auch über den Befehl meta erreichbar.

Es zeigt außerdem, sofern vorhanden, die Herkunft der Datenbank an — siehe Eine Datenbank weitergeben: Herkunft und Passwort. Bei einer gewöhnlichen Datenbank erscheint dieser Abschnitt nicht.

Eine Datenbank weitergeben: Herkunft und Passwort

Wer als Lehrender eine Positionsdatenbank verteilt, hat zwei voneinander unabhängige Mechanismen zur Hand, beide optional und beide beim Export zu wählen: die Datei mit ihrer Herkunft zu kennzeichnen und sie mit einem Passwort zu schützen.

Bemerkung

Keiner von beiden verfolgt, was aus der Datei wird. blunderDB zeichnet auf der Empfängerseite nichts auf: Eine gekennzeichnete Datenbank zu öffnen ist genau wie jede andere zu öffnen, und nirgends wird festgehalten, wer sie wann geöffnet hat oder woher ihr Inhalt stammt.

Eine Datenbank mit ihrer Herkunft kennzeichnen

Das Exportfenster passt auf einen einzigen Bildschirm: eine Kopfleiste — die Zahl der exportierten Stellungen, Abbrechen und Exportieren… — dann ein Raster mit einer Zeile pro Familie samt ihrer Anzahl. Diese Zahlen sind exakt: Sie werden bei jeder Änderung eines Kästchens vom Server gelesen, auf derselben Auswahl wie der Export, und sind das, was die Datei enthalten wird. Die Datei wird zuletzt gewählt, nach Exportieren…; schließt man diese Auswahl ohne Namen, kehrt man zum Raster zurück. Während des Schreibens blendet sich eine Fortschrittsanzeige ein, das Fenster schließt sich von selbst und das Ergebnis erscheint in der Statusleiste.

Neun Punkte verdienen Beachtung:

Der Umfang: Ausgehend von einer Liste — einer Suche, einer Sammlung — wählt die Zeile Umfang zwischen Aktuelle Liste und Gesamte Bibliothek. Die aktuelle Liste exportiert ihre Stellungen, und die Zeile Matches bietet nur die Matches an, in denen diese Stellungen gespielt wurden; jedes angehakte Match wird mit allen seinen Stellungen mitgenommen. Aus der Bibliothek heraus ist der Umfang die Bibliothek.
Gesamte Bibliothek ist der Export des Servers und von export --type database: Alle Familien sind von vornherein angehakt, die Anki-Stapel mit ihrem Wiederholungsverlauf, und die laufenden Transkriptionen werden mit dem Rest mitgenommen.
Die Synchronisierung: Bei Gesamte Bibliothek bietet die Zeile Synchronisierung die Option Nur Neues seit dem letzten Export in diesen Ordner und die Schaltfläche Ordner wählen… an. Die Datei wird dann nicht mehr abgefragt: Sie wird in diesem Ordner unter einem neuen Namen geschrieben, und die Zahlen sind die des Neuen (siehe Zwei Rechner synchronisieren).
Ein Match wird mit seinem Transkriptionsentwurf mitgenommen, unter dem Kästchen Transkriptionen der Zeile Matches, das von vornherein angehakt ist; ebenso die Matches, die ein Turnier mitnimmt. Ein Entwurf, der noch kein Match hervorgebracht hat, wird nur mit der gesamten Bibliothek mitgenommen. Ein Match oder eine Transkription, die mit einem lokalen Video verknüpft sind, nehmen nur den Dateinamen ohne den Ordner mit, den der Empfänger auf seiner eigenen Kopie neu zuordnet; ein Weblink wird unverändert mitgenommen. Auch die Datei, aus der ein Match importiert wurde, wird nur mit ihrem Namen mitgenommen.
Ein Match wird mit den Aliassen seiner Spieler und seines Ereignisses mitgenommen: Das Kästchen Aliasse, von vornherein angehakt, lässt die Spielerzusammenführung mitwandern, und der Empfänger liest einen zusammengeführten Spieler als einen einzigen. Ein Alias, der keinen Spieler der exportierten Matches benennt, bleibt bei Ihnen.
Eine Sammlung, deren Stellungen nicht alle in der Liste stehen, kommt gekürzt an. Die Sammlungsliste zeigt für jede den abgedeckten Anteil („12/40“) und markiert ihn rot, wenn er unvollständig ist. Das Kästchen + ihre Positionen nimmt die Stellungen der angehakten Sammlungen mit: die einer von Hand erstellten Liste, die, die die Abfrage einer lebendigen Sammlung auswählt. Eine lebendige Sammlung, deren Abfrage Zeilen nennt, die nicht in der Datei stehen, kommt eingefroren an: Sie erscheint als die Liste, die ihre Abfrage heute auswählt; die Liste markiert sie rot als „eingefroren“ mit einem Hinweis. Mit + ihre Positionen bleibt sie lebendig.
Ein Turnier wird immer mit seinen Matches exportiert: Ohne sie gäbe es die Verbindung Turnier–Match nicht, und das Turnier käme leer an. Wer ein Turnier ankreuzt, nimmt seine Matches mit, auch wenn das Matches-Feld nicht angekreuzt oder auf andere beschränkt ist. Es wird auch mit seiner Leitung exportiert — Journal, Paarungen, Tische und Zuordnung der exportierten Matches —, und seine Begegnung wird exportiert, sobald eines ihrer Turniere exportiert wird; der Ausgabeordner der Leitung bleibt bei Ihnen. Die Leitung findet man beim Öffnen der Datei wieder oder indem man sie in eine andere Datenbank importiert.
Ein Anki-Stapel wird mit seinen Stellungen mitgenommen, als neue Lernkopie. Das Kästchen mit meinem Verlauf nimmt zusätzlich den Zustand jeder Karte und das Protokoll ihrer Wiederholungen mit: eine Sicherung oder Ihre auf einen anderen Rechner übertragenen Stapel. Es ist für eine Liste nicht angehakt, für die Bibliothek angehakt.
Die gespeicherten Filter exportieren keinen Inhalt, sondern Ihre eigenen Suchen, die in der Datenbank eines anderen nutzlos sind; das Kästchen ist für eine Liste nicht angehakt. Ein Filter, der eine Stellung, ein Match oder ein Turnier über seine Nummer bezeichnet, wird für die Datei neu nummeriert; bezeichnet er eines, das nicht mitgenommen wird, bleibt er bei Ihnen.

Sammlungen, Lektionen, Transkriptionen, Anki-Stapel, Aliasse und Turniere werden mit den Erstellungs- und Hinzufügungsdaten exportiert, die sie bei Ihnen tragen, nicht mit dem Exportdatum.

Die Felder Benutzer, Beschreibung und Erstellungsdatum beschreiben die erzeugte Datei; sie werden aus der Quelldatenbank vorausgefüllt.

Ein Häkchen bei Wasserzeichen blendet zwei Felder ein:

Herkunft — was diese Datei ist und woher sie kommt, in Ihren eigenen Worten: „Kurs von Jean Dupont — 12. März 2026“. Dieses Feld ist obligatorisch: Solange es leer ist, ist es rot umrandet und die Export-Schaltfläche bleibt inaktiv.
Hinweis, optional — Nutzungsbedingungen, eine Kontaktadresse, die Bitte, die Datei nicht weiterzugeben.

Die Kennzeichnung wird mit Ihrer Ausstelleridentität signiert. Sie ist damit unverfälschbar und nicht nachahmbar: Niemand kann sie verändern oder eine in Ihrem Namen erzeugen. Sie ist dagegen nicht unlöschbar — die verteilte Datei ist eine gewöhnliche SQLite-Datenbank, und blunderDB ist freie Software. Sie verhindert nichts: Sie sagt, woher die Datei kommt.

Die von Ihnen geschriebenen Kommentare werden mit derselben Identität signiert: Der Empfänger sieht, dass sie von Ihnen stammen und ob sie unterwegs verändert wurden (siehe Kommentare-Panel). Ein Kommentar, der bereits die Signatur eines anderen Ausstellers trägt, behält sie. Die Statusleiste nennt am Ende des Exports, wie viele Ihrer Kommentare signiert wurden; ein Export ohne Markierung signiert keinen.

Ausstelleridentität

Die Kennzeichnungen werden mit Ihrer Ausstelleridentität signiert, die beim ersten Kennzeichnen einer Datei von selbst angelegt wird; es ist nichts einzurichten. Sie gehört zu einer Person und nicht zu einer Datenbank: Alle Ihre Dateien tragen denselben öffentlichen Fingerabdruck der Form A3F1-9C24-7B05-E1D8.

Sie können diesen Fingerabdruck Ihren Empfängern mitteilen, damit sie prüfen können, dass eine Datei tatsächlich von Ihnen stammt. Die Identität lässt sich als einzelne Datei (Endung .bdbid) von einem Rechner auf den anderen mitnehmen, auf Wunsch durch eine Passphrase geschützt. Mit dieser Datei kann in Ihrem Namen signiert werden: Geben Sie sie nicht weiter.

In den Einstellungen (Zahnradsymbol in der Werkzeugleiste) zeigt die Registerkarte Ausstelleridentität Ihren Namen und Ihren Fingerabdruck an und bietet Identität speichern…, Identität laden… und Neu erzeugen… an.

Warnung

Neu erzeugen widerruft nichts. Ein Wasserzeichen enthält den öffentlichen Schlüssel, mit dem es signiert wurde: Es lässt sich daher für immer aus sich selbst heraus prüfen. Ist Ihre Identitätsdatei abhandengekommen, kann derjenige, der sie besitzt, weiterhin unter Ihrem alten Fingerabdruck signieren, und diese Kennzeichnungen bleiben gültig.

Was Sie nach einem solchen Verlust schützt, ist keine Software: Es ist, Ihren neuen Fingerabdruck zu veröffentlichen und den alten gegenüber Ihren Empfängern für ungültig zu erklären.

Das Neuerzeugen überschreibt den aktuellen Schlüssel; blunderDB bietet an, ihn vor dem Ersetzen zu speichern.

Eine Datenbank mit einem Passwort schützen

Das Passwort wird verdeckt eingegeben, hier wie beim Öffnen einer geschützten Datei; das Augensymbol zeigt es an, solange es gedrückt gehalten wird, und verdeckt es wieder, sobald man loslässt.

Ein Häkchen bei Passwort erzeugt eine Datei mit der Endung .dbx — auch wenn der im Speichern-Dialog gewählte Name auf .db endet. Zum Öffnen verwenden Sie das übliche Öffnen einer Datenbank: Das Auswahlfenster akzeptiert .db und .dbx gleichermaßen. blunderDB fragt dann nach dem Passwort und legt daneben eine gewöhnliche Datenbank an; danach wird nichts mehr abgefragt.

Das Fenster bietet an, die geschützte Datei nach dem Öffnen zu löschen: Andernfalls behalten Sie denselben Inhalt unter zwei Namen. Das Kästchen ist standardmäßig nicht angehakt — die geschützte Datei bleibt Ihnen erhalten, wenn Sie sie weitergeben wollen — und gelöscht wird erst nach einem erfolgreichen Öffnen.

Warnung

Das Passwort schützt die Datei auf dem Transportweg, nicht die Datenbank. Es hindert Dritte daran, eine Datei zu öffnen, die in einem Download-Ordner liegt oder als versehentlich weitergeleiteter Anhang ankommt. Vor demjenigen, dem Sie das Passwort gegeben haben, schützt es nicht.

Das Passwort wird bei jedem Öffnen geprüft, auch wenn die Datei auf diesem Rechner schon einmal geöffnet wurde.

Technisch wird die Datenbank mit AES-256 im GCM-Modus verschlüsselt, mit einem Schlüssel, der per Argon2id (64 MiB Speicher, 3 Durchläufe, 4 Threads) aus dem Passwort abgeleitet wird, und einem zufälligen, für jede Datei eigenen Salt. Der GCM-Modus authentifiziert das Ganze: Ein falsches Passwort wird als solches erkannt, ebenso jede Veränderung der verschlüsselten Datei — man erhält nie stillschweigend eine beschädigte Datenbank.

Der Kopf der geschützten Datei bleibt unverschlüsselt: Ihre Herkunft ist auch ohne Passwort lesbar.

Die Herkunft einer Datei lesen

Öffnen Sie in der Anwendung die Datei und blenden Sie das Panel Metadaten ein (Befehl meta). Am Kopf des Panels erscheint schreibgeschützt ein Abschnitt Herkunft, der angibt, was eingetragen wurde, von wem, wann, und wie es um die Signatur steht:

„✓ von Ihnen gekennzeichnet“: Die Datei trägt Ihre Kennzeichnung, unversehrt;
„✓ Signatur geprüft“: Die Kennzeichnung ist unversehrt und stammt von einem anderen Schlüssel — vergleichen Sie ihren Fingerabdruck mit dem, den der Ersteller Ihnen mitgeteilt hat;
„⚠ Signatur ungültig“: Das Dokument wurde verändert oder gefälscht.

Bei einer gewöhnlichen Datenbank erscheint dieser Abschnitt nicht.

Auf der Kommandozeile zeigt blunderdb info --db datei.db die Herkunft und den Zustand der Signatur an, ohne jemals in die Datei zu schreiben. Der Befehl funktioniert auch bei einer geschützten Datei, ohne das Passwort. Siehe CLI_USAGE.md für die Optionen --watermark und --password von export sowie für identity und open.

Eine Datenbank für andere veröffentlichen

Eine markierte Datenbank wird wie jede andere Datei verteilt — E-Mail, eigene Website, USB-Stick. blunderDB bietet keinen Dienst: kein Repository, keinen gehosteten Katalog, kein Konto. Das folgt unmittelbar aus seiner Bauart: auf der Seite dessen, der eine Datei erhält, wird nie etwas aufgezeichnet, es gäbe also nichts an einen Dienst zu melden, selbst wenn es einen gäbe.

Was eine veröffentlichte Datenbank für andere brauchbar macht, hängt an vier Feldern, die alle schon da sind:

Benutzer — wer sie zusammengestellt hat, unter dem Namen, der genannt werden soll.
Beschreibung — was die Datenbank enthält, in einem Satz, der in eine Liste passt: „240 Dopplerentscheidungen beim Stand, kommentiert, mittleres Niveau“.
Herkunft (des Wasserzeichens) — was diese Datei ist und für wen sie erzeugt wurde. Es ist das Erste, was der Empfänger im Panel Metadaten liest.
Ausstellerfingerabdruck — veröffentlichen Sie ihn neben der Datei, nicht darin: an seinem Vergleich prüft der Empfänger, dass die Datei von Ihnen kommt und nicht von jemandem, der Ihren Namen übernommen hat.

Eine ohne Wasserzeichen veröffentlichte Datenbank bleibt vollkommen brauchbar; sie ist einfach anonym, und das Panel Metadaten zeigt dann keinen Abschnitt Herkunft.

Um eine Datenbank bekannt zu machen, dient die Kategorie Show and tell der Diskussionen des Repositorys als Verzeichnis: eine Liste, geführt von denen, die veröffentlichen, kein von blunderDB erbrachter Dienst. Eine dort anzukündigen braucht den Link, die vier obigen Felder und den Fingerabdruck.