Guia do console de operadores AeroNyx Nodeboard

Nodeboard é o console operacional dos nós de privacidade descentralizados AeroNyx. Ele transforma registro, saúde agregada, capacidade, evidência do protocolo, manutenção e fechamento de incidentes em workflows repetíveis sem expor tráfego do usuário nem conteúdo cifrado. Abra app.aeronyx.network. Um painel prova apenas o que sua fonte atual reporta; configuração, runtime readiness e evidência observada são estados separados.

Escopo e modelo operacional

Use três níveis. Dashboard responde se a frota precisa de ação. Services compara um domínio de serviço ou capacidade entre seus nós. Node detail explica um nó e contém evidências, controles e histórico de auditoria. Nós saudáveis ficam silenciosos; raw proof history e command timeline ficam no detalhe. Nodeboard administra nós ligados ao operador autenticado, não é um explorador público de tráfego.

Registrar um nó

Crie um código curto em Registration Codes e use o comando gerado ou o instalador oficial. Acompanhe separadamente planning, instalação, registration, início do serviço, heartbeat e admission. Quando o nó aparecer, confirme região, visibilidade pública, versão runtime, source commit, capacidade e saúde. O código vincula um onboarding; não é API key reutilizável e o segredo consumido não deve reaparecer.

Começar pela atenção da frota

Priorize heartbeat offline/stale; comando failed/timeout/stale; maintenance com active sessions; packet drops ou pressão de IP pool, conntrack, file descriptors e disco; policy drift; inconsistência discovery/relay; depois evidência recovery/proof antiga. Stale, not reported e disabled não significam zero nem saudável. Abra o item de maior impacto e defina impacto do usuário e condição verificável de fechamento.

Usar Services e detalhes do nó

Services agrupa Privacy Network, Discovery & Relay, MemChain & Storage e Runtime. Compare e abra o detalhe para timestamp da fonte, policy sync, riscos, estado do comando e recovery evidence. Todo incidente precisa de sinal, impacto, ação e fechamento. Exit code zero não basta: heartbeat recente, saúde do serviço, endpoint do protocolo e capacidade afetada devem voltar.

Decidir capacidade e placement

Capacidade orienta admission, não é score decorativo. Revise IP pool usado/livre, max_connections, policy max_sessions, active sessions, conntrack, fd, packet drops, pps/bps, política de banda, disco, memória e CPU. Separe hard runtime limits de política comercial; zero pode ser unlimited segundo o backend. Mostre Accepting, Limited, Drain ou Maintenance com motivo e não deduza atividade individual de taxas agregadas.

Ler discovery e evidência de relay cifrado

Separe configured capability, signed advertisement, endpoint reachability, estabilidade de probes, observação de relay cifrado real, terminal client receipt e continuidade após restart. Synthetic probe prova rota de teste, não tráfego de usuário. OnionMiddle é relay cifrado sem saída; requer peer API acessível, ChatRelay pronto, descriptor assinado, peers routeable e evidência fresca. Não exponha hops, social graph, payload ou identidade do client.

Ler MemChain e evidência de commitment

MemChain pode informar se sealed storage, commitment follower, witnesses, quota, cleanup e recovery estão configurados e frescos. São recursos config-gated: empty/disabled não prova falha. Contadores witness/checkpoint são evidência de rollback/fork, não consenso de cadeia pública nem prova de posse do payload. Mostre apenas agregado, nunca owner key, record ID, project, vector, edge, checkpoint material ou ciphertext.

Manter, reiniciar e atualizar com segurança

O restart_service remoto é comando privilegiado com gate do backend. Exija permissão, aviso de sessões, orientação maintenance/drain, confirmação explícita, audit imutável e ciclo pending -> sent -> executing -> completed | failed | timeout; cancele só quando permitido. Depois valide runtime, heartbeat, healthcheck, policy sync e evidência afetada antes de encerrar maintenance. Upgrade mostra version drift, staged state, blockers e cutover safety, mas não implica upgrade remoto universal de um clique. Use workflow aprovado e rollback.

Separar credenciais de acesso

Um registration code inclui o nó; um private access code admite clients aprovados em nó restrito; um anonymous voucher comprova elegibilidade sem virar credencial do operador. Não são intercambiáveis. Aplique menor privilégio, expiração curta, exibição única, revogação e auditoria. Nunca coloque secrets, private keys, raw bearer ou recovery material em eventos, URLs, capturas ou tickets.

Usar eventos, freshness e auditoria

Cada painel identifica provenance e freshness: signed Rust heartbeat, health endpoint local, discovery status, systemd/upgrade report, backend policy ou command audit. Eventos respondem quando, qual nó/serviço, qual ator permitido iniciou e se chegou evidência de fechamento. Guarde timestamps e reason codes amplos; exclua payloads, destinos, message IDs, atividade de IP do client, conteúdo de memória e social graph.

Permissões e limite de privacidade

Proteja registro, policy, maintenance, comandos, códigos e audit por função. Nodeboard pode mostrar sessions, bytes, packets, pressão de capacidade, routeability, proof outcomes, recovery e ciclo de comando agregados. Não mostra DNS, destinos, histórico, plaintext de pacote/mensagem/MemChain, atividade de IP público do client, tráfego wallet, private keys ou voucher secrets. O operador deve manter infraestrutura sem conhecer o comportamento do usuário.

Rotina do operador e referências

Diário: Attention, offline/stale, placement, drops, recursos, freshness discovery e SLA dos comandos. Antes: sessions, drain/maintenance, versão/commit alvo e rollback. Depois: serviço active/enabled, heartbeat fresco, healthcheck, policy sync e admission discovery/relay configurada; então feche.