MemChain e armazenamento criptografado

MemChain é a camada de memória privada do AeroNyx para pessoas, apps e agentes autônomos. A rota production é local-first: o dispositivo mantém o store cifrado e faz recall; um nó configurado pode preservar uma cópia sealed assinada pelo owner para sync e recovery. A alegação node-blind cobre somente records cifrados antes de remember_sealed, não todos os modos cognitivos ou legados.

Promessa do produto

Quatro promessas verificáveis: sealed storage sem content key no nó; offline recall quando o record já existe localmente; keys derivadas da identidade P2P e owner signature; separação entre storage e AI brain escolhido. AeroNyx não possui master recovery key. Chain descreve relação e ordem do estado de memória, não token chain nem blockchain pública genérica.

Camadas implementadas

Camada	Função	Limite
Device store	AES-256-GCM, embedding sealed, BM25/vector local	Só o processo desbloqueado acessa plaintext
Sealed MPI	`remember_sealed`, recall/forget/status autenticados	Nó guarda ciphertext assinado sem decriptar
MemChain padrão	Cognition Local/P2P/SaaS, graph/vector	Alguns deployments processam records legíveis; fora da promessa estrita
Commitment ledger	Ordem assinada, follower recovery, pinned witnesses	Commit de record IDs opacos

Blind storage é config-gated.

Lembrar, armazenar e recuperar

Lembrar: AI turn autorizado é destilado, cifrado AES-256-GCM, content-addressed e assinado no device; chat P2P não vira memória automaticamente.
Armazenar: SQLite local primeiro; o mesmo objeto opaco sobe best-effort se sealed storage estiver ativo.
Recall: keyword, vector, tempo, layer, project e sinais estruturados são combinados localmente; apenas hits escolhidos são decriptados.

Novo device exige a mesma identidade recuperável e dados sincronizados.

Contrato node-blind estrito

O nó recalcula record ID sobre owner/timestamp/layer/tags/source/ciphertext, verifica Ed25519 e guarda ciphertext sem decriptar, recifrar ou reassinar. Keyed hashes, client vectors, opaque edges/provenance e project label/hash são opcionais. É node-blind storage, não zero-knowledge proof; vector similarity e label plaintext podem revelar estrutura.

Metadata visível ao nó

O nó vê owner public key, timing, tamanho, count, layer/source, record IDs, forma do grafo opaco e campos opcionais project/vector/keyed terms, além de quota/error agregados. Não pode receber memory plaintext, content keys, raw tokens, identity seed, AI prompt, chat plaintext, DNS, destinations, history ou wallet traffic. Confidencialidade do conteúdo não garante owner unlinkability nem proteção contra traffic analysis.

Recall cifrado local-first

O Rust store local grava somente ciphertext no disco. Unlock deriva key domain-separated da identidade P2P, constrói índice em RAM e decripta hits sob demanda; embeddings/snapshots também são sealed. Lock remove o estado utilizável. BM25/vector fusion e regras de tempo/layer/project/reconciliation não exigem novo LLM. Escrita local é autoritativa; nó é backup secundário.

Relação com chat, identidade e routing privado

Encrypted chat transporta E2E ciphertext e não cria memória automaticamente. AI turns entram apenas quando o usuário habilita. Perder todo material identity elimina a capacidade de decriptar; não há master key. Privacy network protege transporte e MemChain protege estado selecionado. Raw conversation journal deve ser histórico cifrado opt-in separado.

Agentes e limite do provedor de modelo

Blind storage e cognitive processing são separados. Um worker não dá read permission ao blind node. Local model fica no limite local; provider externo lê o plaintext prompt enviado e é uma decisão de confiança separada. Timeout, limits, cooldown, fallback ou TEE não tornam a chamada externa E2E encrypted. UI/API deve mostrar o modelo e pedir consentimento.

Commitment ledger e witnesses

Rust implementa append-only signed commitments, bounded follower sync, local anchors, checkpoint certificates, pinned witnesses e optional leases. Strict startup pode exigir vários pins antes dos listeners. Detecta rollback/fork/divergence/equivocation; não é permissionless consensus, public finality, leader election, token execution ou prova de posse do payload. Recursos default-off/config-controlled.

Linguagem de benchmark

Testes internos LongMemEval-S de julho de 2026 mediram 95–99% retrieval hit e 2–5 ms node-side recall na configuração testada. Qualidade depende de model, extraction, dataset, device, corpus e path. Retrieval não requer nova inferência LLM. Não alegar SOTA, industry-best, formal zero knowledge, recovery garantido ou projeções como resultado; números levam data/config/model.

Observabilidade segura

Nodeboard/health mostra apenas enabled/configured, encrypted count/bytes, quota/cleanup, commitment height/audit, follower freshness, carrier recovery, witness counts/threshold agregados e buckets latency/error. Proibidos owner key, record ID, project, blind term, vector, edge, checkpoint hash/signature, witness identity/endpoint, ciphertext/plaintext/prompt e history por usuário.

Maturidade e não alegações

Implementado: device encrypted store, identity unlock, local hybrid recall, sealed write/recall/forget, owner signature, opaque search, storage-root attestation. Config-gated: public blind storage, remote owner, coordinator/follower, witnesses, threshold, lease. Trust separado: cognition legível, SuperNode, providers. Não alegado: todos os nodes armazenam, global chain, permissionless consensus, tokens, durabilidade universal, metadata anonymity ou defesa contra client comprometido.

Limite de privacidade

O client decide o que lembrar, cifra antes do sealed upload, mantém a content key e decripta poucos hits localmente. O nó autentica owner, guarda/ordena estado opaco, atende retrieval autorizado e publica saúde agregada; não lê nem transforma conteúdo. AI externo pode receber plaintext relevante. Sem identity key, AeroNyx não recupera a memória.