Murad Terminal: uma BBS elegante e centrada

Uma proposta simples, bonita e viável para um site-terminal com alma de BBS, sem nostalgia vazia nem excesso de arquitetura.

Projeto: Murad Terminal / site-BBS / arquivo textual interativo
Versão inicial: 22 de junho de 2026

1. A decisão principal

O projeto não deve ser “uma BBS genérica instalada em um servidor”.

Também não deve ser “um site comum fingindo ser terminal”.

A forma mais elegante é esta:

Um sistema editorial em terminal, com alma de BBS, acessível por Web, SSH e Telnet.

Ou seja:

Web para qualquer pessoa acessar sem fricção.
SSH para a experiência terminal moderna, segura e bonita.
Telnet como modo público retrô, sem dados sensíveis.
Markdown como fonte editorial.
ANSI/ASCII como pele estética.
SQLite como memória dinâmica.
Go como núcleo do sistema.

A BBS, aqui, não é o protocolo.
A BBS é o ritual: entrar, explorar, ler, deixar uma marca, descobrir arquivos, navegar por menus, sentir que existe uma comunidade/arquivo vivo do outro lado.

2. Frase-guia do projeto

Web para alcance. Terminal para ritual. Markdown para preservação. ANSI para alma.

Essa frase deve guiar quase todas as decisões.

Quando surgir uma dúvida técnica, pergunte:

isso melhora o alcance?
isso melhora o ritual?
isso preserva melhor o conteúdo?
isso fortalece a estética?
ou é só vaidade técnica?

Se for só vaidade técnica, corte.

3. O que o Murad Terminal deve ser

O Murad Terminal deve ser um lugar para:

publicar zines;
organizar textos;
apresentar bibliotecas;
exibir arte ASCII/ANSI;
manter um guestbook;
guardar logs de laboratório;
criar uma experiência de leitura alternativa;
dar ao visitante a sensação de acessar um arquivo vivo;
servir como porta lateral para projetos maiores: Murad Library, Murad Press, dlore, QEL, Biblioteca Arcana etc.

O projeto deve parecer menos um “site” e mais um nó textual.

Exemplo de abertura:

╔════════════════════════════════════════════════════╗
║                  MURAD TERMINAL                   ║
║              TEXTMODE ARCHIVE NODE                ║
╚════════════════════════════════════════════════════╝

NODE:   SAO-PAULO / ARCHIVE
MODE:   PUBLIC
STATUS: ONLINE

[1] Biblioteca
[2] Zines
[3] Logs
[4] ANSI/ASCII
[5] Guestbook
[6] Sobre
[7] Ajuda
[0] Sair

murad@terminal:~$

4. O que ele não deve ser

O projeto não deve virar:

rede social;
fórum gigante;
clone de Reddit;
shell Linux público;
sistema de upload anônimo;
chat aberto sem moderação;
plataforma de login complexa;
“mais uma BBS pronta” com seu nome colado em cima;
brinquedo técnico sem conteúdo.

A armadilha é clara: gastar 90% do tempo criando infraestrutura e 10% criando experiência.

Tem que ser o contrário.

5. Arquitetura conceitual

A arquitetura mais limpa é separar o projeto em cinco camadas:

┌────────────────────────────────────────────┐
│  Entrada                                   │
│  Web Terminal / SSH / Telnet               │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│  Sessão                                    │
│  estado, usuário, caminho atual, tamanho   │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│  Motor de Comandos                         │
│  help, ls, open, search, back, random      │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│  Motor Editorial                           │
│  Markdown, índice, zines, biblioteca       │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│  Armazenamento                             │
│  arquivos + SQLite                         │
└────────────────────────────────────────────┘

O núcleo não deve se importar se o visitante veio por Web, SSH ou Telnet.

Ele recebe:

input do usuário

e devolve:

saída textual/ANSI

Essa separação evita criar três sistemas diferentes.

6. Stack escolhida

A stack mais elegante e centrada para uma versão autoral é:

