Ce qu'il faut savoir lors du départ de GitHub vers Buzz et Nostr
TuBrief 편집팀
2026년 8월 24일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
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.