PocketContext für dich installieren

Diese Anleitung ist für eine Person, die eine Anwendung nutzt. Den Server betreibt meist jemand anders. Du meldest dich an und installierst optional einen kleinen Skill, damit ein KI-Assistent Datensätze gemeinsam mit dir lesen und aktualisieren kann.

Wenn du die Person bist, die den Server installiert, ihn baut oder den Cloud-Rechner anlegt, nutze zuerst die Server-Anleitung.

Was du auswählst

flowchart TB
  you[Du]
  you --> browser[Nur die Website nutzen]
  you --> laptop[Einen Skill auf diesem Rechner installieren]
  you --> vps[Einen Skill auf einem VPS installieren, den du per SSH erreichst]
  you --> localapp[Eine lokale Anwendung auf diesem Rechner betreiben]

  browser --> read[Lesen, und in NotifyContext auch schreiben]
  laptop --> agent[KI-Assistent auf diesem Rechner]
  vps --> agentcloud[KI-Assistent auf dem VPS]
  localapp --> linkedin[LinkContext oder NetworkContext]

Weg	Was du installierst	Wo die Datenbank liegt
Browser	Nichts	Auf dem Server, den dein Admin betreibt
Skill auf diesem Rechner	Einen Skill, uv und eine Anmeldung	Weiterhin auf diesem Server
Skill auf einem VPS	Denselben Skill, auf dem VPS	Weiterhin auf diesem Server, der ein anderer Rechner als der VPS sein kann
Lokale LinkedIn-Anwendungen	Die Anwendung und einen lokalen Server	Auf diesem Rechner

Ein Skill ist ein Ordner mit Anweisungen plus einem Befehl, zum Beispiel wikicontext oder dealcontext. Der Befehl spricht mit dem Server. Die Daten des Unternehmens enthält er nicht.

Umgebungsvariablen

Jeder Skill braucht zwei Angaben in der Umgebung, die den KI-Assistenten startet: wo der Server ist und welche E-Mail-Adresse zu dir gehört. Eine Passwort-Variable gibt es nur für ein Konto, das dein Admin mit einem Passwort angelegt hat. Die Google-Anmeldung nutzt sie nicht. Setze die Variablen in dieser Umgebung. Füge sie nicht in den Befehl ein, und nutze nicht das Passwort des Betreibers. Dieses Konto ist für die Admin-Oberfläche.

export <APP>_URL=https://<app>.example.com
export <APP>[email protected]

Der Befehlsname ist der Anwendungsname in Kleinbuchstaben, zum Beispiel wikicontext oder dealcontext. Nutze https://, außer der Server liegt auf diesem Rechner. Ein lokaler Server ist http://127.0.0.1: plus den Port, den dein Admin gewählt hat. Frag deinen Admin nach der Origin. Jede Anwendung hat ihre eigene Anmeldung, deshalb öffnet eine Wiki-Sitzung nicht das CRM.

1. Nur der Browser

Öffne die Origin, die dein Admin dir gegeben hat, und melde dich mit dem Google-Konto an, das er erwartet. Wenn die Anmeldung beim ersten Zugriff für deine Workspace-Domain eingeschaltet ist, kann die erste erfolgreiche Anmeldung dein Anwendungskonto anlegen. Sie macht dich nicht zum Betreiber.

Wofür der Browser da ist, hängt von der Anwendung ab:

Was du öffnest	Was du dort tun kannst
DealContext, TaskContext, RaiseContext, PeopleContext, AccountContext, WikiContext, ChatContext, LinkContext, NetworkContext	Lesen. Die Aktualisierungen macht der KI-Assistent.
NotifyContext	Lesen, eine Notiz schreiben und markieren, dass du eine gesehen hast. Eine Notiz zu öffnen markiert sie nicht von selbst als gelesen.
VaultContext	Die Einrichtungsanleitung lesen. Die Seite entsperrt keine Dateien.

Besucher in ChatContext unterscheiden sich von Teammitgliedern. Ein Besucher weist eine E-Mail-Adresse mit einem Einmalcode nach und sieht danach nur sein eigenes Supportgespräch. Teammitglieder nutzen Google.

sequenceDiagram
  participant You
  participant Browser
  participant App as Der Anwendungsserver

  You->>Browser: die Origin öffnen
  Browser->>App: Google-Anmeldung
  App-->>Browser: deine Leseansicht

Hier kannst du aufhören, wenn du nur schauen wolltest.

