O que saber ao sair do GitHub para o Buzz e Nostr
TuBrief 편집팀
2026년 8월 24일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Chega um momento em que o modelo de enviar códigos para um repositório centralizado começa a parecer incômodo. As políticas mudam com frequência e você não sabe onde seu código está sendo usado. Para freelancers individuais ou equipes pequenas, a soberania de dados é uma questão de sobrevivência. O Buzz e o protocolo Nostr NIP-34 são alternativas viáveis que não dependem de uma única empresa. No entanto, quando você decide migrar, pode parecer assustador. É preciso resolver procedimentos, custos e problemas de segurança por conta própria.
Simplesmente executar git push --mirror fará com que o servidor recuse a operação. Isso acontece devido às referências internas do GitHub, como refs/pull/*. O servidor de destino não aceita referências ocultas. Para mover o código sem conflitos, você deve remover as referências desnecessárias e fazer o push explicitamente.
Você precisa criar um repositório bare em um diretório temporário, apagar as referências exclusivas do GitHub e enviá-lo para o endpoint do Buzz. Se houver arquivos grandes, os objetos LFS também devem ser tratados separadamente.
`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)"
`
Ao executar este script, o histórico de commits é preservado em 100%. O hash do commit inicial se torna o identificador exclusivo do projeto.
| Item de Comparação | GitHub | Buzz / Nostr NIP-34 |
|---|---|---|
| Identificação do Repositório | Registro de banco de dados do servidor central (org/repo) |
ID do commit inicial e ID do evento Nostr |
| Método de Autenticação | OAuth, PAT, SSH Key | Assinatura assimétrica de curva elíptica secp256k1 |
| Troca de Patches | API exclusiva do GitHub | Evento de patch NIP-34 (kind: 1617) |
No ecossistema Nostr, humanos e agentes de IA são entidades criptográficas idênticas. Eles autenticam uns aos outros usando chaves públicas de 32 bytes e assinaturas Schnorr. Deixar chaves privadas embutidas no código leva a incidentes de segurança. Elas devem ser mantidas apenas na memória por meio de variáveis de ambiente ou utilizando um assinante remoto.
Para verificar se um patch enviado por um agente não foi adulterado no meio do caminho, você deve validar o hash de serialização do 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"]
`
Quando precisar trocar códigos de forma sigilosa, utilize a especificação NIP-44 v2 para criptografia com ChaCha20.
Se você delegar a codificação a agentes, eles cairão em um loop de auto-correção que consome tokens rapidamente. Conforme registros de falhas se acumulam, o contexto é contaminado e os custos disparam. Para evitar isso, você deve impor limites no nível de proxy.
Coloque o proxy LiteLLM na frente e defina limites diários de orçamento e velocidade por chave 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"]
}'
`
Se o orçamento diário ultrapassar 5 dólares, um erro é retornado imediatamente e a execução para. O orçamento de toda a equipe também pode ser restringido por meio de um arquivo de configuração.
`yaml
model_list:
litellm_settings:
max_budget: 100.0
budget_duration: "30d"
default_team_settings:
`
Você também deve parar de incluir o código inteiro no contexto. O desperdício de tokens é reduzido ao utilizar o Tree-Sitter para recortar apenas as assinaturas de funções necessárias e as áreas ao redor das alterações (hunks). O uso dessa abordagem reduz as chamadas de ferramentas desnecessárias em mais da metade.