Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Le moment vient où pousser son code vers un dépôt centralisé devient inconfortable. Les politiques changent fréquemment et on ne sait pas où notre code est utilisé. Pour un freelance ou une petite équipe, la souveraineté des données est une question de survie. Buzz et le protocole Nostr NIP-34 sont des alternatives réalistes qui ne dépendent pas d'une seule entreprise. Cependant, migrer peut s'avérer intimidant au premier abord. Il faut gérer soi-même les procédures, les coûts et les problèmes de sécurité.
Tapez simplement git push --mirror et le serveur rejettera la commande. La cause en est les références internes de GitHub telles que refs/pull/*. Le serveur cible n'accepte pas les références cachées. Pour transférer du code sans conflit, vous devez éliminer les références inutiles et pousser explicitement.
Vous devez créer un dépôt bare dans un répertoire temporaire, supprimer les références spécifiques à GitHub, puis pousser vers l'endpoint Buzz. S'il y a des fichiers volumineux, les objets LFS doivent également être pris en compte.
`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)"
`
L'exécution de ce script préserve l'historique des commits à 100 %. Le premier hachage de commit devient l'identifiant unique du projet.
| Éléments de comparaison | GitHub | Buzz / Nostr NIP-34 |
|---|---|---|
| Identification du dépôt | Enregistrement BDD du serveur central (org/repo) |
ID du premier commit et ID d'événement Nostr |
| Mode d'authentification | OAuth, PAT, clé SSH | Signature asymétrique sur courbe elliptique secp256k1 |
| Échange de patchs | API dédiée de GitHub | Événement de patch NIP-34 (kind: 1617) |
Dans l'écosystème Nostr, qu'il s'agisse d'un humain ou d'un agent IA, il s'agit de la même entité cryptographique. L'authentification mutuelle repose sur une clé publique de 32 octets et des signatures Schnorr. Laisser une clé privée dans le code entraîne immédiatement un incident de sécurité. Elle doit être conservée uniquement en mémoire via des variables d'environnement ou en utilisant un signeur distant.
Pour vérifier si un patch envoyé par un agent a été modifié en cours de route, il faut valider le hachage de sérialisation NIP-01.
`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"]
`
Lorsque vous devez échanger du code en secret, utilisez la spécification NIP-44 v2 pour le chiffrer avec ChaCha20.
Si vous confiez le codage à des agents, ils s'enferment dans des boucles de correction autonomes et consument les jetons à une vitesse fulgurante. Plus les enregistrements d'échecs s'accumulent, plus le contexte est pollué et plus les coûts s'envolent. Pour éviter cela, des limites doivent être imposées au niveau du proxy.
Placez un proxy LiteLLM en amont pour restreindre le budget journalier et la vitesse par clé virtuelle.
`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"]
}'
`
Si le budget journalier dépasse 5 dollars, une erreur est immédiatement renvoyée et le processus s'arrête. Le budget de toute l'équipe peut également être contrôlé via un fichier de configuration.
`yaml
model_list:
litellm_settings:
max_budget: 100.0
budget_duration: "30d"
default_team_settings:
`
Il faut également cesser d'inclure le code entier dans le contexte. Utilisez Tree-Sitter pour extraire uniquement les signatures de fonctions nécessaires et les zones proches des modifications afin de réduire le gaspillage de jetons. Cette approche permet de réduire de plus de moitié les appels d'outils inutiles.