Was Sie wissen müssen, wenn Sie GitHub verlassen und zu Buzz und Nostr wechseln
TuBrief 편집팀
2026년 8월 24일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Es kommt der Punkt, an dem sich das Hochladen von Code in ein zentralisiertes Repository unangenehm anfühlt. Die Richtlinien ändern sich ständig und man weiß nicht genau, wofür der eigene Code verwendet wird. Für Solo-Freelancer oder kleine Teams ist die Datenhoheit eine Frage des Überlebens. Buzz und das Nostr NIP-34-Protokoll sind realistische Alternativen, die nicht von einem einzigen Unternehmen abhängen. Doch wenn man tatsächlich migrieren möchte, steht man vor Hürden. Verfahren, Kosten und Sicherheitsprobleme müssen eigenständig gelöst werden.
Ein einfacher Aufruf von git push --mirror wird vom Server abgelehnt. Der Grund dafür sind GitHub-interne Referenzen wie refs/pull/*. Der Zielserver akzeptiert keine versteckten Referenzen. Um Code ohne Konflikte zu übertragen, müssen unnötige Referenzen entfernt und der Push explizit durchgeführt werden.
Erstellen Sie dazu ein Bare-Repository in einem temporären Verzeichnis, löschen Sie die GitHub-spezifischen Referenzen und pushen Sie es an den Buzz-Endpunkt. Falls große Dateien vorhanden sind, müssen auch die LFS-Objekte separat berücksichtigt werden.
`bash
#!/usr/bin/env bash
set -euo pipefail
GITHUB_REPO_URL="2"
TEMP_DIR=$(mktemp -d -t buzz-migration-XXXXXX)
trap 'rm -rf "$TEMP_DIR"' EXIT
git clone --mirror "TEMP_DIR/bare_repo.git"
cd "$TEMP_DIR/bare_repo.git"
git for-each-ref --format='%(refname)' refs/pull/ | while read -r ref; do
git update-ref -d "$ref"
done
git remote add buzz "$BUZZ_REMOTE_URL"
git push --force --prune buzz "+refs/heads/:refs/heads/" "+refs/tags/:refs/tags/"
ROOT_COMMIT=ROOT_COMMIT)"
`
Wenn Sie dieses Skript ausführen, bleibt die Commit-Historie zu 100% erhalten. Der ursprüngliche Commit-Hash wird zum eindeutigen Identifikator des Projekts.
| Vergleichspunkt | GitHub | Buzz / Nostr NIP-34 |
|---|---|---|
| Repository-Identifikation | Zentraler Server-DB-Datensatz (org/repo) |
Ursprüngliche Commit-ID und Nostr-Eheignis-ID |
| Authentifizierungsmethode | OAuth, PAT, SSH-Key | secp256k1 elliptische Kurven-Asymmetrische Signatur |
| Patch-Austausch | GitHub-spezifische API | NIP-34 Patch-Ereignis (kind: 1617) |
Im Nostr-Ökosystem sind Menschen und KI-Agenten gleichermaßen kryptografische Entitäten. Sie authentifizieren sich gegenseitig über 32-Byte-Public-Keys und Schnorr-Signaturen. Sobald ein Private-Key im Code hinterlegt wird, führt dies zu einem Sicherheitsvorfall. Er sollte ausschließlich über Umgebungsvariablen im Arbeitsspeicher gehalten oder ein Remote-Signer verwendet werden.
Um zu überprüfen, ob ein von einem Agenten gesendeter Patch unterwegs manipuliert wurde, muss der NIP-01 Serialisierungs-Hash validiert werden.
`python
import json
import hashlib
from coincurve import PrivateKey
def create_signed_agent_event(secret_key_hex: str, kind: int, content: str, tags: list) -> dict:
sk = PrivateKey.from_hex(secret_key_hex)
pubkey_hex = sk.public_key.format(compressed=True)[1:].hex()
created_at = 1710000000
serialized_data = json.dumps(
[0, pubkey_hex, created_at, kind, tags, content],
separators=(',', ':'),
ensure_ascii=False
)
event_id = hashlib.sha256(serialized_data.encode('utf-8')).hexdigest()
sig_hex = sk.schnorr_sign(bytes.fromhex(event_id), None, raw=True).hex()
return {
"id": event_id,
"pubkey": pubkey_hex,
"created_at": created_at,
"kind": kind,
"tags": tags,
"content": content,
"sig": sig_hex
}
def verify_agent_event(event: dict) -> bool:
preimage = [0, event["pubkey"], event["created_at"], event["kind"], event["tags"], event["content"]]
serialized = json.dumps(preimage, separators=(',', ':'), ensure_ascii=False)
computed_id = hashlib.sha256(serialized.encode('utf-8')).hexdigest()
return computed_id == event["id"]
`
Wenn Code vertraulich ausgetauscht werden muss, wird die NIP-44 v2-Spezifikation zur Verschlüsselung mit ChaCha20 verwendet.
Wenn man Agenten mit dem Codieren betraut, geraten sie schnell in autonome Korrekturschleifen und verbrauchen Tokens in rasantem Tempo. Je mehr fehlgeschlagene Versuche sich ansammeln, desto stärker wird der Kontext kontaminiert und desto höher schnellen die Kosten. Um dem entgegenzuwirken, müssen Limits auf Proxy-Ebene gesetzt werden.
Platzieren Sie einen LiteLLM-Proxy davor und beschränken Sie das tägliche Budget sowie die Geschwindigkeit pro virtuellem Schlüssel.
`bash
curl -X POST 'http://localhost:4000/key/generate'
-H 'Authorization: Bearer sk-master-key-1234'
-H 'Content-Type: application/json'
-d '{
"key_alias": "auto-coder-agent-01",
"max_budget": 5.0,
"budget_duration": "1d",
"tpm_limit": 50000,
"rpm_limit": 30,
"models": ["agent-code-model"]
}'
`
Sobald das Tagesbudget von 5 US-Dollar überschritten wird, wird sofort ein Fehler ausgegeben und der Prozess gestoppt. Das Budget für das gesamte Team kann ebenfalls über eine Konfigurationsdatei reguliert werden.
`yaml
model_list:
litellm_settings:
max_budget: 100.0
budget_duration: "30d"
default_team_settings:
`
Man sollte auch davon absehen, den gesamten Code in den Kontext zu geben. Durch die Verwendung von Tree-Sitter sollten nur die benötigten Funktionssignaturen und die Bereiche um die geänderten Hunks herum zugeschnitten und übergeben werden, um Token-Verschwendung zu reduzieren. Durch diesen Ansatz werden unnötige Tool-Aufrufe um mehr als die Hälfte reduziert.