Moon Flower Society > 50 Projetos IndieWeb Baseados em JSON — Versão Completa

50 Projetos IndieWeb Baseados em JSON — Versão Completa

Expansão completa das cinquenta ideias IndieWeb de Pablo Murad, com funcionamento, implementação, MVP, evolução, riscos, monetização e viabilidade.

Posted June 21, 2026. Markdown. Tags: indieweb, json, small-web, protocolos, produto, pablo-murad.

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:

{
  "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:

Site Identity Card
Readme.json
Static Site Registry
RSS-to-JSON Hub
Blog Discovery Network
Blogroll JSON
Follow List JSON
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

RSS-to-JSON Hub, porque API resolve dor técnica clara.
Indie Analytics, porque sites pequenos pagam por ferramenta simples.
Public Library JSON / Murad Library Protocol, porque biblioteca pessoal tem valor emocional e utilitário.
Indie Resume / Skills Registry, porque identidade profissional tem valor econômico direto.
Open Collections, porque colecionadores e criadores aceitam pagar por organização e publicação bonita.
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:

Site Identity Card
Readme.json
Static Site Registry
Blog Discovery Network
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:

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”.