Murad Library
RESEARCH#md

RESEARCH

Soledade — Ideia Refinada

soledade-ideia-refinada.md

research·#MD·soledade-ideia-refinada.md
Date
Reading
10 min read

Soledade — Ideia Refinada

Resumo

O Soledade é uma ideia forte quando tratado como um projeto pessoal, hacker, literário e técnico: um blog textual minimalista, feito para navegador e terminal, inspirado em sistemas como Nightfall, Nex, NPS, Gemini, Gopher e a web antiga.

A proposta central não deve ser competir com WordPress, Medium, Substack, Hugo ou qualquer plataforma moderna. O valor do Soledade está justamente no oposto: ser pequeno, direto, controlável, textual e quase artesanal.

A melhor definição é:

Soledade é uma casa textual para navegador e terminal.

Ou, de forma ainda mais objetiva:

Um blog estático com alma de protocolo antigo.

A ideia vale ser construída, mas precisa de disciplina. Se virar plataforma, rede social, sistema multiusuário ou CMS completo, morre pela própria ambição.

Diagnóstico honesto

O Soledade é uma boa ideia como:

  • blog pessoal;
  • experimento de internet textual;
  • ferramenta de publicação via terminal;
  • projeto de aprendizado;
  • manifesto contra a web inchada;
  • espaço autoral de escrita e permanência.

O Soledade é uma má ideia como:

  • plataforma pública multiusuário;
  • substituto de WordPress;
  • rede social textual;
  • protocolo alternativo ambicioso;
  • serviço aberto para qualquer pessoa postar;
  • produto SaaS genérico.

A força do projeto está no limite. Quanto menor, melhor.

O núcleo da ideia

O Soledade deve ter três faces:

HTTPS / navegador     -> leitura pública comum
TCP porta 1900        -> leitura textual via terminal
publicação segura     -> envio de posts por terminal

A arquitetura ideal é:

Markdown -> gerador estático -> HTML público
Markdown -> servidor textual -> leitura por terminal
cliente CLI -> publicação -> rebuild do site

A fonte da verdade deve ser o diretório de arquivos Markdown. Nada de banco de dados na primeira versão. Nada de painel administrativo. Nada de editor visual.

O projeto deve preservar esta filosofia:

pequeno > grande
texto > interface inchada
arquivo > banco desnecessário
terminal > painel pesado
clareza > framework da moda

O que deve permanecer

A ideia original tem bons fundamentos. Eu manteria:

  1. Markdown como formato principal
    Simples, editável, portátil e fácil de versionar.

  2. Geração estática de HTML
    Mais seguro, mais rápido e mais barato do que renderização dinâmica.

  3. Acesso pelo navegador
    O site precisa continuar sendo acessível por qualquer pessoa, sem cliente especial.

  4. Leitura por terminal
    Esse é o diferencial estético e técnico do projeto.

  5. Controle total do servidor
    O Soledade deve ser uma ferramenta própria, não uma dependência de plataforma.

  6. Ausência de banco de dados na versão inicial
    Banco só entra quando existe necessidade real. No MVP, não existe.

  7. Ausência de painel web
    O painel web mataria parte da identidade do projeto.

O que deve mudar

A versão original é boa, mas eu refinaria alguns pontos.

1. Usar Caddy no MVP

Para a primeira versão, Caddy é mais adequado que nginx.

Motivo simples: HTTPS automático, configuração menor e menos chance de erro operacional. nginx é excelente, mas exige mais etapas com Certbot, renovação e configuração manual.

Para o Soledade, a prioridade deve ser publicar texto, não cuidar de certificado.

A configuração inicial poderia ser apenas:

blog.seudominio.com {
    root * /opt/soledade/public
    file_server
}

Depois, se houver necessidade, nginx pode entrar.

2. Não abrir a porta de publicação para o mundo

A porta de leitura textual, como a 1900, pode ficar pública.

A porta de publicação, como a 1915, não deve ficar aberta globalmente sem proteção forte.

Publicação é administração remota. Deve ser tratada como área sensível.

O ideal é uma destas opções:

