CARDBOARD PROTOCOL / DOSSIER DO PROJETO
KAYA CLI
Proximidade física como infraestrutura digital temporária.
Capítulo 01
O Gatilho
A cloud era tratada como obrigatória, mesmo quando todas as pessoas já estavam na mesma sala.
Antes da interface, existia uma pergunta mais simples: porque deveriam dois dispositivos próximos precisar de um servidor distante?
OBSERVAÇÃO
As pessoas podem estar na mesma sala, ligadas à mesma rede, e ainda depender de um servidor a milhares de quilómetros para comunicar.
A primeira pergunta não foi como criar outra interface de mensagens. Foi se a cloud precisava realmente de existir no circuito.
A rota herdada
- 01Dispositivo
- 02Internet
- 03Cloud
- 04Identidade central
- 05Internet
- 06Dispositivo
Capítulo 02
A Suposição Oculta
Sistemas de comunicação assumem infraestrutura permanente para grupos que podem ser temporários.
SUPOSIÇÃO
Permanência
Contas são permanentes. Servidores são permanentes. A identidade é centralizada. Mas muitos grupos humanos são temporários.
KAYA começa pelo modelo oposto: o espaço digital surge quando o grupo surge e desaparece quando o grupo parte.
Fronteira depois da remoção
- 01Peer
- 02Rede local
- 03Peer
Capítulo 03
O Primeiro Modelo
Provar presença local, salas e mensagens antes de investir numa interface mais ampla.
PROTOCOLO
Menor sistema credível
- Descoberta automática de peers na LAN
- Salas públicas e mensagens diretas
- Interface de terminal
- Sem login, cloud ou servidor central
Porquê terminal primeiro
O terminal manteve o binário leve, o estado inspecionável e o modelo de interação visível em hardware modesto.
Foi uma decisão de produto: provar a rede e os comandos antes de assumir a complexidade de uma GUI.
Capítulo 04
A Fricção
O primeiro modelo só funcionava enquanto a rede se comportava como o diagrama.
RETRABALHADO
- Multicast pode ser bloqueado
- Peers desaparecem e as rotas ficam obsoletas
- Identidade sem contas continua a exigir confiança
- Mensagens diretas seguras exigem sessões criptográficas
- Transferências e alcance podem falhar
- Salas públicas e DMs seguras têm propriedades distintas
O primeiro modelo funcionava apenas numa rede ideal.
O problema real começou quando a rede deixou de se comportar como o diagrama.
Capítulo 05
A Viragem
Preservar local-first como caminho principal e acrescentar alternativas controladas.
FRONTEIRA DO SISTEMA
Local continua preferencial
TCP direto, endereçamento VPN e relay WAN opcional ampliam o alcance sem transformar o produto em cloud-first.
Payloads cifrados podem atravessar nós intermédios sem expor plaintext. A mesh permanece explicitamente experimental.
- Fingerprints de confiança
- Material de identidade Ed25519 e X25519
- Sessões de DM cifradas
- TTL, pontuação e inspeção de rotas
- Configuração e cache local persistentes
Capítulo 06
O Sistema
Rede, identidade, comandos, persistência e UI permanecem responsabilidades separadas.
Workspace Rust
app commands direct events
files mesh peer persistence
protocol relay rooms security
shared transport ui sdkFluxo de eventos
- 01Descoberta LAN
- 02Estado do peer
- 03Participação em sala
- 04Validação do pacote
- 05Event bus
- 06Atualização da UI
Fluxo de DM segura
- 01Identidade
- 02Fingerprint
- 03Acordo de chave
- 04Sessão cifrada
- 05Transporte escolhido
- 06Decifragem
Capítulo 07
Trade-offs
Cada dependência amplia uma capacidade e introduz um custo visível.
Rust + terminal
Segurança, concorrência, controlo de rede e distribuição nativa.
Custo: uma interface terminal não serve todos os utilizadores.
Multicast + relay opcional
Multicast reduz configuração local; relay amplia alcance.
Custo: multicast não é universal e o relay não pode tornar-se uma dependência central invisível.
Mesh experimental
A mesh explora resiliência entre rotas locais.
Custo: topologia, routing e segurança tornam-se muito mais complexos.
Capítulo 08
Limites Atuais
Os limites permanecem explícitos porque o sistema é infraestrutura exploratória.
LIMITE ATUAL
- Descoberta automática exige IPv4 UDP multicast
- Routing mesh é experimental
- Salas públicas usam plaintext
- Chunks de ficheiros não passam pela mesh
- Sem NAT traversal geral ou cliente mobile
- Criptografia sem auditoria externa
- Não é uma plataforma de comunicação pronta para produção
Capítulo 09
O Que Mudaria
A evolução futura é tratada como extração disciplinada, não como funcionalidade concluída.
PRÓXIMA EXTRAÇÃO
- Versionamento formal do protocolo e testes baseados em propriedades
- Threat modelling e auditoria criptográfica externa
- Pesquisa de NAT traversal e transportes de descoberta
- Melhor observabilidade e chaos testing
- Cliente mobile ou desktop sobre o SDK
- Transferência retomável e UX de confiança mais precisa
Capítulo 10
Ficheiro Técnico
A evidência de implementação por trás da tese do produto.
VERIFICADO
linguagem: Rust
runtime: Tokio
ui: Ratatui
identidade: Ed25519 + X25519
cifra: ChaCha20-Poly1305
descoberta: UDP multicast
alcance: direto / relay opcional / mesh experimentalKAYA começou como ferramenta de comunicação. Tornou-se um argumento: uma rede local pode ser infraestrutura social, não apenas canalização.
Contracapa
Uma rede local pode ser infraestrutura social, não apenas canalização.