GBR: ADR-0004 Recuperação Social e Abstração de Conta (Social Recovery)

• *Status:* Proposto -> (Aceito)
• *Data:* 2026-05-12

*Contexto:*

A perda do hardware que contém a Passkey resultaria na perda catastrófica de acesso à identidade e aos recursos delegados na rede.

A perda do dispositivo biométrico não pode significar a morte da conta (problema das carteiras de Bitcoin).

*Decisão:*

Implementar *Social Recovery (M-of-N)* inspirado em Vitalik Buterin. A identidade é um contrato lógico. A recuperação exige um quórum de assinaturas de "Guardiões" (outros dispositivos ou parceiros confiáveis).

1. *Abstração de Identidade:* A conta do usuário não é a sua chave, mas um contrato/registro distribuído.
2. *M-of-N Guardians:* Implementar o suporte a múltiplos "Guardiões" (outros dispositivos do usuário, Agentes Institucionais ou colegas confiáveis).
3. *Rotação de Chaves:* Se a Passkey principal for perdida, o usuário pode invocar a recuperação, exigindo assinaturas criptográficas de um quórum de guardiões predefinido para autorizar o registro de uma nova Passkey raiz.

*Consequências:*

• *Positivas:* Resolve o problema de "chaves perdidas" de forma descentralizada e escalável; melhora massivamente a experiência do usuário (UX).

• *Positivas:* Resiliência contra falhas de hardware humano. UX de recuperação familiar para o mercado B2B.

• Negativas: Requer infraestrutura complexa para monitorar e orquestrar as assinaturas dos guardiões durante o processo de recuperação. (WIP sendo mitigada)

Análise da negativa

A recuperação da autenticação/autorização precisa ser de forma *matemática e distribuída*. Vamos focar na complexidade da orquestração e desenhar a engenharia exata de como um dispositivo, um amigo ou um servidor LDAP podem atuar como "Guardiões" sem quebrar a pureza da rede P2P.

1. A Autópsia da Complexidade: Por que a Orquestração é Difícil?

No mundo Web2 (centralizado), a recuperação de senha é trivial: você clica em "Esqueci a senha", o servidor central altera a linha no banco de dados (UPDATE users SET password_hash = ...) e envia um e-mail.

No mundo P2P (Gleam-BR), *não existe banco de dados central para alterar*. Se você perdeu sua Passkey, a sua identidade raiz "morreu". Para ressuscitar, a rede precisa concordar em transferir a autoridade da Chave A (perdida) para a Chave B (nova).

A complexidade ("Negativa" do ADR) reside em três desafios físicos da rede:

1. *Assincronia:* Os seus guardiões (o celular da sua esposa, o laptop do seu sócio) podem não estar online ao mesmo tempo. Como acumular votos se não há um servidor central para guardá-los?
2. *Falsificação (Sybil Attack):* Como a rede sabe que o voto do guardião é real e não um atacante forjando pacotes?
3. *A Barreira do Legado:* Como um sistema dos anos 90 (LDAP/Active Directory), que não sabe o que é uma Curva Elíptica ou um Hash, emite um "voto criptográfico"?

2. Dissecando os Guardiões (A Tríade de Confiança)

Para orquestrar isso sem um servidor central, nós modelamos o processo de recuperação como um *Consenso de Limiar (M-of-N)*. Você precisa de, digamos, 3 de 5 votos. Quem são esses 5?

A) O Guardião de Silício (Seus próprios dispositivos)

• *O que é:* O seu iPad ou Desktop que já possui uma delegação ZCAP-LD válida sua.
• *Como vota:* Pura matemática. O seu novo dispositivo (com a nova Passkey) envia um desafio via P2P. O iPad, de forma silenciosa ou com um clique de confirmação seu, assina a aprovação com a chave Ed25519 local.

B) O Guardião Social (Humanos / Colegas)

• *O que é:* O did:key do seu CTO ou do seu Gerente.
• *Como vota:* Exige UX. No aplicativo deles exibe um alerta: "O Comandante Paulo iniciou uma recuperação de conta. Confirma que ele perdeu o dispositivo?". Eles tocam na biometria deles para assinar o voto a seu favor.