Go
Wish
Bubble Tea opcional
xterm.js
SQLite
Markdown + frontmatter
Caddy ou Nginx
Docker

Por que Go?

Porque Go é uma ótima escolha para esse tipo de projeto:

gera binário único;
é simples de fazer deploy;
lida bem com rede;
roda bem em VPS pequena;
tem boa concorrência;
não força uma arquitetura complexa;
fica mais limpo que Python quando o projeto amadurece.

Python seria excelente para protótipo rápido.
Rust seria excelente para obsessão técnica.
Go é o melhor meio-termo para produto pequeno, elegante e público.

Por que Wish?

Porque ele permite criar aplicações acessíveis por SSH. O visitante pode conectar com:

ssh guest@terminal.seudominio.com -p 2222

e cair direto no Murad Terminal, sem shell real do servidor.

Wish também se integra com Bubble Tea, caso você queira interfaces TUI mais sofisticadas no futuro.

Por que xterm.js?

Porque permite colocar um terminal de verdade dentro do navegador.

Assim, uma pessoa comum pode entrar por:

https://terminal.seudominio.com

sem instalar nada.

Por que SQLite?

Porque o sistema dinâmico inicial é pequeno.

SQLite basta para:

guestbook;
logs;
sessões;
visitas;
mensagens aprovadas;
pequenos registros internos.

PostgreSQL só faria sentido depois, se o projeto crescer de verdade. Antes disso é peso morto.

7. Três portas de entrada

7.1 Web: a porta principal

A maioria das pessoas deve entrar pela Web.

https://terminal.seudominio.com

A página inicial deve ter:

botão “Entrar no terminal”;
instruções para SSH;
instruções para Telnet;
versão HTML dos zines;
explicação curta do projeto;
screenshots;
links de download.

A Web é a vitrine.
O terminal é o ritual.

7.2 SSH: a porta nobre

A experiência mais bonita para usuário técnico deve ser SSH:

ssh guest@terminal.seudominio.com -p 2222

O usuário guest não deve abrir shell.
Ele deve cair direto no app.

Nada de:

/bin/bash

Nada de shell real.
Nada de comandos do sistema.

A sessão SSH deve ser apenas uma interface para o Murad Terminal.

7.3 Telnet: a porta retrô

Telnet deve existir, mas com limites:

telnet terminal.seudominio.com 2323

Regras:

sem senha real;
sem login sensível;
sem dados privados;
sem shell;
sem upload;
sem administração;
apenas leitura, exploração e talvez guestbook moderado.

Telnet é estética e homenagem.
SSH é operação segura.
Web é alcance.

8. Modelo de conteúdo

O conteúdo deve viver em arquivos, não no banco.

Estrutura recomendada:

content/
  about.md
  help.md

  zines/
    murad-press-001/
      index.md
      terminal.md
      zine.pdf
      cover.txt
      meta.yaml

    terminal-notes-001/
      index.md
      terminal.md
      meta.yaml

  biblioteca/
    historia/
      index.md
      textos/

    tecnologia/
      index.md
      textos/

    cinema/
      index.md
      textos/

    saude-mental/
      index.md
      textos/

  logs/
    2026-06-22-primeiro-node.md

  manifestos/
    manifesto-do-terminal.md

  ansi/
    gallery.md

Regra:

Markdown é fonte. TXT/ANSI/HTML/PDF são exportações.

Isso evita bagunça. Se cada formato virar “fonte”, o projeto morre em inconsistência.

9. Frontmatter para tudo

Cada texto importante deve ter metadados.

Exemplo:

---
title: "Manifesto do Terminal"
slug: "manifesto-do-terminal"
section: "manifestos"
date: "2026-06-22"
status: "published"
tags: ["terminal", "bbs", "arquivo", "zine"]
terminal_width: 80
---

Isso permite gerar:

índice;
busca;
página HTML;
tela terminal;
RSS;
listagens por tag;
zines em PDF;
exportações futuras.

10. O banco de dados

O banco guarda apenas o que muda.

