Roadmap/skill-discovery-and-trust.md

Skill discovery, recommendation and trust

Pesquisa inicial sobre descoberta de skills, recomendação e mitigação de risco para skills maliciosos, com preferência por uma arquitetura descentralizada baseada em Nostr.

TL;DR

Não parece existir hoje um padrão Nostr maduro e específico para registry de skills. O que existe são blocos compatíveis que podem ser combinados:

Minha leitura: dá para montar uma arquitetura muito boa em Nostr, mas ela precisará ser composta a partir desses NIPs, e não simplesmente adotada pronta.

1. O que já existe em Nostr que ajuda

1.1 Descoberta de apps e handlers, NIP-89

O NIP-89 define:

Isso é interessante porque se aproxima bastante de um modelo de descoberta de skills:

Ponto forte:

Limitação:

1.2 Listas, sets e curadoria, NIP-51

O NIP-51 define listas públicas/privadas e vários tipos de sets.

Isso é ótimo para:

Também é útil para:

1.3 Labels e classificação, NIP-32

O NIP-32 permite anexar labels a eventos, pubkeys, relays, URLs e tópicos.

Isso pode servir para classificar skills por:

Exemplos de labels úteis:

1.4 Reports, inclusive malware, NIP-56

O NIP-56 define reports (kind:1984) e inclui explicitamente o tipo malware.

Isso é uma peça importante para um ecossistema de skills porque dá uma base para:

Limitação importante:

1.5 Badges e attestations, NIP-58

O NIP-58 permite badges emitidos por terceiros e escolhidos pelo usuário no perfil.

Isso pode virar uma camada de atestação, por exemplo:

Uso interessante:

1.6 Repositórios e código no Nostr, NIP-34

O NIP-34 cobre anúncio de repositórios Git, patches, PRs e issues via Nostr.

Isso sugere um caminho forte para skills:

Isso é melhor do que guardar só um blob solto, porque:

1.7 Serviços/agentes sob demanda, NIP-90

O NIP-90 é mais sobre Data Vending Machines, isto é, pedidos de computação/resultado.

Não resolve registry de skill, mas ajuda a pensar a camada de uso:

Pode ser útil se o projeto quiser suportar dois modelos:

2. O que já existe fora de Nostr e vale reaproveitar

Para segurança, o Nostr sozinho não basta. O ideal é combinar Nostr com práticas modernas de supply chain.

2.1 TUF

O TUF, The Update Framework, é focado em segurança de sistemas de update, incluindo cenários em que o repositório ou chaves são comprometidos.

Ideias reaproveitáveis:

2.2 in-toto

O in-toto registra quais passos foram executados, por quem e em que ordem dentro da supply chain.

Ideias reaproveitáveis:

2.3 SLSA

O SLSA é um framework de níveis de integridade para artefatos de software.

Ideias reaproveitáveis:

2.4 Assinatura e provenance de artefatos

Mesmo quando o registry é descentralizado, ainda vale usar ideias do mundo de pacotes/containers:

3. Proposta de arquitetura Nostr-first para discovery de skills

3.1 Entidades principais

  1. Skill manifest
    • evento descrevendo o skill, versão, publisher, runtime compatível, capabilities e artefatos
  2. Skill recommendation
    • evento de recomendação/curadoria por usuários ou comunidades
  3. Skill labels
    • classificação, compatibilidade, risco, auditoria
  4. Skill reports
    • malware, spam, impersonation, unsafe behavior
  5. Skill badges / attestations
    • emitidos por auditores/curadores confiáveis

3.2 Modelo mínimo

Uma primeira versão poderia ser:

3.3 Ranking / recomendação

A recomendação pode combinar:

3.4 Sinal de uso

Dá para pensar em eventos opcionais de uso, por exemplo:

Mas isso precisa ser tratado com cuidado por privacidade. O default ideal provavelmente é:

4. Como reduzir o risco de skill malicioso

Resposta curta

Não dá para garantir 100%.

O que dá para fazer é construir um sistema de redução de risco em camadas.

4.1 Manifesto com capabilities explícitas

Cada skill deve declarar claramente:

Exemplo de classes de risco:

4.2 Permissões vêm da plataforma, não do skill

Regra importante:

Ou seja, o manifesto não pode auto-conceder poderes.

4.3 Artefatos com hash e assinatura

Para cada versão do skill:

4.4 Provenance e reprodutibilidade

Quanto mais sensível o skill, mais vale exigir:

4.5 Sandbox por padrão

Mesmo skill confiável deve rodar com contenção:

4.6 Revisão humana e auditoria comunitária

Para skills de maior risco, vale exigir:

4.7 Trust graph e curadores

Em vez de confiar em “qualquer skill publicado”, o cliente pode priorizar:

4.8 Revogação e quarentena

Se um skill ou publisher for comprometido, o sistema precisa suportar:

4.9 Política local por organização

Empresas/comunidades podem manter listas próprias:

5. Modelo prático que parece mais promissor

Se fosse desenhar agora, eu faria assim:

Camada 1, identidade e publicação

Camada 2, discovery

Camada 3, reputação

Camada 4, segurança

6. O que eu acho que já existe vs o que ainda falta

Já existe em forma de building blocks

Ainda falta, ou pelo menos não aparece como padrão consolidado

7. Recomendação para o Freedom Skills

Eu seguiria por este caminho:

Fase 1

Fase 2

Fase 3

Fase 4

8. Minha opinião direta

A parte de discovery e recommendation dá para fazer de forma bem elegante em Nostr.

A parte de segurança não deve depender só de Nostr.

Nostr é muito bom para:

Mas a segurança pesada precisa vir da combinação com:

Se eu tivesse que resumir em uma linha:

Nostr resolve bem a camada social do registry, mas não deve ser a única linha de defesa contra skill malicioso.

9. Fontes pesquisadas