C) O Guardião Institucional (A Ponte LDAP/AD)

• *A Mágica:* O LDAP não assina criptografia. Quem assina é o *Nó Gleam-BR/Monitor v2.0 (Hotel)* que está instalado na infraestrutura do cliente.
• *Como vota:* O seu novo dispositivo conecta-se ao IP do Monitor corporativo. O Monitor apresenta uma tela de login clássica. Você digita seu usuário e senha do Active Directory. O Monitor vai até o AD, valida a senha e diz: "Ok, o AD confirmou que este é o Paulo". Em seguida, o **Nó Monitor pega a sua própria chave de máquina (did:key corporativo) e assina o seu voto de recuperação.**

*A Inovação:* Nós transformamos o LDAP de um "Deus Central" para apenas "Mais um Guardião com peso 1". A rede P2P continua matematicamente pura, pois quem atesta é o Nó Monitor v2.0, não o LDAP diretamente.

3. A Engenharia de Orquestração (Mitigando a Complexidade)

Como acumulamos esses votos em uma rede onde os nós entram e saem o tempo todo? Nós utilizamos o poder da *Erlang VM (BEAM)* misturado com *CRDTs (Conflict-free Replicated Data Types)*.

1. *A Gênese do Resgate:* Seu dispositivo novo gera uma nova Passkey e cria um pacote chamado RecoveryProposal. Ele grita na rede GossipSub: "Eu sou a nova chave do Paulo. Preciso de 3 votos".
2. *O Processo Fantasma (GenServer):* Na BEAM do seu novo dispositivo, um Ator OTP (recovery_coordinator) é iniciado. O trabalho dele é ficar vivo na memória, ouvindo a malha P2P e acumulando assinaturas.
3. *O Acúmulo Assíncrono:* - O Nó Monitor (LDAP) verifica sua senha e manda 1 voto. O Ator guarda: [1/3]. - Duas horas depois, seu CTO abre o app e assina. O Ator guarda: [2/3]. - No dia seguinte, você liga seu iPad antigo e aprova. O Ator guarda: [3/3].
4. *A Ressurreição (Cunhagem do Novo ZCAP-LD):* Quando o Ator OTP atinge 3 votos válidos, ele empacota as 3 assinaturas em um único super-documento (Proof of Recovery) e publica no GossipSub. A rede inteira valida a matemática, revoga a sua Passkey antiga no cache local e aceita a nova.

4. Veredito para o ADR

A complexidade é brutal para desenvolvedores Javascript/Python que dependem de bancos de dados estatais. Mas para a *Arquitetura de Atores (OTP)*, acumular estado assincronamente ao longo de dias é exatamente o que a Erlang faz melhor (é assim que ela mantém chamadas telefônicas vivas).

*Atualização do Status do Risco no ADR:*

• *Negativa Original:* "Requer infraestrutura complexa para monitorar e orquestrar assinaturas…"
• *Tratamento do Risco:* *MITIGADO (Risco Absorvido pela Arquitetura OTP).*
• *Medidas Incorporadas:* 1. Uso de Atores OTP dedicados (recovery_coordinator) na borda do usuário para acumular o estado dos votos localmente, eliminando a necessidade de um "banco de dados de recuperação" central. 2. Tradução de sistemas legados (LDAP/AD) através do "Guardião Institucional" (O Nó Monitor usa sua chave M2M para atestar o sucesso da validação legado corporativa). 3. Adoção de CRDTs transmitidos via GossipSub para garantir que a prova matemática da recuperação se propague universalmente, invalidando a chave antiga instantaneamente em toda a malha.

Conclusão

Neste ADR, nós não apenas resolvemos uma falha; *nós patenteamos (intelectualmente) o sistema de identidade definitivo.*

Um ecossistema que não pode ser derrubado (P2P), que não pode ser invadido por engenharia social remota (Passkeys de silício), e que se o usuário cometer um erro humano (perder o celular), o próprio ecossistema corporativo (LDAP) e os seus pares se unem para reconstruir o acesso dele, sem que um único administrador central de banco de dados tenha o poder de sequestrar a rede.