Detalhes
IA / protótipo
Aurora
Aurora começou como um assistente de voz local e evoluiu para uma malha de capacidades orientada à privacidade: contratos de serviço tipados, modos de processo LocalBus/BullMQ, chamadas ponto a ponto WebRTC, permissões específicas por destinatário, clientes compartilhados React/TypeScript, autorização Rust/WASM, fala nativa e gerenciamento do ciclo de vida no Android.
Arquitetura 3D ao vivo
Use a navegação para alternar entre diagramas e trabalhos relacionados, depois role o painel para ler os detalhes.
O caminho de voz é o produto: palavra de ativação, transcrição, orquestração, memória, ferramentas e resposta falada.
Problema
Assistentes locais mantêm os dados sob o controle do usuário, mas herdam os limites da máquina à sua frente. O problema central da Aurora é o compartilhamento de capacidade sem comprometer a privacidade ou o controle: um notebook baixo-VRAM pode usar um modelo de desktop aprovado, um telefone pode solicitar a capacidade de fala de outro dispositivo, e cada dispositivo expõe apenas o que o proprietário autorizou.
Contribuição
Desenvolvi e construí a arquitetura do Aurora com contratos de serviço, despacho por barramento, rotas de API geradas, transporte peer, concessões por peer, clientes compartilhados, fala nativa, limites de dados locais e registros de avaliação. A contribuição útil é a integração e a arquitetura: o projeto compõe runtimes e modelos existentes em um sistema assistente/mesh testado com autoridade e limites de ciclo de vida explícitos.
Cinco eixos de arquitetura
Aurora separa cinco decisões que são fáceis de confundir: modo de execução de serviço, superfície do cliente, função de malha, perfil de transporte e camada de runtime. O modo Threads usa LocalBus dentro de um processo Python; o modo processo usa BullMQ sobre Redis entre processos de serviço; nenhum deles significa automaticamente P2P. Um navegador, um shell de desktop ou um cliente Android pode atuar como um console remoto ou como um nó de malha aprovado, dependendo do perfil de runtime e das concessões. HTTP-only, WebRTC-only e WebRTC-preferred são escolhas de transporte, enquanto a autorização permanece uma decisão de aplicação.
Arquitetura
Aurora começou como um assistente local e foi deliberadamente separado em contratos de serviço: coordenador STT, transcrição, palavra de ativação, TTS, orquestrador, DB/RAG, ferramentas, agendador, gateway e supervisor. As mesmas capacidades podem ser executadas em modo de thread através de LocalBus ou em modo de processo através de Redis/BullMQ, com rotas de gateway geradas a partir de contratos tipados e roteamento em malha projetado como configuração em vez de reescritas do chamador.
Contratos de Serviço e Despacho
Um contrato de método registra módulo, versão, nome do método, tópico do barramento, nível de exposição, modelos de entrada/saída, prioridade e permissões necessárias. Esses registros impulsionam o despacho do barramento, validação/docs gerados FastAPI, anúncios de capacidade, reconfiguração e remoção no desligamento. A capacidade torna-se dados que podem ser roteados, projetados, filtrados e revogados, em vez de uma referência direta de objeto Python.
Decisões técnicas
Compensações
Resultado
Um projeto de sistemas de IA avançado: voz UX, privacidade local, orquestração de ferramentas, contratos de serviço, RAG, flexibilidade de modelo-provedor e arquitetura de mesh distribuída, todos visíveis em uma única base de código.
Clientes, Tempo de Execução Nativo e Limites de Dados
O React UI compartilhado fala por meio de um SDK TypeScript e adaptadores de plataforma, em vez de serviços Python diretos, internos WebRTC ou comandos nativos. O desktop-local pode supervisionar um sidecar Python; os pacotes desktop-client e móvel são executados sem Python. Rust/WASM cobre o núcleo de autorização leve e funções nativas selecionadas. Os dados locais-first usam SQLite/OPFS com fallback limitado, e a exportação/importação de conhecimento é limitada por namespace, proveniência, redação e seleção explícita de sobrescrita.
Fala nativa e ciclo de vida do Android
O caminho de fala mais recente do Aurora usa sessões de propriedade Rust, alças de tarefa, estado de geração, cancelamento e confinamento FFI ao redor de Sherpa-ONNX/ONNX Runtime para STT, VAD, detecção de palavra-chave e TTS. A fala do navegador usa workers específicos de tarefa WASM de modo que a inferência síncrona não bloqueie a thread da interface. Em Android, uma sessão de mesh nativa Rust pode manter um DataChannel ativo, responder a uma ferramenta de status de dispositivo autorizada enquanto o WebView dorme, enfileirar mensagens por ponto a ponto limitadas sob a mesma identidade e adiar a orquestração apenas em primeiro plano até a retomada.
Testes e resultados
Conjunto de testes Python
Autorização
Rust/WASM paridade
Modo de processo
Navegador WebRTC
Stack e domínios
- Python
- FastAPI
- Pydantic
- LangGraph
- LangChain
- MCP
- SQLite
- Redis
- BullMQ
- WebRTC
- MQTT
- React
- TypeScript
- Tauri
- Rust
- WebAssembly
- Sherpa-ONNX
- ONNX Runtime
- Android