Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Llega un momento en que empujar código a un repositorio centralizado resulta incómodo. Las políticas cambian con frecuencia y es imposible saber exactamente dónde se utiliza tu código. Para los freelancers independientes o los equipos pequeños, la soberanía de los datos es un asunto de supervivencia. Buzz y el protocolo NIP-34 de Nostr son alternativas reales que no dependen de una sola empresa. Sin embargo, cuando finalmente decides migrar, puede parecer abrumador, ya que debes resolver los procedimientos, los costos y los problemas de seguridad por tu cuenta.
Si simplemente ejecutas git push --mirror, el servidor lo rechazará debido a las referencias internas de GitHub como refs/pull/*. El servidor de destino no acepta referencias ocultas. Para mover el código sin conflictos, debes eliminar las referencias innecesarias y hacer un push explícito.
Debes crear un repositorio bare en un directorio temporal, eliminar las referencias exclusivas de GitHub y enviarlo al endpoint de Buzz. Si tienes archivos grandes, también debes gestionar los objetos LFS por separado.
`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)"
`
Al ejecutar este script, el historial de commits se conserva al 100%. El hash del commit inicial se convierte en el identificador único del proyecto.
| Elemento de comparación | GitHub | Buzz / Nostr NIP-34 |
|---|---|---|
| Identificación del repositorio | Registro de BD del servidor central (org/repo) |
ID del commit inicial e ID de evento de Nostr |
| Método de autenticación | OAuth, PAT, SSH Key | Firma asimétrica de curva elíptica secp256k1 |
| Intercambio de parches | API exclusiva de GitHub | Evento de parche NIP-34 (kind: 1617) |
En el ecosistema de Nostr, tanto las personas como los agentes de IA son entidades criptográficas idénticas. Se autentican mutuamente mediante claves públicas de 32 bytes y firmas Schnorr. Dejar una clave secreta incrustada en el código conduce directamente a un incidente de seguridad. Debe mantenerse únicamente en la memoria mediante variables de entorno o utilizar un firmante remoto.
Para verificar que un parche enviado por un agente no haya sido alterado en el camino, es necesario validar el hash de serialización 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"]
`
Cuando necesites intercambiar código de forma confidencial, utiliza la especificación NIP-44 v2 para cifrarlo con ChaCha20.
Si le asignas la programación a un agente, este puede quedar atrapado en un bucle de autocorrección y consumir tokens rápidamente. Cuantos más registros de fallos se acumulen, más se contaminará el contexto y se dispararán los costos. Para evitarlo, debes establecer límites a nivel de proxy.
Coloca un proxy LiteLLM al frente y limita el presupuesto diario y la velocidad por clave virtual.
`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 el presupuesto diario supera los 5 dólares, arrojará un error de inmediato y se detendrá. También puedes ajustar el presupuesto general del equipo mediante un archivo de configuración.
`yaml
model_list:
litellm_settings:
max_budget: 100.0
budget_duration: "30d"
default_team_settings:
`
También debes dejar de incluir todo el código en el contexto. Utiliza Tree-Sitter para recortar y enviar únicamente las firmas de funciones necesarias y las zonas cercanas a los hunks modificados para reducir el desperdicio de tokens. Aplicar este enfoque reduce las llamadas de herramientas innecesarias a más de la mitad.