SQLite inicial:

guestbook (
  id INTEGER PRIMARY KEY,
  nick TEXT NOT NULL,
  message TEXT NOT NULL,
  approved INTEGER DEFAULT 0,
  created_at TEXT NOT NULL
);

sessions (
  id TEXT PRIMARY KEY,
  ip_hash TEXT,
  entrypoint TEXT,
  started_at TEXT,
  last_seen TEXT
);

events (
  id INTEGER PRIMARY KEY,
  event_type TEXT NOT NULL,
  metadata TEXT,
  created_at TEXT NOT NULL
);

Não coloque artigo, zine e manifesto no banco no começo.
Isso é erro clássico.

Conteúdo editorial precisa ser versionado com Git.

11. Navegação

O terminal deve aceitar dois modos ao mesmo tempo:

Menu numérico

Para visitante casual:

[1] Biblioteca
[2] Zines
[3] Logs
[4] Guestbook
[0] Sair

Comandos

Para visitante curioso:

help
map
ls
cd zines
open 001
back
home
search bbs
random
guestbook
about
clear
exit

O erro seria escolher só um.

Menu puro fica bobo.
Comando puro assusta usuário comum.
Híbrido é o caminho certo.

12. Comandos mínimos

Essenciais

help        mostra ajuda
map         mostra mapa do terminal
ls          lista itens da seção atual
cd          entra em seção
open        abre item
back        volta
home        volta ao início
search      busca textos
random      abre item aleatório
about       explica o projeto
clear       limpa tela
exit        encerra sessão

De charme

fortune     mostra frase/fragmento aleatório
whoami      mostra identidade da sessão
now         mostra horário do node
motd        mensagem do dia
guestbook   abre livro de visitas
nfo         mostra informações do sistema/projeto

Easter eggs

invoke qel
sudo open arcana
hack reality
open blackbox

Easter egg bom é tempero.
Easter egg demais vira adolescente demais.

13. Experiência de leitura

O leitor de textos precisa ser simples e confortável.

Comandos durante leitura:

n       próxima página
p       página anterior
q       sair
h       ajuda
/       buscar dentro do texto
g       ir para início
G       ir para fim

Cada página deve mostrar:

Título
Seção
Página atual
Comandos básicos

Exemplo:

┌──────────────────────────────────────────────────────┐
│ Murad Press #001                                     │
│ O Manifesto do Arquivo                               │
└──────────────────────────────────────────────────────┘

Todo arquivo é uma conversa com o futuro.

A web moderna ficou lisa demais: rápida, rastreável,
otimizada, previsível. O terminal exige presença.

[p 1/4] [n] next  [p] prev  [q] quit

Nada de linhas com 140 caracteres.
Terminal bom respeita largura.

Largura recomendada:

80 a 100 colunas

14. Estética visual

A estética deve ser:

BBS + terminal Unix + zine + arquivo oculto + laboratório textual

Mas com controle.

Paleta ANSI

Use pouco:

Ciano       comandos e links
Amarelo     destaques
Cinza       texto normal
Branco      títulos
Verde       status OK
Vermelho    erros/alertas
Magenta     áreas especiais

Regra dura

Se tudo brilha, nada importa.

ANSI demais fica carnavalesco e cansa.

Tela boa

╔════════════════════════════════════════════════════╗
║                  MURAD TERMINAL                   ║
╚════════════════════════════════════════════════════╝

Tela ruim

╔═══▒▓█☠☠☠ CYBER OCCULT HACKER BBS 3000 ☠☠☠█▓▒═══╗

A segunda parece paródia. Use com cuidado.

15. Identidade editorial

O terminal precisa ter voz própria.

Não precisa fingir que é hacker anos 1990.
Isso seria cosplay.

A voz ideal:

precisa;
literária sem ser ilegível;
técnica sem ser pedante;
misteriosa sem virar fanfic ruim;
direta;
com humor seco ocasional.

Exemplo:

[SYS] Este arquivo ainda está incompleto.
[SYS] Arquivos incompletos também dizem alguma coisa.

Ou:

[WARN] Nada encontrado. Ou você procurou mal, ou o arquivo está mentindo.

Isso é muito melhor do que “access granted” repetido como clichê.

16. Seções principais

16.1 Biblioteca

Arquivo organizado de textos.

/biblioteca
  historia
  tecnologia
  cinema
  saude-mental
  ocultismo
  literatura

16.2 Zines

Publicações numeradas e fechadas.

/zines
  murad-press-001
  terminal-notes-001
  arcana-brief-001

Zine precisa ter edição, capa, sumário e fechamento.
Se for só “um monte de post”, não é zine.

16.3 Logs

Notas curtas de laboratório.

/logs
  2026-06-22-primeiro-node
  2026-06-23-parser-markdown

Logs podem ser mais crus.
Eles dão sensação de arquivo vivo.

16.4 ANSI/ASCII

Galeria visual.

/ansi
  logos
  banners
  dividers
  experiments

16.5 Guestbook

Livro de visitas.

Campos:

nick;
mensagem;
data;
status aprovado/não aprovado.

Precisa de moderação.

Guestbook sem moderação vira lixão de bot.

17. Arquitetura técnica concreta

murad-terminal/
  cmd/
    terminald/
      main.go

  internal/
    app/
      app.go
      session.go
      router.go

    adapters/
      ssh/
      telnet/
      websocket/

    content/
      loader.go
      indexer.go
      markdown.go
      search.go

    render/
      ansi.go
      pager.go
      menu.go
      wrap.go

    storage/
      sqlite.go
      guestbook.go
      events.go

  content/
    about.md
    help.md
    zines/
    biblioteca/
    logs/
    manifestos/

  ansi/
    welcome.ans
    main-menu.ans
    goodbye.ans

  web/
    index.html
    terminal.html
    assets/

  data/
    terminal.db

  Dockerfile
  docker-compose.yml
  README.md

18. Fluxo interno de uma sessão

conexão aberta
   ↓
cria Session
   ↓
detecta entrada: web / ssh / telnet
   ↓
mostra welcome.ans
   ↓
mostra menu principal
   ↓
recebe comando
   ↓
Router interpreta
   ↓
Content Engine busca conteúdo
   ↓
Renderer formata saída
   ↓
Adapter envia ao usuário
   ↓
repete até exit/timeout

19. Web terminal

A página web não precisa ser cheia de coisa.

Ela deve ter:

MURAD TERMINAL
[Entrar pelo navegador]

Também disponível via:
ssh guest@terminal.seudominio.com -p 2222
telnet terminal.seudominio.com 2323

Ao clicar, abre o xterm.js.

Fluxo:

Browser
  ↓
xterm.js
  ↓
WebSocket
  ↓
murad-terminal core

Não exponha shell real via navegador.
O navegador fala com o app, não com /bin/bash.

20. Deploy recomendado

VPS simples com Debian.

Portas:

443   HTTPS / Web terminal
2222  SSH público do app
2323  Telnet público do app

Evite porta 23 para Telnet.
Ela atrai ruído automático de bot.

Caddy/Nginx

Use Caddy ou Nginx para:

TLS;
proxy WebSocket;
servir site estático;
servir downloads;
aplicar rate limit se necessário.

Docker

Rode o app isolado.

container:
  usuário sem root
  filesystem read-only quando possível
  volume para content/
  volume para data/

O app nunca deve ter permissão ampla no servidor.

21. Segurança

Regras sem romantismo:

Telnet não tem senha real.
SSH público não abre shell.
Web terminal não abre shell.
Guestbook tem moderação.
Nada de upload público no começo.
Nada de comandos do sistema.
Nada de executar código do usuário.
Nada de painel admin dentro do Telnet.
Logs sem armazenar IP cru, se possível use hash.
Timeout de sessão inativa.
Limite de conexões por IP.
App rodando como usuário sem privilégio.
Backup do SQLite e do conteúdo.