2. Ein Skill auf diesem Rechner

Das ist der übliche Weg, einen KI-Assistenten in einer Anwendung arbeiten zu lassen. Der KI-Assistent und der Skill laufen auf demselben Rechner wie du. Die Daten der Anwendung bleiben auf dem Server.

Du brauchst:

uv, das das festgelegte Python-Paket des Skills beim ersten Einsatz herunterlädt.
Python 3.11 oder neuer, das uv bereitstellen kann.
Node.js, nur wenn du den Skill mit npx installierst. Ohne Node kopierst du den Skill-Ordner von Hand aus einem Klon des Anwendungs-Repositories in den Ordner, aus dem dein KI-Assistent Skills liest.

Der Befehl von VaultContext braucht außerdem Linux oder macOS, weil die entsperrte Sitzung einen Unix-Socket nutzt. Das veröffentlichte Server-Binary deckt Intel-Macs nicht ab, aber diese Grenze betrifft den Betrieb des Servers. Der Skill selbst ist ein Python-Befehl.

Den Skill installieren

Das DealContext-Beispiel für einen KI-Assistenten wie Claude Code, aus der README der Anwendung:

npx skills add pocketcontext/dealcontext --skill dealcontext --agent claude-code -g -y

--list zeigt die Skill-Namen in einem Repository, bevor du installierst. -g legt den Skill in deinen Benutzerordner. Ohne -g landet er im aktuellen Projekt. --agent nennt den KI-Assistenten. Wenn du --agent weglässt, fragt das Installationsprogramm.

Dieselbe Form funktioniert für die anderen Anwendungen. Ersetze das Repository und den Skill-Namen:

npx skills add pocketcontext/wikicontext --skill wikicontext --agent claude-code -g -y
npx skills add pocketcontext/notifycontext --skill notifycontext --agent claude-code -g -y
npx skills add pocketcontext/taskcontext --skill taskcontext --agent claude-code -g -y
npx skills add pocketcontext/vaultcontext --skill vaultcontext --agent claude-code -g -y

Nutze den Namen des KI-Assistenten, den dein Installationsprogramm erwartet. Codex, Claude Code und andere wählst du mit --agent. Ein kopierter Ordner ist genauso gültig. Der Befehl im Ordner ist das, worauf es ankommt.

Aktualisiere später mit npx skills update dealcontext -g oder indem du den Ordner erneut kopierst. Der Server ist die Instanz für die Daten. Wenn check sagt, dass das Schema abweicht, gilt der laufende Server, und ein neuerer Skill bringt die lokalen Notizen wieder in Einklang.

Auf den Server ausrichten

Lege die beiden Variablen in die Umgebung, die den KI-Assistenten startet. Für das Wiki sieht das so aus:

export WIKICONTEXT_URL=https://wiki.pocketcontext.com
export [email protected]

Nutze deine eigene E-Mail-Adresse und die Origin, die dein Admin dir gegeben hat. Lass die Passwort-Variable weg, wenn du Google nutzen wirst.

Mit Google anmelden

Führe im Skill-Verzeichnis den Anmeldebefehl aus. Nur eine Anwendung zur Zeit. Warte, bis er fertig ist, bevor du dich bei einer zweiten Anwendung anmeldest.

./wikicontext login --google

Der Befehl gibt eine Adresse aus. Öffne sie im Browser auf demselben Rechner. Google schickt den Browser zurück zu http://127.0.0.1:8765/callback. Der Skill lauscht dort ein paar Minuten. Das Token, das er speichert, ist das Anwendungstoken, nicht dein Google-Passwort. Es liegt in einem privaten Cache, üblicherweise unter ~/.cache/ oder $XDG_CACHE_HOME, in einem Ordner, der nach der Anwendung benannt ist.

sequenceDiagram
  participant You
  participant Skill as Skill auf diesem Rechner
  participant Browser
  participant Google
  participant App as Anwendungsserver

  You->>Skill: login --google
  Skill-->>You: eine private URL
  You->>Browser: diese URL öffnen
  Browser->>Google: anmelden
  Google->>Skill: Callback auf Port 8765
  Skill->>App: ein Anwendungstoken speichern
  You->>Skill: whoami
  Skill-->>You: dein Name, deine E-Mail-Adresse und der Server

Danach:

./wikicontext whoami
./wikicontext check

whoami gibt aus, für wen der Server dich hält. check vergleicht die Notizen des Skills mit den laufenden Tabellen. Der Exit-Code 0 bedeutet, dass sie übereinstimmen.