1. publicar via SSH/git;
2. restringir a porta 1915 ao IP do autor;
3. usar túnel SSH;
4. usar VPN;
5. usar HMAC com timestamp se insistir no TCP público.

A opção mais sensata para começar:

publicação via SSH/git
leitura textual via TCP público

Isso preserva a estética sem abrir uma superfície de ataque desnecessária.

3. Separar poesia técnica de administração real

O protocolo textual de leitura é bonito, simples e relativamente seguro.

O protocolo textual de postagem é charmoso, mas perigoso se for implementado de forma ingênua.

Portanto, a estratégia correta é:

Primeiro: site estático funcionando.
Depois: leitura textual por terminal.
Depois: cliente CLI.
Por último: publicação estilo NPS, se ainda fizer sentido.

Não comece pela parte mais arriscada.

4. Gerar RSS desde cedo

RSS combina perfeitamente com o Soledade.

Se o projeto é sobre permanência, texto e autonomia, RSS é mais importante do que tags, busca ou tema visual avançado.

A primeira versão deveria gerar:

/feed.xml
/sitemap.xml

RSS é uma ponte entre a web tradicional e a web textual. É simples, útil e coerente.

5. Manter multiusuário fora do escopo

Multiusuário parece tentador, mas é uma armadilha.

No momento em que o Soledade aceita múltiplos autores, aparecem problemas que não fazem parte da ideia principal:

  • cadastro;
  • recuperação de senha;
  • permissões;
  • moderação;
  • spam;
  • abuso;
  • quota por usuário;
  • sanitização de HTML;
  • logs individuais;
  • banimento;
  • política de conteúdo;
  • backup por usuário.

Isso não é mais um blog textual. Isso vira uma plataforma. E plataforma demais vira cemitério de manutenção.

Posicionamento correto

O Soledade não deve ser apresentado como apenas mais um gerador de blog.

Geradores de blog já existem aos montes.

O posicionamento forte é:

Uma casa textual para navegador e terminal.

Ou:

Um blog estático com alma de protocolo antigo.

Ou:

Publicação pessoal para quem prefere arquivo, terminal e silêncio.

Esse posicionamento diferencia o projeto sem prometer demais.

Arquitetura recomendada

A arquitetura refinada seria:

/opt/soledade/
├── content/
│   ├── index.md
│   ├── about.md
│   └── posts/
├── public/
│   ├── index.html
│   ├── feed.xml
│   └── sitemap.xml
├── soledade/
│   ├── build.py
│   ├── read_server.py
│   ├── cli.py
│   └── config.py
├── templates/
│   └── base.html
├── logs/
└── venv/

Na primeira versão, eu removeria post_server.py ou deixaria como experimental.

A publicação inicial poderia ser:

scp meu-post.md servidor:/opt/soledade/content/posts/
ssh servidor 'cd /opt/soledade/soledade && ../venv/bin/python build.py'

Depois isso vira um comando:

soledade publish posts/meu-post.md meu-post.md

Por baixo, o comando pode usar SSH. O usuário sente que está publicando pelo terminal, mas a segurança fica mais razoável.

Roadmap recomendado

Fase 1 — Blog estático

Objetivo: colocar o site no ar.

Entregas:

  • estrutura de diretórios;
  • posts em Markdown;
  • gerador HTML;
  • template simples;
  • Caddy com HTTPS;
  • /feed.xml;
  • /sitemap.xml.

Critério de sucesso:

Escrever um Markdown, rodar o build e ver o post no navegador.

Fase 2 — Leitura textual

Objetivo: permitir leitura por terminal.

Entregas:

  • servidor TCP na porta 1900;
  • leitura de arquivos Markdown;
  • listagem de diretórios;
  • proteção contra path traversal;
  • systemd para manter o serviço vivo.

Critério de sucesso:

printf "index.md\n" | nc blog.seudominio.com 1900

Fase 3 — Cliente CLI

Objetivo: melhorar a experiência de uso.

Entregas:

  • comando soledade read;
  • comando soledade publish;
  • configuração local com domínio e caminho do servidor;
  • publicação usando SSH por baixo.

Exemplo:

soledade read posts/noite.md
soledade publish posts/noite.md noite.md

Critério de sucesso:

Publicar e ler sem decorar comandos longos.

Fase 4 — Publicação textual opcional

Objetivo: testar o protocolo estilo NPS.

Entregas:

  • porta 1915;
  • token forte;
  • limite de payload;
  • validação rígida de caminho;
  • allowlist de IP;
  • logs;
  • Fail2Ban;
  • rebuild automático.

Critério de sucesso:

Publicar via TCP sem expor o servidor a riscos idiotas.

Essa fase é opcional. O projeto não depende dela para ser bom.

Fase 5 — Refinamentos

Objetivo: tornar o projeto agradável sem inflar.

Possíveis melhorias:

  • tags simples;
  • página de arquivo;
  • busca local com JSON estático;
  • modo .gmi para Gemini;
  • tema visual alternativo;
  • página /now;
  • backups automáticos;
  • comando de status;
  • importador de posts antigos.

Cuidado: cada melhoria deve passar por uma pergunta dura:

Isso fortalece a ideia central ou só adiciona manutenção?

Se só adiciona manutenção, corte.

Segurança mínima obrigatória

Se existir qualquer tipo de publicação remota, estes pontos não são opcionais:

  1. Token forte ou SSH
    Nada de senha curta. Nada de segredo previsível.

  2. Validação de caminho
    Nunca aceitar caminho livre do usuário sem resolver e conferir se está dentro de content/.

  3. Bloqueio de .. e caminhos absolutos
    Path traversal é o erro clássico.

  4. Limite de tamanho de postagem
    Evita abuso simples e consumo desnecessário de memória.

  5. Logs
    Sem logs, você está cego.

  6. Firewall
    A porta de publicação não deve ficar exposta para qualquer IP.

  7. Backups
    O conteúdo é o projeto. Perder content/ é perder a casa.

  8. Nada de multiusuário no começo
    Multiusuário é outro produto.

MVP ideal

A versão mínima que eu construiria é esta:

Caddy
Markdown
build.py
HTML estático
RSS
sitemap
porta 1900 para leitura
publicação via SSH
systemd para o leitor textual
backup diário

Sem painel. Sem banco. Sem login. Sem comentários. Sem multiusuário. Sem API pública.

Depois de isso estar sólido, você decide se a porta 1915 merece existir.

O que não fazer

Não faça estas coisas no começo:

  • painel administrativo web;
  • autenticação multiusuário;
  • editor Markdown no navegador;
  • sistema de comentários;
  • likes;
  • seguidores;
  • analytics pesado;
  • banco de dados;
  • Docker obrigatório;
  • tema complexo;
  • plugin system;
  • marketplace de templates;
  • integração social automática.

Essas coisas parecem evolução, mas são distração.

O Soledade deve ser uma ferramenta de escrita e leitura, não uma fábrica de dívida técnica.

Manifesto prático

O Soledade deve existir porque a web ficou pesada demais.

Ele não tenta vencer a internet moderna. Ele escolhe sair do jogo.

O projeto deve defender:

menos interface
mais texto
menos plataforma
mais arquivo
menos feed
mais permanência
menos algoritmo
mais intenção
menos painel
mais terminal

Essa é a parte bonita da ideia.

Mas beleza sem disciplina vira bagunça.

Por isso, a regra central deve ser:

Tudo que não serve ao texto, ao acesso simples ou à autonomia deve ficar fora.

Conclusão

O Soledade vale ser construído.

Mas ele deve nascer pequeno, pessoal e funcional.

A versão correta não é uma plataforma alternativa da internet. A versão correta é uma ferramenta autoral para publicar texto com controle, calma e permanência.

O caminho mais inteligente é:

1. blog estático sólido;
2. RSS e sitemap;
3. leitura textual por terminal;
4. cliente CLI;
5. publicação remota segura;
6. protocolo de postagem apenas se ainda fizer sentido.

O Soledade tem personalidade. Isso é raro.

Agora a parte difícil é não estragar essa personalidade com ambição demais.

Related documents

Soledade — Ideia Refinada · Murad Library