A estética pode ser hacker.
A operação não pode ser amadora.

22. MVP realmente elegante

A primeira versão boa não precisa ter mil coisas.

Ela precisa ter poucas coisas muito bem resolvidas.

v0.1

Web landing page.
Terminal no navegador.
SSH guest.
Telnet público em 2323.
Tela inicial ANSI.
Menu principal.
help, map, ls, open, back, home, random, exit.
Leitor de Markdown paginado.
Seção /zines.
Seção /biblioteca.
Seção /about.
Logs básicos.
Docker.
Conteúdo versionado em Git.

v0.2

Guestbook moderado.
Busca simples.
Comando fortune.
RSS/Atom.
Galeria ANSI.
Exportação HTML estática dos textos.

v0.3

Geração de PDF/EPUB dos zines.
Painel admin separado, fora do terminal público.
Tags.
Índice por autor/tema.
Página web pública para cada zine.
Modo “read-only archive”.

v1.0

Identidade visual consolidada.
3 a 5 zines reais publicados.
Biblioteca inicial organizada.
Guestbook funcionando.
Terminal estável.
Backups.
Documentação pública.
Página “como acessar”.

23. A métrica de sucesso

Não meça pelo número de features.

Meça por perguntas melhores:

Uma pessoa entende o que é em 30 segundos?
Ela consegue ler algo sem se perder?
A tela inicial dá vontade de explorar?
O terminal funciona bem em navegador?
O SSH funciona bem para usuário técnico?
O Telnet funciona sem colocar nada em risco?
O conteúdo tem valor real?
O projeto parece autoral ou parece template?
Dá vontade de voltar?

Se a resposta for sim, está funcionando.

24. O erro que mataria o projeto

O erro mais provável seria este:

tentar criar uma BBS completa antes de criar um arquivo interessante.

Não faça isso.

Crie primeiro:

uma entrada bonita;
um menu claro;
10 textos bons;
1 zine fechado;
1 guestbook simples;
1 estética consistente.

Depois expanda.

Sem conteúdo, a stack é só decoração.

25. Versão curta da arquitetura ideal

                   ┌──────────────────────┐
                   │ terminal.seudominio  │
                   └──────────┬───────────┘
                              │
             ┌────────────────┼────────────────┐
             │                │                │
             ▼                ▼                ▼
        Web/xterm.js      SSH/Wish        Telnet/2323
             │                │                │
             └────────────────┼────────────────┘
                              ▼
                    Murad Terminal Core
                              │
          ┌───────────────────┼───────────────────┐
          ▼                   ▼                   ▼
      Markdown            SQLite              ANSI/TXT
      conteúdo            dinâmico            estética

26. Recomendação final

A versão mais elegante e centrada é:

Go como núcleo
Wish para SSH
xterm.js para Web
Telnet em 2323 como modo retrô
Markdown como fonte editorial
SQLite para dados dinâmicos
ANSI/ASCII como linguagem visual
Docker + Caddy/Nginx para deploy

Mas a prioridade real não é a stack.

A prioridade é o conceito:

Murad Terminal é um arquivo vivo em modo texto. Uma biblioteca-zine acessível por terminal. Uma BBS sem a gordura de BBS. Um lugar para ler, explorar e deixar vestígios.

Essa é a forma mais forte.

Não tente competir com web moderna.
Use o terminal justamente porque ele faz outra coisa: ele desacelera, dá textura, cria presença e transforma leitura em exploração.

27. Referências técnicas úteis

Wish: https://github.com/charmbracelet/wish
Bubble Tea: https://github.com/charmbracelet/bubbletea
xterm.js: https://xtermjs.org/
xterm.js GitHub: https://github.com/xtermjs/xterm.js/
Textual: https://textual.textualize.io/
Ratatui: https://ratatui.rs/
16colo.rs: https://16colo.rs/
Moebius ANSI editor: https://blocktronics.github.io/moebius/
PabloDraw: https://github.com/cwensley/pablodraw