SolOS
Uma operating layer sobre um runtime intermediário, com Linux como base.
O SolOS nasce de uma fricção simples: a computação mudou, mas o ambiente operacional principal ainda parece preso a uma lógica de apps isolados, assistentes encaixotados, wallets separadas e automações invisíveis.
A proposta do SolOS é reorganizar esse centro de gravidade. Em vez de tratar agência, identidade, approvals, apps e ativos como peças espalhadas, o projeto tenta reuni-los num mesmo sistema legível, modular e vivo.
A nova formulação do projeto ficou mais precisa: Linux é a base do sistema, o runtime em Rust funciona como middleware de mediação e orquestração, e o SolOS aparece acima disso como operating layer visível.
Arquitetura em andamento
A direção técnica atual evita dois erros comuns: manter tudo em mock por tempo demais, ou tentar um rewrite total antes de existir uma fronteira arquitetural decente. O corte escolhido agora é mais pragmático e mais preciso.
Linux base system
O SolOS não finge um kernel próprio. Ele assume Linux como base confiável para boot, processos, sessão, rede e serviços do host.
Rust runtime intermediary
O runtime em Rust atua como middleware de mediação e orquestração entre o host Linux e a operating layer, normalizando estado e capacidades em contratos estáveis.
SolOS operating layer
A shell nativa continua como camada de apresentação, interação e gramática operacional para Home, Agent, Wallet e Apps.
O primeiro subsistema em Rust agora é tratado explicitamente como runtime intermediary. Isso cria um seam concreto para approvals, task orchestration, wallet mediation, app capability boundaries e presença do agente, enquanto a shell continua evoluindo como superfície nativa do sistema.
Fase atual
SolOS v1.0 RC1: agência inspecionável
O release candidate fecha o primeiro caminho completo e demonstrável: intenção, classificação, capability, aprovação, ação mediada, resultado e trace. O runtime agora exporta contratos versionados, política default-deny, evals persistidos, sessão Wallet explícita e memória com retenção e revogação.
O backend patrocinado continua desligado até existir prova assinada de holder. Isso não é uma lacuna escondida: é a fronteira de segurança do produto. BYOK permanece como fallback e o demonstrador nunca assina Wallet nem executa comandos arbitrários.
Plano vivo
Onde o SolOS esta agora
O plano de conclusão virou um release candidate verificável. A leitura honesta agora é: o SolOS v1.0 RC1 é demonstrável e possui um caminho mediado ponta a ponta; serviços patrocinados, autonomia ampla e Pulso real continuam fora da promessa até seus próprios gates de segurança existirem.
v1.0 RC1 entregue
- tese, arquitetura e roadmap vivos
- shell nativa Qt/QML com Home, Agent, Wallet e Apps
- runtime-core em Rust emitindo contratos estruturados
- Ghost classifier, traces persistidos e semente de avaliação determinística
- manifesto de capacidades default-deny com approvals por escopo
- primeira ação mediada: abrir Workspace somente após aprovação visível
- contratos de sessão Wallet, memória revogável e quota proxy provider-neutral
- Heart Pass Quota Layer visivel em Wallet e Agent/Ghost
- SolOS Pulso definido no CMS como rede social experimental e superfície futura de Apps
Fronteiras honestas
- runtime ainda liderado por snapshot, nao por servico/eventos duraveis
- backend patrocinado permanece desligado até existir prova assinada de holder
- Wallet não assina nem movimenta ativos no demonstrador
- Pulso existe como prototipo CMS e pagina publica somente leitura, ainda sem coleta real ou credit ledger ativo
- native runtime não executa comandos arbitrários do host
Release gate
- testes Rust e invariantes do snapshot
- build da shell web e shell nativa Qt/QML
- validação dos scripts do appliance
- demo de quatro minutos e checklist de release repetível
- tag v1.0.0-rc1 após publicação do corte verificado
SolOS Pulso
Rede social experimental integrada ao ecossistema
O SolOS Pulso entra como uma superfície futura de Apps: uma rede fechada para posts, vídeos, temas periódicos e respostas de uma palavra, onde sinais humanos consentidos podem virar contexto para Ghost e créditos de utilidade para o usuário.
A regra econômica inicial é Pulso Credits: crédito interno, com teto e anti-fraude, usado para Ghost, ferramentas, upload, acesso e participação. Não é promessa de renda nem yield; primeiro a rede cobre custo, depois amadurece mecanismos de repartição.
Por que colaboração aberta importa aqui
O SolOS não é só uma interface bonita nem um pitch abstrato. É uma tese de produto que precisa de crítica, implementação, documentação, design e validação pública. Quanto mais gente boa ajudar, mais rápido a visão sai do campo da especulação e entra no terreno do software útil.
Código e arquitetura
Implementar shell, runtime intermediary, modelos, integrações e superfícies que transformem a tese do SolOS em software real.
Design e linguagem de produto
Refinar a gramática visual, a experiência de approvals, a presença do agente e a clareza da operating layer acima do runtime.
Documentação e narrativa
Consolidar tese, roadmap, onboarding, manifesto técnico e materiais públicos sem perder a distinção entre Linux base, runtime intermediário e SolOS.
Testes, crítica e debate
Contribuir com objeções inteligentes, validação de hipóteses e feedback honesto sobre utilidade, segurança, mediação e legibilidade.
Princípios que orientam o projeto
- agência nativa em vez de assistente preso a uma aba
- ownership explícito em vez de automação opaca
- approvals como primitiva do sistema
- apps como módulos dentro de um ambiente coerente
- suporte às principais línguas humanas como capacidade do Ghost, não apenas tradução de interface
- Linux como base, runtime como mediação e SolOS como operating layer
- documentação viva junto com o código e com a narrativa pública
Ghost
Fluência humana em múltiplas línguas
A próxima direção do Ghost é tratar linguagem humana como parte da mediação operacional do SolOS. Isso vai além de traduzir botões: o agente precisa detectar o idioma do usuário, responder no idioma certo, explicar approvals com clareza e preservar o sentido de fontes, citações, tom e contexto cultural.
A cobertura inicial documentada mira as principais línguas globais, incluindo Inglês, Português, Espanhol, Francês, Alemão, Italiano, Árabe, Hindi, Bengali, Mandarim, Japonês, Coreano, Russo, Indonésio, Turco. A implementação ainda é progressiva, mas a tese pública já fica registrada: um operating layer para agentes e identidade não pode nascer linguisticamente estreito.
SolOS Heart Pass
Passe inicial: NFT utilitário, Ghost e créditos de busca
O primeiro pass público do SolOS pode nascer como um artefato simbólico de apoio e acesso: o SolOS Heart Pass, ancorado na arte NFT Anastacia Our Hearts #1, em Polygon. A proposta é utilitária: identidade de apoiador inicial, guided onboarding, experimentos de Ghost e benefícios de uso conforme o sistema amadurece.
A frente técnica inicial começa pelo Brave Search. Em vez de esconder uma chave global do desenvolvedor, o SolOS deve manter a fronteira de ownership explícita: cada usuário configura sua própria Brave API key, entende seus créditos e limites, e o Ghost valida/salva essa chave localmente. Uma camada futura poderá oferecer quotas patrocinadas por usuário a partir de um backend/proxy com medição transparente.
Este passe não deve ser comunicado como promessa de lucro, yield ou retorno financeiro. O valor público está no acesso, na participação, na identidade de early supporter e nos benefícios progressivos do ecossistema.
Vídeo explicativo
Este vídeo apresenta a visão do SolOS, a proposta da operating layer, o papel do runtime intermediário e o convite aberto para colaboração em código, design, documentação e crítica técnica.
Como colaborar
Se você quer ajudar, a melhor forma é entrar pelo trabalho concreto: código, arquitetura, testes, design, documentação, crítica honesta e refinamento da tese. O objetivo não é formar torcida, mas construir um sistema melhor com inteligência distribuída.