logout löscht das Token auf diesem Rechner. Dein Konto löscht es nicht. Sitzungen halten etwa sieben Tage und erneuern sich, solange du den Befehl weiter nutzt. Nach einer ruhigen Woche führst du login --google erneut aus.

Wenn dein Admin das Konto deaktiviert hat, schlägt die Anmeldung fehl, bis er es wieder aktiviert. Das Google-Konto in Workspace auszuschalten lässt ein schon ausgestelltes Anwendungstoken nicht von selbst ablaufen. Dieser Teil ist der Abmeldeschritt des Admins.

3. Ein Skill auf einem VPS

Nutze das, wenn der KI-Assistent auf einem Cloud-Rechner läuft und du diesen Rechner per SSH erreichst. Der Skill wird auf dem VPS installiert, mit denselben Schritten über npx oder durch Kopieren wie auf einem Laptop. Der Anwendungsserver kann ein ganz anderer Rechner sein. Die URL-Variable zeigt weiter auf die Anwendung, zum Beispiel https://wiki.pocketcontext.com, nicht auf den VPS.

Die Google-Anmeldung ist der Teil, der sich ändert. Der Skill lauscht auf Port 8765 auf dem VPS. Dein Browser ist auf deinem Laptop. Ein direktes 127.0.0.1:8765 auf dem Laptop ist der Laptop, nicht der VPS.

Leite diesen Port vom Laptop aus weiter und halte die SSH-Sitzung offen:

ssh -L 8765:127.0.0.1:8765 user@your-vps

Führe auf dem VPS in dieser Sitzung login --google aus. Öffne die ausgegebene URL im Browser auf dem Laptop. Port 8765 des Laptops ist zum VPS weitergeleitet, deshalb erreicht der Callback den Skill.

sequenceDiagram
  participant Laptop as Browser auf deinem Laptop
  participant VPS as Skill auf dem VPS
  participant App as Anwendungsserver

  Note over Laptop,VPS: ssh -L 8765 leitet den Callback an den VPS
  VPS->>Laptop: ausgegebene Anmelde-URL
  Laptop->>VPS: Google kehrt zu Port 8765 zurück
  VPS->>App: Anwendungstoken, auf dem VPS zwischengespeichert

Das Token bleibt auf dem VPS. Die Anmeldung auf deinem Laptop meldet den KI-Assistenten auf dem VPS nicht an. Wiederhole die Anmeldung auf jedem Rechner, auf dem ein Skill läuft.

Der VPS in diesem Abschnitt ist dein Arbeitsplatz in der Cloud. Er ist nicht der PocketContext-Server, außer dein Admin hat den Server auch dort abgelegt. Einen Skill zu installieren legt nie pb_data an.

Die Anmeldung mit Passwort überspringt den Browser. Wenn dein Admin dir ein Passwort gegeben hat, setze die Passwort-Variable für diese Anwendung und führe whoami aus. Bevorzuge Google, wenn der Server dafür eingerichtet ist. Schreibe das Passwort nicht in die Kommandozeile und nicht in einen Chat.

4. VaultContext, nach Google

Google weist deinen Namen nach. Eine Passphrase entsperrt die Dateien. Das sind zwei Schritte.

export VAULTCONTEXT_URL=https://vault.pocketcontext.com
export [email protected]
vaultcontext login --google
vaultcontext init
vaultcontext unlock

init läuft einmal, in einem Terminal, an dem du sitzt, und fragt nach der Passphrase. unlock fragt erneut, wenn du eine Sitzung willst. Die Sitzung lebt auf diesem Rechner, für denselben Betriebssystembenutzer, 15 Minuten lang, außer du übergibst ein längeres --timeout bis zu einer Stunde. lock beendet sie. Es gibt keinen Wiederherstellungsschlüssel. Verlierst du die Passphrase, ohne entsperrte Sitzung und ohne eingetragenen macOS-Keychain-Eintrag, bleiben die Dateien unlesbar.

Tippe die Passphrase selbst. Lege sie nicht in eine Umgebungsvariable, einen Chat oder ein Befehlsargument.

Auf einem Mac kannst du die Passphrase nach init in die Keychain eintragen. Dieser Eintrag gilt nur für macOS. Ein Linux-VPS bittet dich, die Passphrase zu tippen. Wenn der Skill auf dem VPS läuft, liegt die entsperrte Sitzung auf dem VPS, und der VPS ist für diese Sitzung mit den entsperrten Dateien betraut.

