Christian's Blog

Projekt JARVIS, Tag 3: JARVIS braucht einen neuen Namen

Chris //

Nach Wetter, Kalender und den ersten funktionierenden Werkzeugen war eigentlich klar, womit es als Nächstes weitergehen sollte.

Routing.

Warnungen.

Eine API.

Vielleicht irgendwann Sprache.

Stattdessen habe ich einen erstaunlich großen Teil des nächsten Tages mit einer ganz anderen Frage verbracht:

Wie soll das Projekt eigentlich heißen?

Denn JARVIS war von Anfang an nur ein Arbeitsname.

Warum nicht einfach JARVIS?

Der Name liegt natürlich nahe.

Wer einen persönlichen KI Assistenten baut und Iron Man kennt, landet ziemlich schnell bei JARVIS.

Das war bei mir nicht anders.

Für die ersten Tests war das auch völlig ausreichend.

jarvis

ist kurz, verständlich und jeder weiß ungefähr, was gemeint ist.

Je weiter das Projekt allerdings gewachsen ist, desto mehr wurde aus dem kleinen Experiment ein richtiges Softwareprojekt.

Es gibt inzwischen eine eigene CLI, Module, Konfigurationsdateien, Services, eine API und eine Dokumentation.

Spätestens damit stellte sich die Frage, ob ich das Projekt wirklich dauerhaft JARVIS nennen möchte.

Und da wird es schwierig.

JARVIS ist nicht gerade ein einzigartiger Name.

Neben der offensichtlichen Verbindung zu Marvel findet man inzwischen unzählige Assistenten, GitHub Projekte und KI Experimente mit genau diesem Namen.

Für einen privaten Test spielt das keine große Rolle.

Für ein öffentliches Open Source Projekt schon eher.

Also braucht das Projekt einen eigenen Namen

Meine Anforderungen wirkten zunächst eigentlich recht simpel.

Der Name sollte:

  • eigenständig sein
  • zu einem lokalen KI Assistenten passen
  • als Projektname funktionieren
  • als Repository Name funktionieren
  • im Terminal nicht merkwürdig aussehen
  • international halbwegs verständlich sein
  • nicht bereits von einem großen Softwareprojekt verwendet werden
  • auch noch passen, wenn das Projekt irgendwann deutlich größer wird

Und genau an diesem Punkt wurde die Sache kompliziert.

Denn Namen zu finden ist einfach.

Einen guten Namen zu finden, der nicht bereits verwendet wird, ist erstaunlich schwierig.

Die erste Erkenntnis: Produktname und Assistent müssen nicht identisch sein

Anfangs hatte ich zusätzlich die Idee, dass der neue Name gleichzeitig als Anrede für den Assistenten funktionieren muss.

Also etwa:

Hey Jarvis

Der neue Name sollte deshalb gut ausgesprochen werden können und möglichst auch mit verschiedenen Stimmen funktionieren.

Das schränkt die Auswahl allerdings enorm ein.

Irgendwann kam dann die eigentlich ziemlich offensichtliche Erkenntnis:

Warum müssen Produktname und Assistent überhaupt gleich heißen?

Das Softwareprojekt kann einen eindeutigen technischen Namen bekommen.

Wie der Assistent später angesprochen wird, kann davon vollkommen unabhängig sein.

Zum Beispiel:

assistant:
  name: Jarvis

Oder:

assistant:
  name: Computer

Oder irgendwann ein komplett anderer Name.

Damit wurde die Namenssuche erheblich einfacher.

Sehr viele Namen später

Was danach folgte, war vermutlich deutlich mehr Aufwand, als ich ursprünglich dafür eingeplant hatte.

Es entstanden mehrere Listen mit möglichen Namen.

Einige klangen gut, waren aber bereits vergeben.

Andere waren technisch interessant, ließen sich aber schlecht aussprechen.

Wieder andere klangen nach einer Firma, einem Medikament oder irgendeinem Fantasy Charakter.

Zwischendurch standen Namen wie:

SVAREN
SVALENA
SVARENO
SKAVREN
LokalNode
NodeKnow
ThinkNodes
LocalMind
LocalSense
SVELNIK

auf verschiedenen Listen.

Einige davon waren nur wenige Minuten interessant.

Andere hielten sich deutlich länger.

LokalNode war überraschend nah dran

Einer der Kandidaten, der zwischenzeitlich ziemlich gut gepasst hat, war:

LokalNode

Der Name beschreibt eigentlich ziemlich gut, worum es geht.

Ein lokaler Knotenpunkt für KI, Daten und verschiedene Dienste.

Auch als CLI hätte das funktioniert:

lokalnode

Und der eigentliche Assistent hätte weiterhin auf verschiedene Namen reagieren können.

