hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
knowledge-base/wiki/tools/cobot.md

5.9 KiB
Raw Blame History

created updated sources tags
2026-09-24 2026-09-24
other/2026-09-24_ultanio-cobot-self-sovereign-agent.md
tool
self-sovereign
ai-agent
nostr
lightning
local-llm
python
plugin-architecture
minimalism
referenz-baukasten

Cobot — minimaler selbst-souveräner Agent (Referenz-Baukasten)

Was es ist

Cobot (ultanio/cobot) ist ein bewusst winziger selbst gehosteter Agent: Python, MIT, Status Alpha, ~2K Zeilen, alles zusammen — Runtime, Identität, Geld, Inferenz — im Besitz des Betreibers. Selbstbeschreibung: „Your keys, your identity, your agent." Geteilt von k9ert in der OME-Gruppe (Topic 406, 2026-09-24).

Der Vergleich steht im eigenen README: ~2K Zeilen gegen 430K+ bei OpenClaw — ein bewusster Minimalismus-Gegenentwurf, kein Feature-Wettbewerb. Siehe ../tools/openclaw.md.

Architektur

Ebene Umsetzung
Runtime selbst gehostet, Python 3.11+, cobot run / --stdin
Identität Nostr npub/nsec — kryptografische ID, kein Plattform-Login
Geld Lightning-Wallet via npub.cash, Sats autonom senden/empfangen
Inferenz flexibel: lokal (Ollama) oder Cloud (PPQ, OpenRouter, …)
Kommunikation Nostr-DMs (NIP-04) und FileDrop (dateibasiert, Schnorr-signiert)
Erweiterung Plugin-Registry + Extension Points + Hook Chain + Hot Reload
Sicherheit Plugin security als Prompt-Injection-Schild; Tool-Ausführung über exec.enabled / exec.timeout

Die Trennung ist die eigentliche Aussage: Hardware, Identität und Zahlungsweg liegen in derselben Hand, die Modellwahl ist austauschbar. Das ist die operative Fassung von ../concepts/hardware/cloud-exit-and-local-superiority.md — dort geht es um Kosten und Hardware, hier um die Besitzfrage auf Agentenebene.

Das Plugin-Muster: Extension Points

Der eine architektonische Gedanke, der über „Plugins gibt es überall" hinausgeht: Ein Plugin definiert einen Hook, ein anderes implementiert ihn. Nicht jeder Anbieter erweitert die Core-App, sondern Plugins erweitern einander.

filedrop  ──definiert──►  Extension Point        ──implementiert──►  filedrop-nostr
                          filedrop.before_write                        sign_message
                          filedrop.after_read                          verify_message

Praktisch: Der Dateitransport filedrop muss nichts über Kryptografie wissen. Das filedrop-nostr-Plugin hängt sich an dessen Hook und signiert/verifiziert mit Schnorr-Signaturen. Dasselbe Muster trägt jede weitere Transport-, Signatur- oder Speicher-Variante, ohne den Core anzufassen — die Konfiguration entscheidet, welche Plugins sich paaren.

Einordnung: Das ist derselbe Gedanke, den ../concepts/agents/harness-loop-graph-engineering.md als Fähigkeiten-Deklaration beschreibt — die Capability einer Komponente (llm, communication, wallet) wird registriert, Abhängigkeiten werden aufgelöst. Cobot ist dafür ein sehr kleines, lesbares Exemplar.

Setup

git clone https://github.com/ultanio/cobot && cd cobot
python -m venv .venv && source .venv/bin/activate
pip install -e .
cobot wizard init        # Identity → Provider → Plugins, erzeugt cobot.yml
cobot run                # oder: cobot run --stdin (ohne Nostr)

Plugins liegen in /opt/cobot/plugins/ (System), ~/.cobot/plugins/ (User) oder ./plugins/ (Projekt); jedes braucht eine plugin.py mit create_plugin().

Roadmap (offen)

Container-Isolation für Tool-Ausführung · smartes LLM-Routing (Kostenoptimierung) · weitere Kanäle (Telegram, Discord) · Agent-zu-Agent-Protokoll · Nostr-Relay für Agent-Discovery.

Die Reihenfolge ist ehrlich: erst die Sandbox, dann mehr Reichweite. Solange Tool-Ausführung ungeisoliert läuft, ist jedes zusätzliche Interface ein zusätzlicher Angriffsweg — das ist der Punkt, an dem die Alpha-Grenze sitzt.

Einordnung: Referenz-Baukasten für lokale Souveränität

Der Wert liegt nicht in der Funktionsliste — dafür ist das Ding zu klein — sondern darin, dass es die Souveränitäts-Kette vollständig und lesbar verdrahtet: eigene Hardware → eigene kryptografische Identität → eigener Zahlungsweg → austauschbares Modell. Wer verstehen will, wie „lokale Souveränität" ohne Plattform-Zwischenhändler konkret aussieht, findet hier eine ~2K-Zeilen-Vorlage statt eines 430K-Zeilen-Systems.

Vergleichbare Wiki-Bestände:

Werkzeug Souveränitäts-Achse
Cobot Identität (Nostr) + Geld (Lightning) + Runtime, minimal
../tools/pocketpal-ai.md (PocketPal AI) Inferenz lokal auf dem Smartphone
../tools/perplexity-portable-computer.md (Perplexity Portable Computer) vollständiger Agent-Stack lokal, Cloud-Eskalation nur mit Freigabe
../concepts/agents/agent-payments-lightning.md (Agent-to-Agent Payments) warum Lightning die Zahlungsschicht für Agenten ist
../tools/blink-wallet-skill.md (Blink Wallet Skill) L402/Lightning-Praxis — mit Telefonnummer-Red-Flag

Ehrliche Einschränkung: Alpha, 2 Stars, 2–3 Mitwirkende, letzte Repo-Aktivität 2026-03-08 (GitHub-API). Dass „beteiligte Agent-Kollaborateure" (Doxios, Zeus, bmad, k9ert) genannt werden, ist eine Aussage über den Entstehungsprozess, nicht über Reife. Als Lehrmuster trägt es trotzdem — die Plugin-Paarbildung ist ein elegantes Stück Architektur, das größere Systeme oft unschöner lösen.

Quellen