--- title: 50 Projetos IndieWeb Baseados em JSON — Versão Completa date: 2026-06-21 summary: Expansão completa das cinquenta ideias IndieWeb de Pablo Murad, com funcionamento, implementação, MVP, evolução, riscos, monetização e viabilidade. tags: [indieweb, json, small-web, protocolos, produto, pablo-murad] flowerColor: "#f7e8f4" --- # 50 Projetos IndieWeb Baseados em JSON **Autor:** Pablo Murad **Ano:** 2026 Este documento transforma cinquenta ideias IndieWeb em propostas de produto e protocolo. A tese central é simples: a web independente não precisa tentar vencer redes sociais no mesmo jogo. Ela precisa criar peças pequenas, interoperáveis, fáceis de publicar e úteis mesmo quando adotadas por uma única pessoa. O eixo técnico é JSON porque ele é simples, legível por máquinas, fácil de gerar em sites estáticos e amigável para APIs modernas. O eixo filosófico é posse: identidade, dados, publicações, recomendações, listas, bibliotecas, eventos e relações devem nascer no domínio do usuário, não dentro de uma plataforma que pode mudar regras, bloquear acesso ou apagar histórico. ## Princípio central A regra para todos os projetos deste documento é: > Um projeto IndieWeb só é forte se funcionar em três níveis: sozinho, em comunidade pequena e em rede aberta. Isso evita o erro clássico de tentar lançar “a nova rede social”. Rede social sem gente é cemitério. Arquivo, feed, catálogo, API, diretório e ferramenta pessoal funcionam mesmo sem multidão. Depois, quando outras pessoas adotam o mesmo formato, surge o efeito de rede. ## Arquitetura comum Quase todos os projetos podem compartilhar a mesma arquitetura: | Camada | Função | Decisão prática | | --- | --- | --- | | Publicação | O dado nasce no domínio do usuário | Arquivos `.json` públicos e versionados | | Descoberta | Outros sistemas encontram o dado | `/.well-known/`, links no HTML, sitemap e manifestos | | Validação | O formato precisa ser confiável | JSON Schema com mensagens claras | | Indexação | Diretórios agregam dados públicos | Crawlers leves, opt-in e respeitando robots.txt | | Interface | Humanos precisam entender | Páginas bonitas, busca, filtros e widgets | | Interoperabilidade | Outros apps precisam usar | API simples, exportação e documentação | | Confiança | Spam e abuso precisam ser tratados | Moderação, assinatura, rate limit e reputação | ## Esquema base recomendado Todo projeto pode usar uma estrutura comum de metadados: ```json { "schema": "https://pablomurad.link/schemas/nome-do-projeto.schema.json", "version": "0.1.0", "owner": { "name": "Pablo Murad", "url": "https://pablomurad.link" }, "updated_at": "2026-06-21T00:00:00-03:00", "items": [] } ``` Essa base resolve versionamento, autoria, atualização e compatibilidade. Cada projeto muda o conteúdo de `items`. ## Estratégia de execução A ordem lógica de implementação não é seguir a lista de 1 a 50 cegamente. A melhor estratégia é criar primeiro os blocos que viram infraestrutura para os outros: 1. **Site Identity Card** 2. **Readme.json** 3. **Static Site Registry** 4. **RSS-to-JSON Hub** 5. **Blog Discovery Network** 6. **Blogroll JSON** 7. **Follow List JSON** 8. **Indie Search Index** Depois disso, os projetos de biblioteca, zines, notas, reviews, eventos e mapas ficam muito mais fáceis porque já existe identidade, descoberta, validação e indexação. ## 1. Blogroll JSON > Um formato portátil para listas públicas de sites recomendados. ### O que é Blogrolls eram uma das melhores mecânicas sociais da web antiga, mas morreram porque ficaram presos a temas de blog, HTML manual e listas difíceis de importar. O problema real é descoberta: quem escreve em site próprio quase sempre fica invisível fora de buscadores e redes centralizadas. ### Como funcionaria - Cada pessoa publica um arquivo `/blogroll.json` no próprio domínio com sites favoritos, categorias, pesos, descrições e data da última revisão. - Um leitor ou diretório consulta esses arquivos, valida o esquema, remove duplicatas e monta mapas de recomendações entre sites independentes. - O usuário continua dono da lista; o serviço central é apenas um índice, não a fonte da verdade. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `site_url` | URL canônica do site. | | `title` | Título legível do item. | | `description` | Descrição curta para humanos. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `language` | Idioma principal. | | `relationship` | Tipo de relação com o item recomendado. | | `weight` | Peso editorial definido pelo dono da lista. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /blogroll.json` - `GET /api/blogroll?domain=exemplo.com` - `POST /api/validate/blogroll` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/blogroll-json.schema.json`. ### MVP honesto - Gerador visual de `blogroll.json`. - Validador público com mensagens claras. - Diretório com busca por tag, idioma e domínio. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Importação de OPML. - Detecção automática de links recíprocos. - Ranking comunitário baseado em recomendações explícitas, não em rastreamento. ### Por que daria certo - É útil para uma pessoa sozinha, porque organiza recomendações pessoais. - Ganha valor com rede, porque cada blogroll vira porta de entrada para outros sites. - É simples de adotar: um arquivo estático já basta. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Pode virar um serviço freemium de hospedagem, validação, analytics ético de cliques externos e diretórios temáticos pagos para comunidades. ### Riscos e mitigação O risco é virar só mais um diretório vazio. A mitigação é começar com curadoria manual forte e importar listas já existentes de OPML/RSS para dar densidade inicial. --- ## 2. Webring JSON > Webrings modernos, automáticos e verificáveis por manifesto. ### O que é Webrings antigos dependiam de HTML copiado e manutenção manual. Quando alguém removia o widget, mudava de domínio ou abandonava o site, o anel quebrava. A ideia resolve a navegação comunitária entre sites pequenos sem depender de rede social. ### Como funcionaria - Cada participante hospeda um `/webring.json` declarando anéis dos quais participa, tags, idioma, URL canônica e preferências de navegação. - Um serviço de anel mantém a ordem, verifica se os membros continuam ativos e gera links `next`, `previous` e `random`. - O widget pode ser estático, mas a autoridade continua distribuída: cada site declara sua participação. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `ring_id` | Campo essencial para representar `ring_id` no formato. | | `member_url` | Campo essencial para representar `member_url` no formato. | | `title` | Título legível do item. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `joined_at` | Campo essencial para representar `joined_at` no formato. | | `status` | Campo essencial para representar `status` no formato. | | `next_url` | Campo essencial para representar `next_url` no formato. | | `previous_url` | Campo essencial para representar `previous_url` no formato. | **Endpoints mínimos:** - `GET /.well-known/webring.json` - `GET /rings/{ring_id}/next?from=domain` - `GET /rings/{ring_id}/random` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/webring-json.schema.json`. ### MVP honesto - Criar um anel temático com 20 sites. - Widget copiável em HTML puro. - Verificador diário de links quebrados. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Anéis por assunto e idioma. - Assinatura de participação para evitar inclusão falsa. - Descoberta de anéis compatíveis a partir de tags. ### Por que daria certo - A navegação lateral tem apelo nostálgico e prático. - Não exige algoritmo: a pessoa literalmente visita vizinhos. - Comunidades pequenas gostam de identidade e pertencimento. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de anéis premium para comunidades, páginas customizadas, estatísticas agregadas sem rastrear usuários e patrocínio de anéis editoriais. ### Riscos e mitigação O risco é spam ou anéis mortos. A mitigação é exigir validação de domínio, checagem automática e curadores por anel. --- ## 3. Readme.json > Um cartão de identidade portátil para pessoas, projetos e sites. ### O que é Perfis pessoais ficam espalhados em redes, bio pages, GitHub, LinkedIn e sites. O problema é que nenhuma dessas plataformas é fonte neutra de identidade. Um `readme.json` transforma o domínio próprio em identidade legível por humanos e máquinas. ### Como funcionaria - O domínio publica um `/readme.json` com nome, bio, links, chaves públicas, interesses, projetos e formas de contato. - Aplicações podem ler esse arquivo para preencher perfis, diretórios, assinaturas e cartões de autor. - O mesmo arquivo pode alimentar uma página bonita, uma API pessoal e validações de posse de domínio. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `name` | Campo essencial para representar `name` no formato. | | `canonical_url` | Campo essencial para representar `canonical_url` no formato. | | `bio` | Campo essencial para representar `bio` no formato. | | `avatar` | Campo essencial para representar `avatar` no formato. | | `links` | Campo essencial para representar `links` no formato. | | `public_keys` | Campo essencial para representar `public_keys` no formato. | | `projects` | Campo essencial para representar `projects` no formato. | | `contact` | Campo essencial para representar `contact` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /readme.json` - `GET /.well-known/readme` - `POST /api/validate/readme` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/readmejson.schema.json`. ### MVP honesto - Esquema JSON e validador. - Gerador de perfil público a partir do JSON. - Badge para sites que tenham identidade válida. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Compatibilidade com h-card, WebFinger e IndieAuth. - Assinaturas criptográficas. - Histórico versionado de identidade. ### Por que daria certo - Identidade própria é fundação do IndieWeb. - Resolve um problema concreto de portabilidade. - Pode ser usado por vários outros projetos da lista como camada base. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Ferramenta SaaS para criar, validar e hospedar identidade pessoal, com recursos pagos para múltiplos perfis, domínios, verificação e exportação. ### Riscos e mitigação O risco é criar mais um formato de perfil sem adoção. A mitigação é mapear para padrões existentes como h-card, WebFinger e JSON-LD, em vez de competir com eles. --- ## 4. Bookmark Exchange > Favoritos públicos, importáveis e organizados por coleção. ### O que é Favoritos pessoais são valiosos, mas ficam presos no navegador, no Pocket, no Raindrop, em threads ou em listas privadas. A web independente precisa de um jeito simples de publicar coleções de links sem virar rede social. ### Como funcionaria - O usuário exporta ou publica coleções em `/bookmarks.json`. - Cada item contém URL, título, resumo, tags, data, nota pessoal e estado de leitura. - Outros leitores podem importar coleções inteiras ou seguir apenas tags específicas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `url` | Campo essencial para representar `url` no formato. | | `title` | Título legível do item. | | `summary` | Campo essencial para representar `summary` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `note` | Campo essencial para representar `note` no formato. | | `source` | Campo essencial para representar `source` no formato. | | `saved_at` | Campo essencial para representar `saved_at` no formato. | | `visibility` | Campo essencial para representar `visibility` no formato. | **Endpoints mínimos:** - `GET /bookmarks.json` - `GET /bookmarks/{collection}.json` - `POST /api/import/bookmarks` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/bookmark-exchange.schema.json`. ### MVP honesto - Importador de HTML de favoritos do navegador. - Página pública de coleções. - Busca local por tags e domínio. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Sincronização com navegadores. - Recomendações por interseção de coleções. - Feeds por tag. ### Por que daria certo - Link salvo é intenção forte, mais valiosa que curtida. - Funciona sem escala massiva. - Cria uma camada humana de curadoria sobre a web. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Plano pago para sincronização, backup, busca full-text, arquivamento de páginas e publicação customizada no domínio do usuário. ### Riscos e mitigação O risco é privacidade: favoritos podem revelar muito. A mitigação é permitir coleções privadas, campos opcionais e publicação seletiva. --- ## 5. Digital Garden Feed > Um feed aberto para notas vivas, jardins digitais e pensamentos em evolução. ### O que é Blogs publicam textos finalizados; jardins digitais publicam ideias em processo. O problema é que RSS e feeds comuns não capturam bem estado, maturidade, backlinks, relações e revisões de notas. ### Como funcionaria - Cada jardim publica `/garden.json` com notas, status de maturidade, links internos, backlinks, tópicos e datas de atualização. - Leitores agregam notas não como posts cronológicos, mas como conhecimento em evolução. - A interface mostra sementes, brotos, árvores e trilhas de leitura. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `id` | Campo essencial para representar `id` no formato. | | `title` | Título legível do item. | | `url` | Campo essencial para representar `url` no formato. | | `status` | Campo essencial para representar `status` no formato. | | `topics` | Campo essencial para representar `topics` no formato. | | `links` | Campo essencial para representar `links` no formato. | | `backlinks` | Campo essencial para representar `backlinks` no formato. | | `created_at` | Campo essencial para representar `created_at` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /garden.json` - `GET /garden/{topic}.json` - `GET /api/gardens/search?q=tema` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/digital-garden-feed.schema.json`. ### MVP honesto - Plugin/exportador para Markdown. - Agregador simples por tópico. - Página de nota com status e relações. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Busca semântica. - Grafo visual entre jardins. - Sincronização com Obsidian, Logseq ou repositórios Git. ### Por que daria certo - Há uma comunidade crescente de pessoas publicando notas, não só artigos. - O valor está na atualização contínua, não no post único. - JSON permite que ferramentas diferentes leiam o mesmo jardim. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de jardins, busca semântica premium, visualizações avançadas e publicação estática automatizada. ### Riscos e mitigação O risco é excesso de complexidade. A mitigação é começar com cinco campos obrigatórios e deixar grafo/semântica como evolução. --- ## 6. Indie Events > Calendário distribuído para eventos pequenos, independentes e comunitários. ### O que é Eventos locais, encontros online e comunidades pequenas dependem de plataformas centralizadas que controlam descoberta, RSVP e dados dos participantes. O problema não é criar um calendário; é permitir descoberta sem entregar a comunidade para uma plataforma. ### Como funcionaria - Organizadores publicam `/events.json` com eventos futuros e passados. - Agregadores indexam por cidade, idioma, tema, formato e data. - Participantes podem seguir calendários por feed, baixar ICS ou responder via formulário/IndieAuth. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `id` | Campo essencial para representar `id` no formato. | | `name` | Campo essencial para representar `name` no formato. | | `description` | Descrição curta para humanos. | | `start` | Campo essencial para representar `start` no formato. | | `end` | Campo essencial para representar `end` no formato. | | `timezone` | Campo essencial para representar `timezone` no formato. | | `location` | Campo essencial para representar `location` no formato. | | `online_url` | Campo essencial para representar `online_url` no formato. | | `organizer` | Campo essencial para representar `organizer` no formato. | | `rsvp_url` | Campo essencial para representar `rsvp_url` no formato. | **Endpoints mínimos:** - `GET /events.json` - `GET /events.ics` - `POST /events/{id}/rsvp` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-events.schema.json`. ### MVP honesto - Cadastro manual de eventos. - Exportação JSON e ICS. - Página pública filtrável por data e tag. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - RSVP federado. - Eventos recorrentes. - Integração com mapas e calendários pessoais. ### Por que daria certo - Calendário é utilidade real, não vaidade social. - Funciona em nichos locais e comunidades técnicas. - Pode interoperar com formatos já conhecidos como iCalendar e schema.org Event. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Cobrança por páginas de comunidade, inscrições, newsletters de eventos e ferramentas de check-in. ### Riscos e mitigação O risco é competir com plataformas gigantes. A mitigação é mirar eventos que valorizam independência, nicho e posse de dados. --- ## 7. Guestbook API > Livro de visitas moderno para sites pessoais. ### O que é O livro de visitas desapareceu porque comentários viraram sistemas pesados, spam virou inferno e redes sociais engoliram interações pequenas. Ainda existe valor em um gesto simples: “passei aqui, gostei, deixei meu nome”. ### Como funcionaria - O site expõe um endpoint de guestbook ou usa um serviço externo que recebe entradas assinadas. - Mensagens têm nome, URL, texto curto, data, status de moderação e prova anti-spam. - O dono do site aprova, rejeita ou responde; a exibição pode ser um widget estático. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `author_name` | Campo essencial para representar `author_name` no formato. | | `author_url` | Campo essencial para representar `author_url` no formato. | | `message` | Campo essencial para representar `message` no formato. | | `created_at` | Campo essencial para representar `created_at` no formato. | | `status` | Campo essencial para representar `status` no formato. | | `reply` | Campo essencial para representar `reply` no formato. | | `signature` | Campo essencial para representar `signature` no formato. | **Endpoints mínimos:** - `GET /guestbook.json` - `POST /guestbook` - `POST /guestbook/{id}/moderate` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/guestbook-api.schema.json`. ### MVP honesto - Widget HTML/JS simples. - Painel de moderação. - Exportação JSON pública. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Login por IndieAuth. - Bloqueio federado de spam. - Importação/exportação entre provedores. ### Por que daria certo - Tem apelo emocional e baixa fricção. - É mais leve que comentários completos. - Dá vida a sites pessoais sem exigir rede social. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Serviço hospedado com plano gratuito limitado, domínios personalizados, moderação avançada e proteção anti-spam paga. ### Riscos e mitigação Spam é o risco principal. A mitigação é moderação por padrão, rate limit, honeypot, blocklists e publicação apenas após aprovação. --- ## 8. Blog Discovery Network > Uma rede aberta para encontrar blogs independentes por relação, tema e contexto. ### O que é A descoberta de blogs foi quebrada por SEO ruim, redes sociais e mecanismos de recomendação fechados. Quem escreve bem em domínio próprio não tem uma superfície justa de descoberta. ### Como funcionaria - Um crawler leve encontra feeds, microformats, blogrolls e links relacionados. - Cada blog recebe um perfil com temas, idioma, frequência, vizinhos e fontes de descoberta. - O usuário explora por assunto, semântica, links entre blogs e recomendações humanas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `domain` | Campo essencial para representar `domain` no formato. | | `feed_url` | Campo essencial para representar `feed_url` no formato. | | `topics` | Campo essencial para representar `topics` no formato. | | `language` | Idioma principal. | | `links_out` | Campo essencial para representar `links_out` no formato. | | `links_in` | Campo essencial para representar `links_in` no formato. | | `last_seen` | Campo essencial para representar `last_seen` no formato. | | `quality_signals` | Campo essencial para representar `quality_signals` no formato. | **Endpoints mínimos:** - `POST /api/submit-site` - `GET /api/sites/{domain}` - `GET /api/discover?tag=historia` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/blog-discovery-network.schema.json`. ### MVP honesto - Submissão manual de blogs. - Crawler de RSS/JSON Feed. - Diretório com filtros básicos. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Grafo global de blogs. - Recomendações por vizinhança. - API pública para leitores RSS. ### Por que daria certo - A dor de descoberta é real e antiga. - Começa com curadoria manual, depois automatiza. - Pode virar infraestrutura para vários outros projetos. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização API paga para apps de leitura, diretórios de nicho, relatórios agregados e serviços de descoberta premium. ### Riscos e mitigação Crawler ruim vira lixo rápido. A mitigação é começar com opt-in, critérios transparentes e revisão humana nas primeiras centenas de sites. --- ## 9. Podcast Directory > Diretório aberto de podcasts independentes com metadados portáveis. ### O que é Podcasts dependem de diretórios fechados para descoberta. RSS ainda é aberto, mas descoberta, rankings, categorias e recomendações costumam ser controlados por plataformas. ### Como funcionaria - O diretório lê feeds RSS e gera um índice JSON normalizado com título, episódios, idioma, temas, autor, site canônico e status de atualização. - Produtores podem publicar metadados adicionais em `/podcast.json`. - O público encontra podcasts por tema real, não só por ranking de plataforma. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `podcast_url` | Campo essencial para representar `podcast_url` no formato. | | `rss_url` | Campo essencial para representar `rss_url` no formato. | | `title` | Título legível do item. | | `author` | Campo essencial para representar `author` no formato. | | `language` | Idioma principal. | | `categories` | Campo essencial para representar `categories` no formato. | | `episodes` | Campo essencial para representar `episodes` no formato. | | `explicit` | Campo essencial para representar `explicit` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `POST /api/submit-podcast` - `GET /podcasts/{slug}.json` - `GET /api/search?topic=cinema` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/podcast-directory.schema.json`. ### MVP honesto - Indexador de RSS. - Busca por título, tema e idioma. - Página pública do podcast. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Recomendações editoriais. - Coleções públicas de podcasts. - API para apps independentes. ### Por que daria certo - Podcast já usa uma base aberta: RSS. - O gargalo é descoberta e curadoria. - Independentes valorizam canais fora das big platforms. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Destaques patrocinados claramente marcados, páginas premium para produtores, analytics agregados e API comercial. ### Riscos e mitigação O risco é virar cópia pobre do Apple/Spotify. A mitigação é foco em independentes, transparência e metadados que plataformas ignoram. --- ## 10. Zine Directory > Catálogo aberto de zines digitais e impressos. ### O que é Zines vivem em Gumroad, PDFs soltos, posts, lojas pequenas e redes sociais. A produção é rica, mas quase invisível e difícil de arquivar. ### Como funcionaria - Autores publicam `/zines.json` com edições, temas, formatos, preço, licença e links de compra/download. - Um diretório indexa zines por tema, idioma, formato, periodicidade e disponibilidade. - Cada zine pode ter página própria com histórico de edições. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `title` | Título legível do item. | | `issue` | Campo essencial para representar `issue` no formato. | | `creator` | Campo essencial para representar `creator` no formato. | | `description` | Descrição curta para humanos. | | `topics` | Campo essencial para representar `topics` no formato. | | `format` | Campo essencial para representar `format` no formato. | | `price` | Campo essencial para representar `price` no formato. | | `license` | Campo essencial para representar `license` no formato. | | `download_url` | Campo essencial para representar `download_url` no formato. | | `purchase_url` | Campo essencial para representar `purchase_url` no formato. | **Endpoints mínimos:** - `GET /zines.json` - `POST /api/submit-zine` - `GET /api/zines?topic=arte` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/zine-directory.schema.json`. ### MVP honesto - Cadastro manual de zines. - Catálogo público com filtros. - Página de edição com metadados. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Federação de catálogos. - Geração automática de EPUB/PDF. - Assinaturas independentes. ### Por que daria certo - Zine é cultura de nicho; diretórios humanos funcionam melhor que algoritmos genéricos. - JSON resolve portabilidade e arquivamento. - Pode atender criadores que não querem depender de marketplace. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Comissão opcional em vendas, páginas premium, ferramentas de publicação e clubes de assinatura. ### Riscos e mitigação O risco é baixa frequência de publicação. A mitigação é aceitar zines impressos, digitais, arquivos históricos e coleções. --- ## 11. Now Page Feed > Um agregador para páginas `/now` com histórico e descoberta. ### O que é Páginas `/now` mostram o que uma pessoa está fazendo no momento, mas são isoladas. Não existe um jeito comum de seguir mudanças sem visitar manualmente cada site. ### Como funcionaria - Cada site publica `/now.json` com foco atual, projetos, leituras, localização aproximada opcional e última atualização. - Um leitor acompanha mudanças de pessoas escolhidas, como um feed de presença lenta. - O histórico preserva fases de vida e projetos sem transformar tudo em timeline viciante. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `status` | Campo essencial para representar `status` no formato. | | `projects` | Campo essencial para representar `projects` no formato. | | `reading` | Campo essencial para representar `reading` no formato. | | `watching` | Campo essencial para representar `watching` no formato. | | `location_label` | Campo essencial para representar `location_label` no formato. | | `mood_optional` | Campo essencial para representar `mood_optional` no formato. | | `updated_at` | Data da última atualização. | | `archive_url` | Campo essencial para representar `archive_url` no formato. | **Endpoints mínimos:** - `GET /now.json` - `GET /api/now?domain=exemplo.com` - `GET /api/now/recent` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/now-page-feed.schema.json`. ### MVP honesto - Gerador de `/now.json`. - Agregador de páginas cadastradas. - Notificação quando alguém atualiza. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Histórico mensal. - Integração com Readme.json. - Busca por pessoas trabalhando em temas parecidos. ### Por que daria certo - É íntimo, útil e menos performático que rede social. - Funciona para networking leve. - Dá contexto humano a sites pessoais. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Ferramenta paga para profissionais independentes manterem página now, histórico e newsletter automática. ### Riscos e mitigação O risco é parecer trivial. A mitigação é conectar `/now` a projetos, disponibilidade e colaboração. --- ## 12. Uses Feed > Feed estruturado das ferramentas, equipamentos e serviços usados por uma pessoa. ### O que é Páginas `/uses` são populares entre desenvolvedores e criadores, mas são HTML isolado. Não dá para comparar stacks, descobrir ferramentas por perfil ou acompanhar mudanças. ### Como funcionaria - O usuário publica `/uses.json` com hardware, software, serviços, livros de referência e notas de uso real. - Um diretório permite explorar ferramentas por profissão, orçamento, sistema operacional e finalidade. - Cada item pode conter link, custo, nota, substitutos e data de adoção. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `category` | Campo essencial para representar `category` no formato. | | `item_name` | Campo essencial para representar `item_name` no formato. | | `vendor` | Campo essencial para representar `vendor` no formato. | | `url` | Campo essencial para representar `url` no formato. | | `price` | Campo essencial para representar `price` no formato. | | `why` | Campo essencial para representar `why` no formato. | | `alternatives` | Campo essencial para representar `alternatives` no formato. | | `started_at` | Campo essencial para representar `started_at` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /uses.json` - `GET /api/uses?tool=obsidian` - `GET /api/compare?category=editor` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/uses-feed.schema.json`. ### MVP honesto - Editor visual de uses. - Página pública bonita. - Busca por ferramenta e categoria. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Comparações entre stacks. - Histórico de trocas. - Afiliados transparentes e declarados. ### Por que daria certo - Pessoas confiam em uso real mais do que review genérico. - A estrutura JSON permite comparação. - Tem potencial comercial claro sem precisar vender dados. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Afiliados éticos, páginas premium, relatórios de tendências por nicho e ferramentas para creators. ### Riscos e mitigação O risco é virar spam de afiliado. A mitigação é exigir notas pessoais, histórico e transparência de monetização. --- ## 13. Public Library JSON > Biblioteca pessoal pública, pesquisável e interoperável. ### O que é Bibliotecas pessoais ficam no Skoob, Goodreads, planilhas ou apps fechados. O livro pertence à pessoa, mas o grafo de leitura fica preso em plataforma. ### Como funcionaria - Cada leitor publica `/library.json` com livros possuídos, lidos, desejados, emprestados ou recomendados. - O catálogo usa ISBN quando existir, mas permite obras sem ISBN, PDFs, zines e domínio público. - Agregadores mostram bibliotecas por tema, autor, idioma e disponibilidade. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `title` | Título legível do item. | | `author` | Campo essencial para representar `author` no formato. | | `isbn` | Campo essencial para representar `isbn` no formato. | | `status` | Campo essencial para representar `status` no formato. | | `format` | Campo essencial para representar `format` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `rating_optional` | Campo essencial para representar `rating_optional` no formato. | | `notes_url` | Campo essencial para representar `notes_url` no formato. | | `owned` | Campo essencial para representar `owned` no formato. | | `lent_to` | Campo essencial para representar `lent_to` no formato. | **Endpoints mínimos:** - `GET /library.json` - `GET /api/library?domain=exemplo.com` - `GET /api/books/{isbn}` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/public-library-json.schema.json`. ### MVP honesto - Importador CSV/Goodreads. - Catálogo público por usuário. - Busca por título, autor e tag. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Integração com ISBN/Open Library. - Empréstimos entre pessoas. - Recomendações por bibliotecas semelhantes. ### Por que daria certo - Biblioteca pessoal é identidade cultural. - Funciona offline/online e não depende de postagem frequente. - Gera muitos caminhos para comunidade e descoberta. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de catálogo, app móvel, etiquetas/QR codes, clube de leitura e recursos de inventário doméstico. ### Riscos e mitigação O risco é dados bibliográficos inconsistentes. A mitigação é aceitar imperfeição no MVP e enriquecer metadados progressivamente. --- ## 14. Reading Progress Feed > Feed de progresso de leitura sem depender de rede social literária. ### O que é Marcar leitura é útil, mas plataformas transformam isso em gamificação e dados fechados. Um feed aberto permite registrar progresso sem entregar hábitos de leitura para um silo. ### Como funcionaria - O leitor publica `/reading.json` com livros ativos, página/percentual, sessões, pausas e notas públicas opcionais. - Apps exibem progresso como timeline calma ou dashboard pessoal. - Clubes de leitura podem agregar feeds dos membros com consentimento. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `book_id` | Campo essencial para representar `book_id` no formato. | | `title` | Título legível do item. | | `author` | Campo essencial para representar `author` no formato. | | `progress_percent` | Campo essencial para representar `progress_percent` no formato. | | `page` | Campo essencial para representar `page` no formato. | | `status` | Campo essencial para representar `status` no formato. | | `started_at` | Campo essencial para representar `started_at` no formato. | | `updated_at` | Data da última atualização. | | `note` | Campo essencial para representar `note` no formato. | **Endpoints mínimos:** - `GET /reading.json` - `POST /api/reading/update` - `GET /api/reading/timeline` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/reading-progress-feed.schema.json`. ### MVP honesto - Formulário simples de atualização. - Página de progresso atual. - Exportação JSON. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Estatísticas anuais. - Metas privadas. - Integração com Public Library JSON. ### Por que daria certo - É útil mesmo privado, como diário de leitura. - Pode alimentar clubes e blogs automaticamente. - Evita lock-in de plataformas literárias. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização App pago de tracking, relatórios, backup, widgets para blogs e recursos para clubes. ### Riscos e mitigação O risco é transformar leitura em ansiedade métrica. A mitigação é tornar metas opcionais e priorizar notas qualitativas. --- ## 15. Distributed Comments > Comentários distribuídos que pertencem ao autor e aparecem no destino. ### O que é Comentários em blogs sofrem com spam, perda histórica e dependência de serviços externos. Redes sociais resolvem distribuição, mas roubam a conversa do site original. ### Como funcionaria - Uma resposta é publicada no domínio de quem comenta, com link para o post original. - O site original recebe uma notificação via Webmention ou endpoint compatível. - Após validação, o comentário aparece no post, apontando para a fonte canônica. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `source_url` | Campo essencial para representar `source_url` no formato. | | `target_url` | Campo essencial para representar `target_url` no formato. | | `author` | Campo essencial para representar `author` no formato. | | `content` | Campo essencial para representar `content` no formato. | | `published_at` | Campo essencial para representar `published_at` no formato. | | `type` | Campo essencial para representar `type` no formato. | | `signature` | Campo essencial para representar `signature` no formato. | | `moderation_status` | Campo essencial para representar `moderation_status` no formato. | **Endpoints mínimos:** - `POST /webmention` - `GET /comments.json?target=url` - `POST /api/comments/moderate` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/distributed-comments.schema.json`. ### MVP honesto - Receiver de Webmention. - Painel de moderação. - Widget para exibir comentários aprovados. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Assinaturas criptográficas. - Threading distribuído. - Listas compartilhadas de bloqueio. ### Por que daria certo - A base conceitual já existe no IndieWeb. - Mantém posse e contexto da conversa. - É modular: pode funcionar só para um blog. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de receiver, moderação anti-spam, backup de comentários e widget premium. ### Riscos e mitigação Spam e abuso são inevitáveis. A mitigação é moderação, verificação de origem, rate limit e listas de confiança. --- ## 16. Indie Search Index > Índice de busca dedicado à Small Web. ### O que é Buscadores gerais favorecem sites grandes, SEO agressivo e conteúdo comercial. A Small Web precisa de busca menor, transparente e orientada a qualidade humana. ### Como funcionaria - Sites entram por submissão voluntária, feeds, blogrolls e diretórios parceiros. - O crawler respeita robots.txt, limita frequência e prioriza conteúdo canônico. - O ranking mistura texto, frescor, links independentes, curadoria e sinais explícitos, sem perfil comportamental do usuário. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `url` | Campo essencial para representar `url` no formato. | | `title` | Título legível do item. | | `content_hash` | Campo essencial para representar `content_hash` no formato. | | `language` | Idioma principal. | | `topics` | Campo essencial para representar `topics` no formato. | | `feed_url` | Campo essencial para representar `feed_url` no formato. | | `last_crawled` | Campo essencial para representar `last_crawled` no formato. | | `canonical_url` | Campo essencial para representar `canonical_url` no formato. | | `quality_flags` | Campo essencial para representar `quality_flags` no formato. | **Endpoints mínimos:** - `POST /api/submit-url` - `GET /api/search?q=termo` - `GET /api/index/domain/{domain}` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-search-index.schema.json`. ### MVP honesto - Crawler opt-in. - Busca full-text básica. - Página de submissão e remoção. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Ranking comunitário. - Índices por idioma/nicho. - API para leitores e navegadores. ### Por que daria certo - Há insatisfação real com busca cheia de SEO lixo. - Um índice pequeno pode ser melhor dentro de um nicho. - Transparência é diferencial contra caixas-pretas. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização API paga, busca personalizada para comunidades, instâncias privadas e patrocínio transparente. ### Riscos e mitigação Busca é cara e difícil. A mitigação é não tentar indexar a web inteira; começar por nichos opt-in. --- ## 17. Static Site Registry > Registro público de sites estáticos e seus manifestos. ### O que é Sites estáticos são baratos, rápidos e duráveis, mas não têm um registro comum de capacidades: feed, autor, licença, tecnologias, endpoints e coleções. ### Como funcionaria - Cada site publica um manifesto `/site.json` com identidade, feeds, coleções, licença, idioma e recursos disponíveis. - O registro valida esses manifestos e cria um diretório técnico da web estática. - Ferramentas podem descobrir automaticamente onde está o feed, o arquivo de identidade, o sitemap e APIs estáticas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `site_name` | Campo essencial para representar `site_name` no formato. | | `domain` | Campo essencial para representar `domain` no formato. | | `owner` | Campo essencial para representar `owner` no formato. | | `language` | Idioma principal. | | `feeds` | Campo essencial para representar `feeds` no formato. | | `collections` | Campo essencial para representar `collections` no formato. | | `license` | Campo essencial para representar `license` no formato. | | `generator` | Campo essencial para representar `generator` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /site.json` - `POST /api/submit-site` - `GET /api/sites/static` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/static-site-registry.schema.json`. ### MVP honesto - Esquema `site.json`. - Validador público. - Diretório de sites compatíveis. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Badges de conformidade. - Monitoramento de uptime. - Descoberta automática de recursos IndieWeb. ### Por que daria certo - Manifestos são simples e úteis para automação. - Sites estáticos combinam com arquivos JSON públicos. - Vira infraestrutura para crawlers e agregadores. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Monitoramento premium, validação CI/CD, badges customizados e relatórios de qualidade técnica. ### Riscos e mitigação O risco é baixa motivação para publicar manifesto. A mitigação é dar benefícios imediatos: badge, diagnóstico e inclusão no diretório. --- ## 18. Wiki Exchange > Interligação aberta entre wikis pessoais e comunitárias. ### O que é Wikis são ilhas. Mesmo quando duas páginas falam do mesmo tema, raramente existe descoberta de backlinks entre instalações, jardins e bases pessoais. ### Como funcionaria - Cada wiki exporta um `/wiki.json` com páginas, aliases, tópicos, links internos e links externos. - Um agregador identifica páginas relacionadas, backlinks globais e conceitos compartilhados. - A navegação passa a acontecer entre wikis diferentes sem exigir uma plataforma única. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `page_id` | Campo essencial para representar `page_id` no formato. | | `title` | Título legível do item. | | `url` | Campo essencial para representar `url` no formato. | | `aliases` | Campo essencial para representar `aliases` no formato. | | `topics` | Campo essencial para representar `topics` no formato. | | `outgoing_links` | Campo essencial para representar `outgoing_links` no formato. | | `summary` | Campo essencial para representar `summary` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /wiki.json` - `GET /api/wiki/backlinks?url=...` - `GET /api/wiki/topic/{slug}` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/wiki-exchange.schema.json`. ### MVP honesto - Exportador para Markdown/wiki estática. - Índice de páginas públicas. - Busca por título e alias. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Backlinks globais. - Resolução de entidades. - Grafo interwiki. ### Por que daria certo - Quem mantém wiki pessoal valoriza ligação entre ideias. - Backlinks globais criam valor imediato. - Pode integrar Digital Garden Feed e Knowledge Graph. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de wiki, busca semântica, mapas de conhecimento e instâncias para comunidades de pesquisa. ### Riscos e mitigação O risco é ambiguidade semântica. A mitigação é usar aliases, URLs canônicas e permitir curadoria manual de equivalências. --- ## 19. Article Recommendations > Recomendações de artigos baseadas em curadoria aberta, não em vigilância. ### O que é Recomendações de leitura são dominadas por plataformas que otimizam retenção. A Small Web precisa de sugestão de leitura baseada em contexto, tags, links e escolhas humanas. ### Como funcionaria - Artigos publicam metadados estruturados com tema, resumo, autor, idioma e relações. - Leitores e curadores publicam listas JSON de recomendações. - O motor sugere artigos parecidos por tags, links, embeddings locais e recomendações explícitas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `article_url` | Campo essencial para representar `article_url` no formato. | | `title` | Título legível do item. | | `author` | Campo essencial para representar `author` no formato. | | `summary` | Campo essencial para representar `summary` no formato. | | `topics` | Campo essencial para representar `topics` no formato. | | `language` | Idioma principal. | | `recommended_by` | Campo essencial para representar `recommended_by` no formato. | | `reason` | Campo essencial para representar `reason` no formato. | | `published_at` | Campo essencial para representar `published_at` no formato. | **Endpoints mínimos:** - `POST /api/recommend` - `GET /api/articles/related?url=...` - `GET /recommendations.json` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/article-recommendations.schema.json`. ### MVP honesto - Bookmarklet para recomendar artigo. - Página de recomendações por usuário. - API de artigos relacionados. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Recomendação semântica. - Listas editoriais. - Integração com RSS readers. ### Por que daria certo - Curadoria humana é mais confiável em nichos. - Funciona sem rastrear comportamento individual. - Melhora descoberta de conteúdo longo. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Planos para newsletters, comunidades, leitores profissionais e API de recomendação por nicho. ### Riscos e mitigação O risco é manipulação por spam. A mitigação é reputação por domínio, peso para curadores confiáveis e transparência de motivos. --- ## 20. Small Web Explorer > Explorador visual da web pequena, pessoal e independente. ### O que é A web pequena não é só conteúdo; é território. O problema é que não existe uma forma boa de explorar relações entre sites, temas, feeds, blogrolls e comunidades. ### Como funcionaria - O sistema coleta sites opt-in, links públicos, feeds e manifestos. - Gera mapas navegáveis por tema, idioma, tecnologia, vizinhança e distância de links. - O usuário pode explorar como quem anda por uma cidade, não como quem faz uma busca objetiva. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `node_id` | Campo essencial para representar `node_id` no formato. | | `domain` | Campo essencial para representar `domain` no formato. | | `title` | Título legível do item. | | `topics` | Campo essencial para representar `topics` no formato. | | `edges` | Campo essencial para representar `edges` no formato. | | `cluster` | Campo essencial para representar `cluster` no formato. | | `language` | Idioma principal. | | `last_seen` | Campo essencial para representar `last_seen` no formato. | **Endpoints mínimos:** - `GET /api/graph` - `GET /api/explore?start=domain` - `GET /api/clusters` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/small-web-explorer.schema.json`. ### MVP honesto - Mapa simples com nós e links. - Cadastro manual de sites. - Filtro por tags. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Visualização gráfica avançada. - Trilhas de descoberta. - Snapshots históricos do grafo. ### Por que daria certo - Exploração visual dá prazer e diferenciação. - A Small Web tem valor justamente nas relações. - Pode usar dados de Blogroll, Discovery e Webrings. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Instâncias customizadas para comunidades, mapas patrocinados, API de grafo e relatórios de ecossistema. ### Riscos e mitigação Grafos grandes ficam confusos. A mitigação é foco em navegação por recortes pequenos e filtros fortes. --- ## 21. Blog Census > Censo voluntário e aberto de blogs independentes. ### O que é Ninguém sabe direito quantos blogs pessoais existem, em quais idiomas, com qual frequência ou usando quais ferramentas. Sem dados, a web independente parece menor do que é. ### Como funcionaria - Blogs participam voluntariamente publicando `/census.json` ou preenchendo formulário. - O censo coleta apenas metadados públicos e agregados: idioma, tema, plataforma, frequência e feeds. - O resultado vira dashboard anual sobre saúde da blogosfera independente. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `domain` | Campo essencial para representar `domain` no formato. | | `language` | Idioma principal. | | `platform` | Campo essencial para representar `platform` no formato. | | `topics` | Campo essencial para representar `topics` no formato. | | `post_frequency` | Campo essencial para representar `post_frequency` no formato. | | `started_at` | Campo essencial para representar `started_at` no formato. | | `feeds` | Campo essencial para representar `feeds` no formato. | | `country_optional` | Campo essencial para representar `country_optional` no formato. | **Endpoints mínimos:** - `GET /census.json` - `POST /api/census/submit` - `GET /api/census/stats` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/blog-census.schema.json`. ### MVP honesto - Formulário de participação. - Dashboard agregado. - Export CSV/JSON público. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Relatórios anuais. - Séries históricas. - Recortes por país, idioma e plataforma. ### Por que daria certo - Dados agregados ajudam comunidades a se enxergar. - É um projeto de baixo custo inicial. - Gera material público citável e compartilhável. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Relatórios premium, patrocínio institucional, consultoria para plataformas de publicação e newsletters de análise. ### Riscos e mitigação O risco é viés de amostra. A mitigação é declarar metodologia e tratar como censo voluntário, não verdade absoluta da web. --- ## 22. Indie Analytics > Analytics ético para sites pessoais, sem vigilância de usuários. ### O que é Donos de sites querem saber se alguém lê, mas ferramentas comuns exageram em rastreamento, cookies e perfis. A alternativa é medir o necessário sem invadir. ### Como funcionaria - O site registra eventos mínimos: pageview agregada, referrer reduzido, país aproximado opcional e user-agent truncado. - Os logs são exportáveis em JSON e podem ser publicados de forma agregada. - O dashboard prioriza tendências, páginas populares e fontes, não identificação de pessoas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `path` | Campo essencial para representar `path` no formato. | | `date` | Campo essencial para representar `date` no formato. | | `views` | Campo essencial para representar `views` no formato. | | `referrer_domain` | Campo essencial para representar `referrer_domain` no formato. | | `country_optional` | Campo essencial para representar `country_optional` no formato. | | `device_class` | Campo essencial para representar `device_class` no formato. | | `bot_flag` | Campo essencial para representar `bot_flag` no formato. | **Endpoints mínimos:** - `POST /collect` - `GET /analytics.json` - `GET /api/stats?site=domain` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-analytics.schema.json`. ### MVP honesto - Script leve sem cookies. - Dashboard diário/semanal. - Exportação JSON. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Comparação anônima entre sites opt-in. - Alertas de tráfego incomum. - Integração com Static Site Registry. ### Por que daria certo - Há demanda por analytics simples e respeitoso. - Sites pequenos não precisam de vigilância pesada. - JSON facilita portabilidade e auditoria. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização SaaS por volume, instâncias self-hosted, relatórios premium e monitoramento de performance. ### Riscos e mitigação O risco é escorregar para rastreamento invasivo. A mitigação é política técnica rígida: sem cookies, sem fingerprinting, retenção curta. --- ## 23. Follow List JSON > Lista pública e portátil de pessoas, sites e feeds seguidos. ### O que é Seguir alguém virou ação presa a plataformas. Se a conta some ou a rede muda regra, a lista social desaparece. Uma follow list em JSON devolve posse sobre o grafo social. ### Como funcionaria - O usuário publica `/following.json` com URLs, feeds, categorias, relação e prioridade. - Leitores importam essa lista para montar timeline, RSS reader ou diretório pessoal. - A lista pode ser pública, parcial ou privada/exportável. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `url` | Campo essencial para representar `url` no formato. | | `feed_url` | Campo essencial para representar `feed_url` no formato. | | `name` | Campo essencial para representar `name` no formato. | | `category` | Campo essencial para representar `category` no formato. | | `relationship` | Tipo de relação com o item recomendado. | | `priority` | Campo essencial para representar `priority` no formato. | | `added_at` | Campo essencial para representar `added_at` no formato. | | `notes` | Campo essencial para representar `notes` no formato. | **Endpoints mínimos:** - `GET /following.json` - `POST /api/import/following` - `GET /api/following/opml` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/follow-list-json.schema.json`. ### MVP honesto - Importar OPML/RSS. - Gerar `following.json`. - Exportar OPML de volta. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Sincronização entre leitores. - Descoberta de seguidos em comum. - Compatibilidade com ActivityPub/WebFinger. ### Por que daria certo - É útil mesmo sem rede: backup da própria lista. - Conecta RSS, blogs e perfis sociais abertos. - É base para leitores independentes. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Gerenciador pago de follows, backup, sincronização multi-app e recomendações transparentes. ### Riscos e mitigação O risco é exposição social indesejada. A mitigação é permitir listas privadas e publicação seletiva por categoria. --- ## 24. Indie Followers > Seguidores leves para sites próprios, sem plataforma central. ### O que é Sites independentes têm leitores, mas não têm uma camada simples de seguidores visíveis. RSS resolve assinatura, mas não cria presença social opcional. ### Como funcionaria - Um leitor declara que segue um site por Webmention, IndieAuth ou arquivo público de follow. - O site seguido mantém uma lista moderada de seguidores públicos ou apenas contagem agregada. - A relação pode alimentar notificações, blogrolls automáticos e prova social leve. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `follower_url` | Campo essencial para representar `follower_url` no formato. | | `target_url` | Campo essencial para representar `target_url` no formato. | | `display_name` | Campo essencial para representar `display_name` no formato. | | `avatar` | Campo essencial para representar `avatar` no formato. | | `followed_at` | Campo essencial para representar `followed_at` no formato. | | `visibility` | Campo essencial para representar `visibility` no formato. | | `verified` | Campo essencial para representar `verified` no formato. | **Endpoints mínimos:** - `POST /follow` - `GET /followers.json` - `DELETE /follow/{id}` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-followers.schema.json`. ### MVP honesto - Botão “seguir este site”. - Lista moderada de seguidores. - Exportação JSON. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Notificações de novos posts. - Interoperabilidade com ActivityPub. - Listas de seguidores por comunidade. ### Por que daria certo - Prova social ajuda sites pequenos. - É menos pesado que rede social completa. - Pode ser opcional e respeitoso. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Serviço hospedado de seguidores/notificações para blogs, newsletters e comunidades. ### Riscos e mitigação O risco é virar métrica de vaidade. A mitigação é priorizar relacionamento e permitir ocultar contagem. --- ## 25. Microblog Feed > Microblog distribuído em JSON, publicável no próprio domínio. ### O que é Microblogs centralizados concentram identidade, audiência e histórico. A versão IndieWeb precisa ser simples: posts curtos no próprio domínio, lidos por qualquer cliente. ### Como funcionaria - O site publica `/microblog.json` ou um JSON Feed com notas curtas, respostas, reposts e favoritos. - Clientes leem múltiplos feeds e montam uma timeline local. - Publicação pode ocorrer via Micropub, com autenticação IndieAuth. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `id` | Campo essencial para representar `id` no formato. | | `content_text` | Campo essencial para representar `content_text` no formato. | | `content_html` | Campo essencial para representar `content_html` no formato. | | `url` | Campo essencial para representar `url` no formato. | | `published_at` | Campo essencial para representar `published_at` no formato. | | `in_reply_to` | Campo essencial para representar `in_reply_to` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `attachments` | Campo essencial para representar `attachments` no formato. | **Endpoints mínimos:** - `GET /microblog.json` - `POST /micropub` - `GET /api/timeline?following=...` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/microblog-feed.schema.json`. ### MVP honesto - Publicador de notas curtas. - Feed JSON público. - Leitor simples de múltiplos feeds. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Respostas via Webmention. - Compatibilidade ActivityPub. - Clientes móveis. ### Por que daria certo - Publicar nota curta é necessidade real. - Padrões já existem para postagem e resposta. - Pode começar como ferramenta pessoal antes de federar. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de microblog, clientes premium, backup, domínio customizado e ferramentas de migração. ### Riscos e mitigação O risco é tentar competir diretamente com redes gigantes. A mitigação é posicionar como posse de conteúdo e interoperabilidade, não como “novo Twitter”. --- ## 26. Quote Collection > Coleção pública e verificável de citações, trechos e referências. ### O que é Citações ficam espalhadas em notas, Kindle, posts e imagens. Muitas perdem fonte, página e contexto. Uma coleção estruturada cria memória intelectual portátil. ### Como funcionaria - O usuário publica `/quotes.json` com texto citado, autor, obra, página, contexto, tags e nota pessoal. - O sistema separa citação, comentário e referência bibliográfica. - A coleção pode alimentar commonplace books, páginas temáticas e mecanismos de busca. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `quote` | Campo essencial para representar `quote` no formato. | | `author` | Campo essencial para representar `author` no formato. | | `work` | Campo essencial para representar `work` no formato. | | `page` | Campo essencial para representar `page` no formato. | | `source_url` | Campo essencial para representar `source_url` no formato. | | `context` | Campo essencial para representar `context` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `note` | Campo essencial para representar `note` no formato. | | `created_at` | Campo essencial para representar `created_at` no formato. | **Endpoints mínimos:** - `GET /quotes.json` - `GET /api/quotes?tag=filosofia` - `POST /api/import/highlights` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/quote-collection.schema.json`. ### MVP honesto - Cadastro manual de citações. - Página pública por autor/tag. - Exportação Markdown/JSON. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Importação Kindle/Readwise. - Ligação com Public Library JSON. - Verificação de fonte e edição. ### Por que daria certo - Citações têm alto valor pessoal e editorial. - Estrutura evita perda de contexto. - Serve a leitores, pesquisadores e escritores. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização App de highlights, backup, publicação bonita, exportações acadêmicas e busca semântica. ### Riscos e mitigação O risco é direito autoral. A mitigação é limitar trechos, registrar fonte e permitir coleções privadas. --- ## 27. Public Notes Protocol > Protocolo simples para publicar notas públicas e sincronizáveis. ### O que é Notas pessoais viraram dependência de apps fechados. Quando o usuário quer publicar algumas notas, precisa adaptar manualmente para blog, wiki ou rede social. ### Como funcionaria - Notas públicas são expostas por uma API JSON com título opcional, corpo, tags, links, visibilidade e histórico. - Clientes podem criar/editar notas via API autenticada e publicar no domínio do usuário. - Leitores consomem notas como feed, grafo ou busca. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `id` | Campo essencial para representar `id` no formato. | | `title` | Título legível do item. | | `body` | Campo essencial para representar `body` no formato. | | `format` | Campo essencial para representar `format` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `links` | Campo essencial para representar `links` no formato. | | `visibility` | Campo essencial para representar `visibility` no formato. | | `created_at` | Campo essencial para representar `created_at` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /notes.json` - `GET /notes/{id}.json` - `POST /api/notes` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/public-notes-protocol.schema.json`. ### MVP honesto - API CRUD de notas. - Publicador web simples. - Exportação estática. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Sincronização multi-dispositivo. - Controle granular de privacidade. - Ponte com Micropub e Digital Garden Feed. ### Por que daria certo - Notas são matéria-prima de blogs, wikis e jardins. - JSON é natural para sincronização. - A utilidade pessoal existe antes da comunidade. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem, sync premium, busca, backup criptografado e publicação em domínio próprio. ### Riscos e mitigação O risco é competir com apps de notas maduros. A mitigação é focar em publicação aberta, não em substituir todo app privado. --- ## 28. Commonplace Book > Caderno público de ideias, citações, links e comentários. ### O que é Um commonplace book mistura leitura, pensamento e repertório. Hoje isso fica dividido entre notas privadas, favoritos, highlights e posts soltos. ### Como funcionaria - O usuário publica um `/commonplace.json` agregando citações, notas, links, temas e relações. - Cada entrada declara origem, tipo, comentário pessoal e conexões com outras entradas. - A interface permite navegar por temas, autores, obras e trilhas de pensamento. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `id` | Campo essencial para representar `id` no formato. | | `type` | Campo essencial para representar `type` no formato. | | `title` | Título legível do item. | | `content` | Campo essencial para representar `content` no formato. | | `source` | Campo essencial para representar `source` no formato. | | `commentary` | Campo essencial para representar `commentary` no formato. | | `topics` | Campo essencial para representar `topics` no formato. | | `related_items` | Campo essencial para representar `related_items` no formato. | | `created_at` | Campo essencial para representar `created_at` no formato. | **Endpoints mínimos:** - `GET /commonplace.json` - `GET /api/commonplace/topic/{topic}` - `POST /api/commonplace` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/commonplace-book.schema.json`. ### MVP honesto - Editor de entradas. - Página pública por tema. - Importação de quotes/bookmarks. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Grafo de ideias. - Exportação para livro/zine. - Busca semântica pessoal. ### Por que daria certo - Une vários projetos em uma experiência intelectual coerente. - Serve para escritores, pesquisadores e leitores sérios. - Tem valor acumulativo: melhora com o tempo. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Ferramenta premium para pesquisadores/criadores, publicação customizada, exportação editorial e templates. ### Riscos e mitigação O risco é virar depósito bagunçado. A mitigação é tipos claros de entrada e revisão periódica. --- ## 29. Knowledge Graph > Grafo pessoal de conhecimento em JSON-LD. ### O que é Notas, livros, projetos, pessoas e conceitos têm relações ricas, mas apps comuns escondem isso em pastas ou tags rasas. Um grafo pessoal torna conhecimento consultável. ### Como funcionaria - O usuário define nós e relações: pessoa, livro, conceito, projeto, citação, site, evento. - Os dados são publicados em JSON ou JSON-LD para compatibilidade com linked data. - Visualizadores e consultas permitem encontrar relações indiretas e trilhas de raciocínio. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `node_id` | Campo essencial para representar `node_id` no formato. | | `type` | Campo essencial para representar `type` no formato. | | `label` | Campo essencial para representar `label` no formato. | | `description` | Descrição curta para humanos. | | `url` | Campo essencial para representar `url` no formato. | | `relations` | Campo essencial para representar `relations` no formato. | | `sources` | Campo essencial para representar `sources` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /graph.json` - `GET /graph.jsonld` - `GET /api/graph/query` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/knowledge-graph.schema.json`. ### MVP honesto - Cadastro de nós e relações. - Visualizador básico. - Export JSON-LD. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Consultas semânticas. - Importação de notas e biblioteca. - Inferência leve de relações. ### Por que daria certo - É infraestrutura para pesquisa pessoal. - JSON-LD dá caminho real de interoperabilidade. - Valor cresce com cada novo nó. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Ferramenta paga para pesquisadores, estudantes, escritores e equipes pequenas; recursos premium de busca, visualização e importação. ### Riscos e mitigação O risco é complexidade ontológica. A mitigação é começar com poucos tipos e relações humanas, sem tentar modelar o universo inteiro. --- ## 30. Blog Neighbors > Descoberta de blogs parecidos por tags, links e leitura. ### O que é Seguir blogs é uma ação solitária; descobrir blogs parecidos com um que você já gosta é difícil. Buscadores não entendem vizinhança cultural. ### Como funcionaria - O sistema analisa tags, links de saída, blogrolls, feeds, idioma e tópicos dos posts. - Para cada blog, calcula vizinhos próximos por similaridade e relações explícitas. - A página “vizinhos” mostra sites que provavelmente interessam ao mesmo leitor. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `domain` | Campo essencial para representar `domain` no formato. | | `topics` | Campo essencial para representar `topics` no formato. | | `outlinks` | Campo essencial para representar `outlinks` no formato. | | `inlinks` | Campo essencial para representar `inlinks` no formato. | | `language` | Idioma principal. | | `similarity_score` | Campo essencial para representar `similarity_score` no formato. | | `reason` | Campo essencial para representar `reason` no formato. | **Endpoints mínimos:** - `GET /api/neighbors?domain=exemplo.com` - `POST /api/analyze-site` - `GET /neighbors.json` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/blog-neighbors.schema.json`. ### MVP honesto - Análise por tags e links. - Página de vizinhos para blogs cadastrados. - Explicação do motivo da recomendação. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Embeddings locais de conteúdo. - Vizinhanças por época/tema. - Widget “blogs parecidos”. ### Por que daria certo - Recomendação explicável gera confiança. - É útil para qualquer blog individual. - Pode reaproveitar dados do Blog Discovery Network. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Widgets para blogs, API de recomendação, diretórios de nicho e relatórios de ecossistema. ### Riscos e mitigação O risco é recomendar conteúdo ruim por similaridade superficial. A mitigação é combinar sinais automáticos com curadoria e feedback. --- ## 31. Indie Recommendations > Sistema de recomendações humanas em listas JSON. ### O que é Recomendação virou sinônimo de algoritmo opaco. Mas recomendações humanas, com motivo e contexto, são mais úteis em comunidades pequenas. ### Como funcionaria - Pessoas publicam listas `/recommendations.json` com sites, artigos, livros, ferramentas ou pessoas recomendadas. - Cada recomendação inclui motivo, categoria, público ideal e data. - Agregadores combinam listas e criam rankings transparentes por curadores, não por vigilância. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `item_url` | Campo essencial para representar `item_url` no formato. | | `item_type` | Campo essencial para representar `item_type` no formato. | | `title` | Título legível do item. | | `reason` | Campo essencial para representar `reason` no formato. | | `recommended_for` | Campo essencial para representar `recommended_for` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `recommended_at` | Campo essencial para representar `recommended_at` no formato. | | `curator` | Campo essencial para representar `curator` no formato. | **Endpoints mínimos:** - `GET /recommendations.json` - `POST /api/recommendations/import` - `GET /api/top?tag=...` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-recommendations.schema.json`. ### MVP honesto - Editor de listas de recomendação. - Diretório de recomendações públicas. - Ranking por tag. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Reputação de curadores. - Coleções colaborativas. - Integração com Article Recommendations e Blogroll. ### Por que daria certo - Motivo explícito é mais útil que score invisível. - Curadoria humana escala bem em nichos. - Pode gerar listas altamente compartilháveis. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Ferramentas para curadores/newsletters, páginas premium, patrocínio editorial e API de listas. ### Riscos e mitigação O risco é compra de recomendações escondida. A mitigação é campo obrigatório de disclosure e sinalização de patrocínio. --- ## 32. Site Identity Card > Cartão de identidade completo de um site. ### O que é Um site tem nome, dono, feeds, licença, descrição, idioma, políticas, chaves, endpoints e coleções. Hoje cada ferramenta tenta descobrir isso de forma frágil. ### Como funcionaria - O domínio publica `/identity.json` ou `/.well-known/site-identity.json`. - O cartão reúne dados de identidade, autoria, feeds, recursos, políticas e links sociais. - Ferramentas usam esse cartão para validar autoria, montar previews, descobrir APIs e verificar integridade. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `site_name` | Campo essencial para representar `site_name` no formato. | | `canonical_url` | Campo essencial para representar `canonical_url` no formato. | | `owner` | Campo essencial para representar `owner` no formato. | | `description` | Descrição curta para humanos. | | `language` | Idioma principal. | | `feeds` | Campo essencial para representar `feeds` no formato. | | `public_keys` | Campo essencial para representar `public_keys` no formato. | | `policies` | Campo essencial para representar `policies` no formato. | | `endpoints` | Campo essencial para representar `endpoints` no formato. | **Endpoints mínimos:** - `GET /.well-known/site-identity.json` - `GET /identity.json` - `POST /api/identity/validate` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/site-identity-card.schema.json`. ### MVP honesto - Esquema JSON. - Validador e badge. - Gerador de cartão visual. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Assinatura criptográfica. - Compatibilidade com Readme.json e Static Site Registry. - Verificação de domínio. ### Por que daria certo - Resolve descoberta técnica de forma simples. - Serve como base para vários projetos. - Um único arquivo já entrega utilidade. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Validação, monitoramento de identidade, badges confiáveis, consultoria para sites independentes e integrações. ### Riscos e mitigação O risco é sobreposição com outros manifestos. A mitigação é mapear campos existentes e manter foco em identidade do site, não configuração de app. --- ## 33. Blog Ping Network > Rede leve de pings para avisar que um site publicou algo novo. ### O que é RSS é ótimo, mas leitores nem sempre verificam rápido. Redes sociais entregam notificação, mas prendem distribuição. Um ping aberto avisa hubs e diretórios que há conteúdo novo. ### Como funcionaria - Ao publicar, o site envia um ping JSON para hubs escolhidos com URL, feed e timestamp. - O hub valida o feed, atualiza cache e notifica assinantes ou agregadores. - Pode funcionar junto com WebSub para entrega em tempo quase real. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `site_url` | URL canônica do site. | | `feed_url` | Campo essencial para representar `feed_url` no formato. | | `post_url` | Campo essencial para representar `post_url` no formato. | | `published_at` | Campo essencial para representar `published_at` no formato. | | `signature` | Campo essencial para representar `signature` no formato. | | `event_type` | Campo essencial para representar `event_type` no formato. | **Endpoints mínimos:** - `POST /ping` - `GET /api/pings/recent` - `GET /api/site/{domain}/updates` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/blog-ping-network.schema.json`. ### MVP honesto - Endpoint público de ping. - Validação de feed. - Dashboard de últimos pings. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Assinaturas por tag. - Rede federada de hubs. - Verificação por assinatura. ### Por que daria certo - Publicação precisa de distribuição. - É barato tecnicamente. - Complementa RSS/JSON Feed sem substituí-los. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hubs premium para comunidades, notificações, integrações com leitores e monitoramento de feeds. ### Riscos e mitigação O risco é abuso por spam de pings. A mitigação é validação de domínio, rate limit e confiança por histórico. --- ## 34. RSS-to-JSON Hub > Conversor e cache universal de feeds RSS/Atom para JSON. ### O que é RSS é aberto e poderoso, mas XML continua sendo barreira para muitos desenvolvedores. Um hub que normaliza feeds em JSON reduz atrito e facilita novos produtos. ### Como funcionaria - O serviço recebe uma URL RSS/Atom e converte para JSON Feed ou esquema próprio normalizado. - Mantém cache, valida erros, expõe metadados e oferece webhooks/pings de atualização. - Aplicações consomem feeds sem lidar com peculiaridades de XML. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `feed_url` | Campo essencial para representar `feed_url` no formato. | | `title` | Título legível do item. | | `home_page_url` | Campo essencial para representar `home_page_url` no formato. | | `items` | Campo essencial para representar `items` no formato. | | `authors` | Campo essencial para representar `authors` no formato. | | `language` | Idioma principal. | | `last_fetched` | Campo essencial para representar `last_fetched` no formato. | | `errors` | Campo essencial para representar `errors` no formato. | **Endpoints mínimos:** - `GET /convert?url=feed` - `GET /feeds/{hash}.json` - `POST /api/subscribe` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/rss-to-json-hub.schema.json`. ### MVP honesto - Conversor RSS/Atom para JSON. - Cache por URL. - Página de validação de feed. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - WebSub quando disponível. - API de normalização em lote. - SDKs para JS/Python. ### Por que daria certo - Desenvolvedores preferem JSON para protótipos modernos. - A base instalada de RSS é enorme. - O produto cria ponte, não tenta matar o padrão antigo. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização API por volume, cache premium, webhooks, monitoramento de feeds e planos para empresas/editoras. ### Riscos e mitigação O risco é custo de crawling/cache. A mitigação é cache agressivo, limites por plano e respeito a headers HTTP. --- ## 35. OPML Social > Camada social para troca e sincronização de listas OPML. ### O que é OPML é ótimo para exportar assinaturas de feeds, mas a troca entre pessoas é manual. Falta uma camada social leve para descobrir, comparar e sincronizar listas. ### Como funcionaria - Usuários publicam OPML e uma versão JSON normalizada com feeds, categorias e notas. - O sistema permite comparar listas, importar categorias e seguir atualizações de outra pessoa. - A pessoa mantém posse do arquivo; a rede apenas facilita troca e descoberta. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `owner` | Campo essencial para representar `owner` no formato. | | `feeds` | Campo essencial para representar `feeds` no formato. | | `categories` | Campo essencial para representar `categories` no formato. | | `feed_url` | Campo essencial para representar `feed_url` no formato. | | `html_url` | Campo essencial para representar `html_url` no formato. | | `notes` | Campo essencial para representar `notes` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /subscriptions.opml` - `GET /subscriptions.json` - `POST /api/opml/import` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/opml-social.schema.json`. ### MVP honesto - Importador/exportador OPML. - Perfil público de feeds. - Comparação entre duas listas. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Sincronização seletiva. - Recomendações de feeds por interseção. - Histórico de mudanças. ### Por que daria certo - OPML já tem adoção em leitores RSS. - Resolver troca social é uma camada pequena e valiosa. - Ajuda a reconstruir descoberta sem plataforma fechada. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Backup/sync de assinaturas, leitores premium, ferramentas para comunidades e API. ### Riscos e mitigação O risco é expor hábitos de leitura. A mitigação é privacidade por pasta, listas privadas e exportação local. --- ## 36. Indie Planet > Agregador comunitário moderno para blogs, notas, podcasts e zines. ### O que é Planets antigos agregavam blogs de uma comunidade, mas muitos ficaram visualmente datados e tecnicamente limitados. Comunidades atuais precisam de portais vivos, bonitos e fáceis. ### Como funcionaria - Uma comunidade define fontes: RSS, JSON Feed, microblogs, zines, podcasts e eventos. - O Indie Planet agrega, normaliza, categoriza e publica uma página comunitária. - Cada fonte continua no domínio original; o portal só aponta e organiza. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `community` | Campo essencial para representar `community` no formato. | | `sources` | Campo essencial para representar `sources` no formato. | | `source_type` | Campo essencial para representar `source_type` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `language` | Idioma principal. | | `moderation_status` | Campo essencial para representar `moderation_status` no formato. | | `last_item` | Campo essencial para representar `last_item` no formato. | **Endpoints mínimos:** - `GET /planet.json` - `POST /api/sources` - `GET /api/planet/feed` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-planet.schema.json`. ### MVP honesto - Cadastro de fontes. - Agregação cronológica. - Filtros por tipo e tag. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Edições semanais automáticas. - Moderação colaborativa. - Instâncias federadas de planets. ### Por que daria certo - Comunidades precisam de homepage coletiva. - Agregação aumenta tráfego para fontes originais. - Funciona com padrões existentes. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de planets para comunidades, temas premium, newsletters automáticas e patrocínios. ### Riscos e mitigação O risco é baixa qualidade no fluxo. A mitigação é curadoria, filtros por tag e destaque editorial. --- ## 37. Personal Hacker News > Página de links votados por uma comunidade pequena ou por uma pessoa. ### O que é Hacker News funciona para uma cultura específica, mas comunidades pequenas precisam de versões próprias, transparentes e portáveis, sem depender de plataforma central. ### Como funcionaria - Usuários submetem links com título, URL, comentário e tags. - Votos e comentários podem ser guardados em JSON e exportados. - Cada comunidade define regras de ranking, moderação e periodicidade. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `id` | Campo essencial para representar `id` no formato. | | `url` | Campo essencial para representar `url` no formato. | | `title` | Título legível do item. | | `submitted_by` | Campo essencial para representar `submitted_by` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `score` | Campo essencial para representar `score` no formato. | | `comments` | Campo essencial para representar `comments` no formato. | | `created_at` | Campo essencial para representar `created_at` no formato. | **Endpoints mínimos:** - `GET /links.json` - `POST /api/links` - `POST /api/links/{id}/vote` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/personal-hacker-news.schema.json`. ### MVP honesto - Submissão de links. - Ranking simples por votos e tempo. - Comentários locais ou via Webmention. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Instâncias pessoais. - Ranking transparente configurável. - Federação entre comunidades. ### Por que daria certo - Links compartilhados ainda são uma unidade social poderosa. - Pequenas comunidades conseguem manter qualidade. - A transparência do ranking é diferencial. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de comunidades, moderação, newsletters automáticas e instâncias privadas para equipes. ### Riscos e mitigação O risco é clone genérico sem comunidade. A mitigação é começar por nichos fortes e regras editoriais claras. --- ## 38. Micro Reviews > Mini resenhas portáveis de livros, filmes, ferramentas, lugares e sites. ### O que é Reviews estão presos em plataformas verticais: filmes num lugar, livros em outro, restaurantes em outro. A pessoa perde o controle do próprio gosto e histórico. ### Como funcionaria - O usuário publica `/reviews.json` com item, tipo, nota opcional, texto curto, data e link canônico. - Agregadores filtram por tipo: livro, filme, ferramenta, site, jogo, restaurante. - O mesmo review pode ser exibido no site pessoal e importado em diretórios. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `item_name` | Campo essencial para representar `item_name` no formato. | | `item_type` | Campo essencial para representar `item_type` no formato. | | `item_url` | Campo essencial para representar `item_url` no formato. | | `rating` | Campo essencial para representar `rating` no formato. | | `review_text` | Campo essencial para representar `review_text` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `reviewed_at` | Campo essencial para representar `reviewed_at` no formato. | | `author` | Campo essencial para representar `author` no formato. | **Endpoints mínimos:** - `GET /reviews.json` - `GET /api/reviews?type=book` - `POST /api/reviews` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/micro-reviews.schema.json`. ### MVP honesto - Editor de mini reviews. - Página pública por tipo. - Exportação JSON/JSON-LD. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Compatibilidade com schema.org Review. - Coleções temáticas. - Importação de Letterboxd/Goodreads/planilhas. ### Por que daria certo - Opiniões curtas são fáceis de produzir. - O histórico de gosto tem valor pessoal. - Schema estruturado favorece descoberta. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização App de reviews pessoais, páginas premium, importadores, backup e widgets para blogs. ### Riscos e mitigação O risco é virar agregador raso de estrelinhas. A mitigação é priorizar texto, contexto e “para quem recomendo”. --- ## 39. Museum of Personal Websites > Arquivo curado de sites pessoais como patrimônio cultural da web. ### O que é Sites pessoais somem com domínios expirados, hospedagens encerradas e mudanças de plataforma. A web perde memória estética, técnica e cultural. ### Como funcionaria - O museu cataloga sites pessoais com metadados, capturas, contexto, tecnologias e período ativo. - Quando permitido, armazena snapshots ou links para arquivos existentes. - A curadoria organiza exposições por época, estilo, comunidade e tecnologia. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `site_url` | URL canônica do site. | | `title` | Título legível do item. | | `creator` | Campo essencial para representar `creator` no formato. | | `period` | Campo essencial para representar `period` no formato. | | `description` | Descrição curta para humanos. | | `screenshots` | Campo essencial para representar `screenshots` no formato. | | `technologies` | Campo essencial para representar `technologies` no formato. | | `archive_url` | Campo essencial para representar `archive_url` no formato. | | `permission` | Campo essencial para representar `permission` no formato. | **Endpoints mínimos:** - `POST /api/submit-site` - `GET /museum.json` - `GET /api/exhibitions/{slug}` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/museum-of-personal-websites.schema.json`. ### MVP honesto - Catálogo manual curado. - Páginas de exposição. - Submissão com permissão. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Preservação de snapshots. - Exposições temáticas. - Parcerias com arquivos digitais. ### Por que daria certo - Há valor cultural real em preservar a web pessoal. - Nostalgia e pesquisa puxam interesse. - Curadoria humana diferencia de arquivo bruto. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Doações, patrocínio cultural, publicações, exposições digitais e serviços de preservação para criadores. ### Riscos e mitigação O risco é direitos autorais e privacidade. A mitigação é trabalhar com permissão, metadados e links quando não houver autorização para cópia. --- ## 40. Public Domain Directory > Diretório de obras em domínio público com metadados limpos e reutilizáveis. ### O que é Obras em domínio público existem em muitos arquivos, mas descoberta, metadados, traduções, formatos e direitos por país são confusos. ### Como funcionaria - O diretório cataloga obras, autores, datas, status de domínio público, formatos disponíveis e fontes confiáveis. - Cada obra tem JSON próprio com relações: autor, traduções, edições, adaptações e arquivos. - Usuários podem montar coleções temáticas e exportar listas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `work_title` | Campo essencial para representar `work_title` no formato. | | `creator` | Campo essencial para representar `creator` no formato. | | `year` | Campo essencial para representar `year` no formato. | | `country` | Campo essencial para representar `country` no formato. | | `public_domain_status` | Campo essencial para representar `public_domain_status` no formato. | | `formats` | Campo essencial para representar `formats` no formato. | | `source_url` | Campo essencial para representar `source_url` no formato. | | `license_notes` | Campo essencial para representar `license_notes` no formato. | **Endpoints mínimos:** - `GET /public-domain.json` - `GET /api/works/{id}` - `GET /api/works?creator=...` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/public-domain-directory.schema.json`. ### MVP honesto - Catálogo inicial curado. - Busca por autor/obra. - Links para fontes confiáveis. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Metadados multilíngues. - Coleções editoriais. - EPUBs gerados automaticamente. ### Por que daria certo - Domínio público tem valor educacional e editorial. - Metadados melhores resolvem dor real. - Pode gerar produtos derivados legais e úteis. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Edições digitais premium, newsletters, APIs para apps educacionais e curadoria para escolas/bibliotecas. ### Riscos e mitigação O risco é erro jurídico por país. A mitigação é tratar status como metadado informativo, registrar jurisdição e citar fontes. --- ## 41. IndieMap > Mapa geográfico opt-in de sites, pessoas, eventos e comunidades independentes. ### O que é A web independente parece sem lugar. Mas pessoas, encontros, projetos e comunidades têm geografia. Um mapa opt-in cria descoberta local sem expor localização sensível. ### Como funcionaria - Participantes publicam localização aproximada em GeoJSON ou escolhem cidade/região manualmente. - O mapa mostra sites, eventos, comunidades, bibliotecas e zines por região. - A precisão é controlada pelo usuário: país, estado, cidade ou coordenada aproximada. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `name` | Campo essencial para representar `name` no formato. | | `url` | Campo essencial para representar `url` no formato. | | `type` | Campo essencial para representar `type` no formato. | | `geo` | Campo essencial para representar `geo` no formato. | | `location_label` | Campo essencial para representar `location_label` no formato. | | `precision` | Campo essencial para representar `precision` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /map.geojson` - `POST /api/map/submit` - `GET /api/map?bbox=...` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indiemap.schema.json`. ### MVP honesto - Mapa com submissão manual. - GeoJSON público. - Filtros por tipo e tag. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Camadas temáticas. - Eventos próximos. - Mapas comunitários embutíveis. ### Por que daria certo - Descoberta local cria relações reais. - GeoJSON é padrão maduro para mapas. - Privacidade pode ser preservada com precisão baixa. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Mapas para comunidades, eventos, diretórios locais, instâncias privadas e patrocínio regional. ### Riscos e mitigação O risco é privacidade física. A mitigação é nunca exigir endereço exato e usar aproximação como padrão. --- ## 42. Human Directory > Diretório de pessoas com identidade própria, interesses e formas de contato. ### O que é Diretórios de pessoas viram redes sociais ou bancos de currículos. A proposta é um diretório humano, opt-in, baseado em domínio próprio e intenção explícita. ### Como funcionaria - Cada pessoa publica perfil via Readme.json, h-card ou formulário. - O diretório indexa interesses, projetos, localização aproximada, disponibilidade e links. - Busca prioriza contexto humano: “pessoas que escrevem sobre cinema”, “pesquisadores de história”, “devs IndieWeb no Brasil”. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `name` | Campo essencial para representar `name` no formato. | | `url` | Campo essencial para representar `url` no formato. | | `bio` | Campo essencial para representar `bio` no formato. | | `interests` | Campo essencial para representar `interests` no formato. | | `projects` | Campo essencial para representar `projects` no formato. | | `location_label` | Campo essencial para representar `location_label` no formato. | | `contact` | Campo essencial para representar `contact` no formato. | | `availability` | Campo essencial para representar `availability` no formato. | **Endpoints mínimos:** - `GET /humans.json` - `POST /api/people/submit` - `GET /api/people?interest=...` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/human-directory.schema.json`. ### MVP honesto - Perfis opt-in. - Busca por interesse e idioma. - Página pública individual. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Verificação por domínio. - Matching de colaboração. - Exportação de listas. ### Por que daria certo - Pessoas querem ser encontradas fora de redes fechadas. - Domínio próprio reduz dependência de plataforma. - Busca por interesse é mais útil que seguidores. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Planos profissionais, comunidades privadas, diretórios de especialistas e ferramentas de contato qualificado. ### Riscos e mitigação O risco é virar spam/recrutamento invasivo. A mitigação é opt-in, contato controlado e moderação forte. --- ## 43. Personal APIs > APIs pessoais padronizadas para dados públicos escolhidos pelo indivíduo. ### O que é Pessoas geram muitos dados úteis: livros, projetos, posts, links, eventos, presença, habilidades. Mas não há uma forma comum de expor isso como API sob controle do indivíduo. ### Como funcionaria - O domínio publica um índice `/api.json` ou OpenAPI descrevendo endpoints pessoais disponíveis. - Cada endpoint aponta para coleções públicas: posts, livros, projetos, now, uses, skills. - Aplicações descobrem automaticamente o que podem consumir. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `owner` | Campo essencial para representar `owner` no formato. | | `base_url` | Campo essencial para representar `base_url` no formato. | | `endpoints` | Campo essencial para representar `endpoints` no formato. | | `schemas` | Campo essencial para representar `schemas` no formato. | | `auth` | Campo essencial para representar `auth` no formato. | | `rate_limits` | Campo essencial para representar `rate_limits` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /api.json` - `GET /.well-known/personal-api` - `GET /openapi.json` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/personal-apis.schema.json`. ### MVP honesto - Manifesto de API pessoal. - Endpoints estáticos para 3 coleções. - Documentação automática. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - OpenAPI completo. - Autenticação para dados privados. - SDKs e integração com apps pessoais. ### Por que daria certo - APIs são linguagem natural de integração. - Começa simples com arquivos estáticos. - Pode unificar vários projetos da lista. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Hospedagem de API pessoal, geração de OpenAPI, analytics, autenticação e integrações premium. ### Riscos e mitigação O risco é expor dados demais. A mitigação é público por padrão apenas para coleções explícitas e escopos claros para dados privados. --- ## 44. Indie Resume > Currículo portátil, versionado e publicável em domínio próprio. ### O que é Currículos ficam em PDFs desatualizados, LinkedIn ou páginas difíceis de reaproveitar. Um currículo em JSON permite múltiplas renderizações e atualização centralizada. ### Como funcionaria - O usuário mantém `resume.json` baseado em JSON Resume ou esquema compatível. - O site gera versões HTML, PDF, texto curto e perfil público. - Verificações podem apontar para projetos, organizações, certificados e referências. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `basics` | Campo essencial para representar `basics` no formato. | | `work` | Campo essencial para representar `work` no formato. | | `education` | Campo essencial para representar `education` no formato. | | `skills` | Campo essencial para representar `skills` no formato. | | `projects` | Campo essencial para representar `projects` no formato. | | `certificates` | Campo essencial para representar `certificates` no formato. | | `languages` | Campo essencial para representar `languages` no formato. | | `references` | Campo essencial para representar `references` no formato. | **Endpoints mínimos:** - `GET /resume.json` - `GET /resume.pdf` - `POST /api/resume/validate` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-resume.schema.json`. ### MVP honesto - Editor de currículo JSON. - Tema HTML bonito. - Exportação PDF. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Histórico de versões. - Verificação de experiências. - Perfis diferentes por objetivo. ### Por que daria certo - JSON Resume já oferece base de adoção. - Profissionais precisam de portabilidade. - Domínio próprio fortalece identidade. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Editor premium, temas, hospedagem, analytics de visualização, versões personalizadas e revisão profissional. ### Riscos e mitigação O risco é competir com LinkedIn sem rede. A mitigação é vender portabilidade e apresentação, não substituir networking. --- ## 45. Skills Registry > Registro estruturado de habilidades, níveis, evidências e disponibilidade. ### O que é Listar habilidades como palavras soltas é quase inútil. Falta contexto: nível, prova, projeto relacionado, interesse atual e disponibilidade para colaborar. ### Como funcionaria - Pessoas publicam `/skills.json` com habilidades, níveis, evidências, projetos e intenção: aprendendo, praticando, ensinando ou contratado. - Diretórios permitem encontrar pessoas por habilidade verificável e contexto. - Cada habilidade aponta para evidência pública, como projeto, artigo, certificado ou repositório. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `skill` | Campo essencial para representar `skill` no formato. | | `level` | Campo essencial para representar `level` no formato. | | `evidence_url` | Campo essencial para representar `evidence_url` no formato. | | `context` | Campo essencial para representar `context` no formato. | | `years_optional` | Campo essencial para representar `years_optional` no formato. | | `status` | Campo essencial para representar `status` no formato. | | `available_for` | Campo essencial para representar `available_for` no formato. | **Endpoints mínimos:** - `GET /skills.json` - `GET /api/skills?name=python` - `POST /api/skills/validate` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/skills-registry.schema.json`. ### MVP honesto - Editor de skills. - Perfil público com evidências. - Busca por habilidade. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Matching de colaboração. - Endossos verificáveis. - Integração com Indie Resume. ### Por que daria certo - Habilidade com evidência é muito mais útil que tag. - Serve para contratação, comunidades e aprendizado. - É pequeno o suficiente para começar rápido. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Diretórios profissionais, matching, perfis premium e ferramentas para comunidades educacionais. ### Riscos e mitigação O risco é autoavaliação inflada. A mitigação é exigir evidências e permitir níveis simples, não métricas falsas de precisão. --- ## 46. Open Collections > Coleções pessoais de qualquer coisa, publicadas em JSON. ### O que é Pessoas colecionam livros, filmes, discos, objetos, links, lugares, receitas e referências. Plataformas verticais não dão conta de coleções híbridas. ### Como funcionaria - O usuário cria coleções com esquema flexível: itens, campos customizados, imagens, tags, notas e links. - Cada coleção pode ser exportada como `/collections/{slug}.json`. - Diretórios ou widgets exibem coleções públicas e permitem remixar listas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `collection_id` | Campo essencial para representar `collection_id` no formato. | | `title` | Título legível do item. | | `description` | Descrição curta para humanos. | | `items` | Campo essencial para representar `items` no formato. | | `item_fields` | Campo essencial para representar `item_fields` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `visibility` | Campo essencial para representar `visibility` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /collections.json` - `GET /collections/{slug}.json` - `POST /api/collections` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/open-collections.schema.json`. ### MVP honesto - Criador de coleção sem código. - Página pública por coleção. - Export JSON/CSV. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Templates de coleção. - Federação de coleções similares. - Colaboração e submissões externas. ### Por que daria certo - Colecionar é comportamento humano universal. - O formato flexível evita prender em um nicho. - Pode alimentar zines, bibliotecas, reviews e diretórios. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização SaaS de coleções, templates premium, domínio próprio, backups e vitrines públicas. ### Riscos e mitigação O risco é flexibilidade demais virar bagunça. A mitigação é oferecer templates fortes e campos recomendados por tipo. --- ## 47. Webrings 2.0 > Webrings inteligentes por tags, reputação e contexto. ### O que é Webring tradicional é linear demais. A evolução é permitir anéis dinâmicos por tema, idioma, maturidade, frequência e relação real entre sites. ### Como funcionaria - Sites declaram tags, temas e anéis desejados em manifesto JSON. - O sistema agrupa automaticamente candidatos, mas curadores aprovam membros. - A navegação pode ser `next`, `previous`, `random`, “parecido” ou “surpreenda-me”. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `site_url` | URL canônica do site. | | `rings` | Campo essencial para representar `rings` no formato. | | `tags` | Tópicos usados para busca, filtros e descoberta. | | `language` | Idioma principal. | | `curator` | Campo essencial para representar `curator` no formato. | | `trust_score` | Campo essencial para representar `trust_score` no formato. | | `navigation_modes` | Campo essencial para representar `navigation_modes` no formato. | **Endpoints mínimos:** - `GET /webrings.json` - `GET /api/rings/suggest` - `GET /api/rings/{id}/navigate` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/webrings-20.schema.json`. ### MVP honesto - Anéis por tag. - Widget com navegação randômica. - Painel de curadoria. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Sugestão automática de membros. - Anéis temporários para eventos. - Reputação por participação. ### Por que daria certo - Combina nostalgia com utilidade moderna. - Curadoria evita ruído. - É uma camada social leve e divertida. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Comunidades pagas, personalização de widgets, páginas premium de anéis e patrocínio de coleções editoriais. ### Riscos e mitigação O risco é automação destruir qualidade. A mitigação é manter aprovação humana e explicar critérios de entrada. --- ## 48. Murad Library Protocol > Protocolo para bibliotecas pessoais federadas, empréstimos e descoberta. ### O que é Bibliotecas pessoais são tesouros privados. O problema é permitir descoberta, empréstimo e recomendação sem centralizar tudo em uma plataforma literária. ### Como funcionaria - Cada pessoa publica catálogo em `/murad-library.json` ou extensão de Public Library JSON. - Itens têm disponibilidade, condição, política de empréstimo, localização aproximada e formas de contato. - Nós federados podem buscar livros entre bibliotecas autorizadas. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `book_id` | Campo essencial para representar `book_id` no formato. | | `title` | Título legível do item. | | `author` | Campo essencial para representar `author` no formato. | | `isbn` | Campo essencial para representar `isbn` no formato. | | `owner` | Campo essencial para representar `owner` no formato. | | `availability` | Campo essencial para representar `availability` no formato. | | `lending_policy` | Campo essencial para representar `lending_policy` no formato. | | `location_scope` | Campo essencial para representar `location_scope` no formato. | | `contact_url` | Campo essencial para representar `contact_url` no formato. | **Endpoints mínimos:** - `GET /murad-library.json` - `GET /api/libraries/search?book=...` - `POST /api/lending/request` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/murad-library-protocol.schema.json`. ### MVP honesto - Catálogo pessoal com status de empréstimo. - Busca entre bibliotecas opt-in. - Solicitação manual por contato. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Rede federada de bibliotecas. - Histórico de empréstimos privado. - Clubes de troca locais. ### Por que daria certo - Biblioteca pessoal tem valor social subutilizado. - Empréstimo local cria relação real. - Começa como catálogo e evolui para rede. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Ferramentas para clubes, bibliotecas comunitárias, inventário doméstico, etiquetas e instâncias privadas. ### Riscos e mitigação O risco é logística e confiança. A mitigação é começar com grupos fechados e empréstimo manual, não marketplace aberto. --- ## 49. Indie Universe Graph > Mapa geral das conexões entre pessoas, sites, feeds, projetos e comunidades. ### O que é Cada projeto IndieWeb gera um pedaço do grafo: blogrolls, follows, links, eventos, bibliotecas, recomendações. Falta uma visão agregada do universo independente. ### Como funcionaria - O sistema coleta dados opt-in de manifestos, feeds, links e protocolos da lista. - Cria um grafo com nós de pessoas, sites, obras, eventos, projetos e comunidades. - Consultas revelam clusters, pontes, hubs, temas emergentes e rotas de descoberta. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `node_id` | Campo essencial para representar `node_id` no formato. | | `node_type` | Campo essencial para representar `node_type` no formato. | | `label` | Campo essencial para representar `label` no formato. | | `url` | Campo essencial para representar `url` no formato. | | `edges` | Campo essencial para representar `edges` no formato. | | `source` | Campo essencial para representar `source` no formato. | | `confidence` | Campo essencial para representar `confidence` no formato. | | `updated_at` | Data da última atualização. | **Endpoints mínimos:** - `GET /universe.graph.json` - `GET /api/universe/query` - `GET /api/universe/path?from=&to=` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/indie-universe-graph.schema.json`. ### MVP honesto - Grafo de sites e links. - Visualização por clusters. - Export JSON. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Múltiplos tipos de nós. - Análise temporal. - APIs para pesquisa e visualização. ### Por que daria certo - É o projeto síntese: usa dados dos demais. - Grafo gera insights que diretório simples não mostra. - Pode virar infraestrutura de descoberta e pesquisa. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização API de grafo, relatórios de ecossistema, instâncias privadas, visualizações premium e pesquisa patrocinada. ### Riscos e mitigação O risco é virar vigilância social. A mitigação é opt-in, transparência, exclusão fácil e foco em dados públicos intencionais. --- ## 50. Fedizine Protocol > Federação de zines com edições, assinaturas e exportação automática. ### O que é Zines digitais precisam de distribuição, arquivo, assinatura e formatos portáveis. Publicar PDF solto não cria rede; marketplace fechado remove independência. ### Como funcionaria - Cada zine publica um feed de edições em `/fedizine.json`. - Leitores e diretórios assinam zines, descobrem novas edições e baixam formatos disponíveis. - Instâncias podem federar catálogos, mantendo cada zine em seu domínio. ### Implementação prática A implementação deve começar como **arquivo estático público** antes de virar plataforma. Esse é o ponto mais importante: se o projeto exige uma rede inteira para ser útil, ele nasce fraco. Se um único site já consegue publicar o JSON, validar e exibir uma página, o projeto tem chance. **Campos JSON mínimos:** | Campo | Função | | --- | --- | | `zine_id` | Campo essencial para representar `zine_id` no formato. | | `title` | Título legível do item. | | `creator` | Campo essencial para representar `creator` no formato. | | `issues` | Campo essencial para representar `issues` no formato. | | `issue_number` | Campo essencial para representar `issue_number` no formato. | | `formats` | Campo essencial para representar `formats` no formato. | | `license` | Campo essencial para representar `license` no formato. | | `published_at` | Campo essencial para representar `published_at` no formato. | | `subscribe_url` | Campo essencial para representar `subscribe_url` no formato. | **Endpoints mínimos:** - `GET /fedizine.json` - `GET /api/zines/federated` - `POST /api/zines/subscribe` **Stack recomendada para MVP:** - Front-end: Astro, Next.js ou HTML estático com JavaScript leve. - Back-end: Node.js/Fastify, Python/FastAPI ou Go, dependendo da preferência. - Banco inicial: SQLite ou PostgreSQL. - Busca: SQLite FTS, Meilisearch ou Typesense quando o volume crescer. - Validação: JSON Schema versionado em `/schema/fedizine-protocol.schema.json`. ### MVP honesto - Feed de edições. - Página de zine e edição. - Exportação manual PDF/EPUB. O MVP não deve tentar resolver federação, reputação, autenticação avançada e monetização ao mesmo tempo. Primeiro precisa provar que o formato é legível, útil e fácil de publicar. ### Evolução do produto - Geração automática de EPUB/PDF. - Federação entre diretórios. - Assinaturas e clubes de zine. ### Por que daria certo - Zines combinam perfeitamente com independência e distribuição aberta. - Feed por edição resolve acompanhamento. - Formatos portáveis preservam o conteúdo. A condição de sucesso é clara: o projeto precisa gerar valor **antes** de ter massa crítica. A massa crítica deve melhorar o produto, não ser requisito para ele funcionar. ### Modelo de adoção e monetização Ferramentas de publicação, assinaturas, venda direta, hospedagem e diretórios temáticos. ### Riscos e mitigação O risco é fragmentação de formatos. A mitigação é definir núcleo mínimo e aceitar extensões opcionais. --- ## Roadmap geral de 12 meses | Fase | Período | Entrega principal | Critério de sucesso | | --- | --- | --- | --- | | 1 | Mês 1 | Esquemas JSON, manifesto base e validadores | 5 formatos publicáveis em site estático | | 2 | Meses 2–3 | Blogroll, Readme, Site Identity e Static Registry | 50 sites cadastrados manualmente | | 3 | Meses 4–5 | Discovery Network e RSS-to-JSON Hub | Busca funcional e feeds normalizados | | 4 | Meses 6–7 | Library, Reading, Bookmarks, Recommendations | Primeiras coleções pessoais reais | | 5 | Meses 8–9 | Comments, Followers, Microblog e Ping Network | Interações entre domínios funcionando | | 6 | Meses 10–12 | Indie Universe Graph, IndieMap e Fedizine | Ecossistema navegável e demonstrável | ## O que não fazer - Não começar tentando criar login, timeline, app móvel, federação e marketplace ao mesmo tempo. - Não obrigar usuário a abandonar RSS, OPML, ActivityPub, Webmention, JSON Feed, JSON Resume ou Microformats. - Não criar formato novo quando um padrão existente resolver 80% do problema. - Não vender “descentralização” como estética. O benefício concreto é posse, portabilidade, durabilidade e independência. - Não depender de viralização. IndieWeb cresce por utilidade acumulada, não por explosão artificial. ## Núcleo comercial realista Os projetos mais monetizáveis no curto prazo são: 1. **RSS-to-JSON Hub**, porque API resolve dor técnica clara. 2. **Indie Analytics**, porque sites pequenos pagam por ferramenta simples. 3. **Public Library JSON / Murad Library Protocol**, porque biblioteca pessoal tem valor emocional e utilitário. 4. **Indie Resume / Skills Registry**, porque identidade profissional tem valor econômico direto. 5. **Open Collections**, porque colecionadores e criadores aceitam pagar por organização e publicação bonita. 6. **Indie Planet**, porque comunidades precisam de portais e podem bancar hospedagem. Os projetos mais estratégicos, mesmo que monetizem menos no início, são: 1. **Site Identity Card** 2. **Readme.json** 3. **Static Site Registry** 4. **Blog Discovery Network** 5. **Indie Universe Graph** Esses são infraestrutura. Eles aumentam o valor dos outros. ## Referências técnicas As ideias deste documento dialogam com padrões e práticas já existentes na web aberta: - [IndieWeb Principles](https://indieweb.org/principles) - [Own Your Data — IndieWeb](https://indieweb.org/own_your_data) - [JSON Feed](https://www.jsonfeed.org/) - [Webmention — W3C Recommendation](https://www.w3.org/TR/webmention/) - [ActivityPub — W3C Recommendation](https://www.w3.org/TR/activitypub/) - [WebSub — W3C Recommendation](https://www.w3.org/TR/websub/) - [Micropub — W3C Recommendation](https://www.w3.org/TR/micropub/) - [IndieAuth](https://indieauth.net/) - [Microformats h-entry](https://microformats.org/wiki/h-entry) - [OPML 2.0](https://opml.org/spec2.opml) - [JSON Resume Schema](https://www.jsonresume.org/schema) - [JSON-LD 1.1 — W3C](https://www.w3.org/TR/json-ld11/) - [WebFinger — RFC 7033](https://www.rfc-editor.org/info/rfc7033/) - [GeoJSON — RFC 7946](https://datatracker.ietf.org/doc/html/rfc7946) - [OpenAPI Specification](https://www.openapis.org/) - [Schema.org](https://schema.org/) ## Conclusão A força dessas cinquenta ideias não está em cada projeto isolado. Está no conjunto. Um `blogroll.json` melhora descoberta. Um `readme.json` melhora identidade. Um `site.json` melhora indexação. Um `library.json` melhora curadoria. Um `universe.graph.json` transforma tudo em mapa. A estratégia correta é construir peças pequenas, públicas, úteis e cumulativas. A web independente não precisa de uma plataforma salvadora. Precisa de protocolos simples, ferramentas bonitas e motivos concretos para pessoas publicarem dados nos próprios domínios. O caminho é menos “criar uma rede social” e mais “criar instrumentos para a web voltar a conversar consigo mesma”.