Die öffentliche Seite unter https://vault.pocketcontext.com ist die Einführungsanleitung. Sie entsperrt nichts.

flowchart LR
  google[Google-Anmeldung]
  phrase[Passphrase in deinem Terminal]
  session[Entsperrte Sitzung auf diesem Rechner]
  files[Verschlüsselte Dateien auf dem Server]
  google --> phrase --> session
  session --> files

5. Lokale Anwendungen auf diesem Rechner

LinkContext und NetworkContext können vollständig auf deinem Rechner laufen. Beide nutzen standardmäßig http://127.0.0.1:8095. Starte eine, oder wähle für die zweite einen anderen Port. Sie teilen sich keine Datenbank.

NetworkContext

Das ist das Archiv dessen, was ein LinkedIn-Konto sieht. Die erste Version hat keine Google-Anmeldung und keine gehostete Seite. Du brauchst einen Checkout von NetworkContext und ein pocketcontext-Binary, gebaut aus dem Commit in POCKETCONTEXT_VERSION dieser Anwendung. Dieses Binary zu bauen ist die Server-Anleitung.

Danach, aus den eigenen Anweisungen der Anwendung:

networkcontext local init --app-dir /path/to/networkcontext --binary /path/to/pocketcontext
networkcontext account add --url https://www.linkedin.com/in/you/ --name "Your Name"
networkcontext whoami
networkcontext check

local init startet den Server, legt ein Konto an und speichert ein zufälliges Passwort in ~/.config/networkcontext/local.json. Spätere Befehle finden diese Datei. Die Datenbank liegt unter ~/.local/share/networkcontext/. Der Leser liegt unter http://127.0.0.1:8095/.

Der Erfassungsschritt ist ein Browser-Agent, der LinkedIn-Seiten liest und eine Datei schreibt. networkcontext ingest speichert diese Datei. Die Anwendung postet nichts, vergibt kein Gefällt mir und sendet nichts.

LinkContext

Das ist der gemeinsame LinkedIn-Speicher des Teams. Lokal kann er einen Benutzer aus LINKCONTEXT_LOCAL_USER_EMAIL und LINKCONTEXT_LOCAL_USER_PASSWORD anlegen und dann auf Port 8095 ausliefern. Das festgelegte Server-Binary aus der Server-Anleitung brauchst du trotzdem. Die öffentliche Origin https://link.pocketcontext.com ist die, die die README nutzen will. Bis es sie gibt, ist der lokale Server der, den du hast.

Auf einem lokalen LinkContext ist die Anmeldung mit Passwort der normale Weg. login --google ist für einen Server, auf dem die Google-Anmeldung eingerichtet wurde.

Wenn etwas sich nicht anmeldet

Was du siehst	Was es meist bedeutet
Der Befehl nennt eine fehlende Variable und endet	Setze diese Variable in der Umgebung und versuche es erneut.
Der Browser erreicht Port 8765 nicht	Auf diesem Rechner sollte während der Anmeldung nichts anderes 8765 belegen. Auf einem VPS muss die SSH-Weiterleitung stehen, und du öffnest die URL auf dem Laptop.
`whoami` zeigt eine andere E-Mail-Adresse als du erwartet hast	Die Variablen und das zwischengespeicherte Token passen nicht zusammen. `logout`, korrigiere die E-Mail-Adresse und melde dich erneut an.
`check` meldet einen Unterschied	Das Schema des Servers und die Notizen des Skills weichen ab. Frag deinen Admin, bevor du die Notizen des Skills als neuer behandelst als den Server.
Die Google-Anmeldung funktioniert, aber die Anwendung verweigert den Zugriff	Die Workspace-Domain passt möglicherweise nicht, oder ein Admin hat das Konto deaktiviert. Eine neue Google-Nutzerin oder ein neuer Google-Nutzer ist kein Betreiber.
Die Vault-Anmeldung funktioniert, und die Dateien öffnen sich nicht	Google ist fertig, und `unlock` wurde in einem Terminal auf diesem Rechner noch nicht ausgeführt. Die Passphrase ist die, die du bei `init` gewählt hast. Dieselbe Passphrase funktioniert auf einem anderen Rechner für dasselbe Konto. Eine andere Passphrase nicht.

Melde dich bei einer Anwendung an, sieh zu, dass whoami gelingt, und geh dann zur nächsten Anwendung.