--- title: "Murad Terminal: uma BBS elegante e centrada" date: 2026-06-22 summary: Arquitetura autoral e viável para um arquivo textual interativo com alma de BBS, acessível pela web, SSH e Telnet. tags: [terminal, bbs, arquitetura, indieweb, zine, go, ansi, markdown] flowerColor: "#63d6c5" --- # 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: ```text ╔════════════════════════════════════════════════════╗ ║ 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: ```text ┌────────────────────────────────────────────┐ │ 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: ```text input do usuário ``` e devolve: ```text 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 é: ```text 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: ```bash 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: ```text 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. ```text 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: ```bash ssh guest@terminal.seudominio.com -p 2222 ``` O usuário `guest` não deve abrir shell. Ele deve cair direto no app. Nada de: ```bash /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: ```bash 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: ```text 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: ```yaml --- 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: ```sql 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: ```text [1] Biblioteca [2] Zines [3] Logs [4] Guestbook [0] Sair ``` ### Comandos Para visitante curioso: ```text 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 ```text 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 ```text 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 ```text 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: ```text 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: ```text Título Seção Página atual Comandos básicos ``` Exemplo: ```text ┌──────────────────────────────────────────────────────┐ │ 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: ```text 80 a 100 colunas ``` --- ## 14. Estética visual A estética deve ser: ```text BBS + terminal Unix + zine + arquivo oculto + laboratório textual ``` Mas com controle. ### Paleta ANSI Use pouco: ```text 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 ```text ╔════════════════════════════════════════════════════╗ ║ MURAD TERMINAL ║ ╚════════════════════════════════════════════════════╝ ``` ### Tela ruim ```text ╔═══▒▓█☠☠☠ 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: ```text [SYS] Este arquivo ainda está incompleto. [SYS] Arquivos incompletos também dizem alguma coisa. ``` Ou: ```text [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. ```text /biblioteca historia tecnologia cinema saude-mental ocultismo literatura ``` ### 16.2 Zines Publicações numeradas e fechadas. ```text /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. ```text /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. ```text /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 ```text 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 ```text 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: ```text 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: ```text 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: ```text 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. ```text 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 ```text ┌──────────────────────┐ │ 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 é: ```text 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