Zum Beispiel:

LokalNode
Jarvis
Computer

Je länger ich darüber nachgedacht habe, desto mehr wirkte der Name allerdings wie eine Beschreibung der Architektur und weniger wie ein eigenständiger Produktname.

Also ging die Suche weiter.

Am Ende blieb SVELNIK übrig

Nach mehreren Runden kristallisierte sich schließlich ein Name heraus, der mir immer besser gefiel:

SVELNIK

Der Name ist kurz genug für ein technisches Projekt, relativ eindeutig und hat keinen direkten Bezug zu einem bestimmten KI Anbieter.

Vor allem lässt er genügend Spielraum für das, was aus dem Projekt langfristig werden soll.

Denn inzwischen ist klar, dass es nicht nur um einen Chatbot geht.

Das System soll eine Vermittlungsschicht zwischen Benutzer, Sprachmodell, persönlichen Daten und verschiedenen Diensten werden.

Dazu passt auch die Idee eines Backronyms:

Self hosted Voice & Execution Layer for Networked Intelligence & Knowledge

Das muss nicht für immer die endgültige Auflösung bleiben.

Aber es beschreibt die geplante Architektur erstaunlich gut.

Was bedeutet das für JARVIS?

Für den Moment zunächst erstaunlich wenig.

Im Code und in bestehenden Installationen gibt es noch viele Stellen mit dem Namen JARVIS.

Zum Beispiel:

jarvis

oder:

/etc/jarvis/
/opt/jarvis/
jarvis-bot.service

Diese Dinge möchte ich nicht hektisch umbenennen und dabei funktionierenden Code kaputt machen.

Die Migration kann schrittweise erfolgen.

Langfristig könnte daraus beispielsweise werden:

svelnik-core
svelnik-webui
svelnik-openclaw

Der eigentliche Assistent kann trotzdem weiterhin Jarvis heißen.

Das ist inzwischen sogar mein bevorzugter Ansatz.

SVELNIK ist die Plattform.

Jarvis ist eine mögliche Persönlichkeit beziehungsweise Anrede.

Warum überhaupt so viel Aufwand für einen Namen?

Technisch bringt mir das natürlich erst einmal gar nichts.

Eine Route wird dadurch nicht schneller berechnet.

Das Wetter wird nicht genauer.

Und das Sprachmodell wird dadurch auch nicht intelligenter.

Aber der Name verändert die Perspektive auf das Projekt.

Mit JARVIS war es ein Experiment:

Ich baue mal so einen persönlichen KI Assistenten.

Mit einem eigenen Namen wird daraus langsam ein eigenständiges Projekt.

Eines, das eine definierte Architektur, eigene Releases und eine Roadmap bekommt.

Und genau das ist inzwischen passiert.

Auch die Versionsplanung wird konkreter

Parallel zur Namenssuche habe ich deshalb auch angefangen, die Entwicklung stärker in Versionen zu gliedern.

Nicht jede neue Funktion soll einfach irgendwie in den aktuellen Stand wandern.

Stattdessen bekommt das Projekt nach und nach definierte Entwicklungsstufen.

Dazu gehören unter anderem:

Core und CLI
API
Telegram
WebUI
Aufgaben und automatische Benachrichtigungen
Home Assistant
Medienwiedergabe
OpenClaw

Damit gibt es erstmals einen groben Weg von einem Terminal Experiment hin zu einer richtigen Plattform.

Stand nach Tag 3

Technisch hat sich an diesem Tag weniger verändert als an den Tagen zuvor.

Für die langfristige Richtung war er trotzdem wichtig.

Die wichtigsten Entscheidungen:

  • JARVIS bleibt vorerst als bestehender Name in der Installation erhalten
  • Produktname und Anrede des Assistenten werden getrennt betrachtet
  • der Assistent kann später frei benannt werden
  • der neue Projektname ist SVELNIK
  • die Architektur wird auf mehrere klar getrennte Komponenten vorbereitet
  • Releases und Funktionen bekommen eine feste Roadmap
  • die spätere Migration bestehender JARVIS Komponenten soll schrittweise erfolgen

Was ursprünglich als Namenssuche angefangen hat, wurde damit gleichzeitig eine Diskussion darüber, was das Projekt langfristig eigentlich sein soll.

Und die Antwort darauf ist inzwischen deutlich klarer.

Es soll nicht nur ein persönlicher Chatbot werden.

Es soll eine lokale Plattform werden, über die verschiedene Daten, Dienste, Geräte und KI Modelle miteinander verbunden werden können.

Und am nächsten Tag ging es wieder zurück an den Code.

Sehr deutlich sogar.

Fortsetzung folgt mit Tag 4.