Murad Library
Info
Murad LibraryREF-0368MD

Antes da Web Lisa: Internet doméstica, BBS, Telnet e a vontade de voltar ao terminal

Catalogued
Reading
15 min read

Há uma diferença enorme entre “a internet existir” e “a internet chegar na casa das pessoas”.

Essa diferença parece pequena quando a gente olha de longe, como se a história da rede fosse uma sequência limpa de datas: ARPANET, TCP/IP, web, provedores, banda larga, smartphones. Mas, para quem viveu a transição dos anos 1990, a coisa nunca foi tão organizada. A internet não chegou como uma entidade pronta. Ela entrou aos poucos, em pedaços: primeiro como notícia de revista, depois como CD encartado, depois como modem chiando, depois como provedor discado, depois como e-mail, depois como navegador, depois como vício cotidiano.

Antes de ser infraestrutura invisível, a internet era um acontecimento.

Hoje a rede é tão banal que parece eletricidade. Está lá. Liga, autentica, sincroniza, notifica, atualiza, rastreia, salva, vende, recomenda. Nos anos 1990, entrar “online” era uma ação física. Tinha som, custo, espera, risco de alguém tirar o telefone do gancho e uma sensação absurda de passagem. Você não estava apenas abrindo uma página. Você estava indo para algum lugar.

Essa conversa começou justamente nesse território: quando o Brasil começou a ter internet residencial, como isso se comparava aos Estados Unidos, o que eram BBS, por que Telnet não é telefone, como arquivos eram transferidos antes da web, por que existiam zines executáveis, e como seria possível recriar hoje um site com alma de BBS.

No fim, a pergunta deixou de ser técnica e virou outra coisa:

o que perdemos quando a internet ficou fácil demais?

Quando a internet chegou em casa

No Brasil, a data mais honesta para falar de internet aberta ao público é 1995.

Antes disso, já havia redes acadêmicas, centros de pesquisa, conexões institucionais e experimentos. A internet não nasceu no Brasil em 1995 como mágica. Ela já vinha sendo montada nos bastidores, principalmente em ambientes científicos e universitários. A RNP, por exemplo, teve papel central nessa fase de transição, e a própria história da rede brasileira mostra esse movimento entre pesquisa, infraestrutura e abertura comercial.

Mas para o usuário comum — a pessoa com computador em casa, modem, linha telefônica e vontade de entrar nesse mundo estranho — 1995 é o marco.

Foi o momento em que a internet começou a deixar de ser coisa de universidade e laboratório para virar produto, serviço, assinatura, provedor, revista, kit de acesso, tutorial e conversa de entusiasta. O Comitê Gestor da Internet no Brasil, o CGI.br, foi criado em 31 de maio de 1995, num momento em que o país precisava organizar a governança e a expansão da rede.

Nos Estados Unidos, a abertura popular aconteceu um pouco antes, mas não tanto quanto às vezes se imagina. A ARPANET e outras redes já existiam havia décadas, mas isso não significa que o cidadão comum usava internet em casa desde os anos 1970. A internet doméstica americana começa a ganhar forma no início dos anos 1990 e se consolida entre 1993 e 1995, com provedores comerciais, serviços online, navegadores e a retirada gradual das restrições ligadas à antiga infraestrutura acadêmica.

O encerramento da NSFNET em 1995 simboliza bem essa virada: a rede acadêmica que ajudou a estruturar a internet americana dava lugar a uma internet comercial mais ampla.

Então, em termos práticos:

  • nos Estados Unidos, o acesso popular começou a se espalhar por volta de 1993/1994;
  • no Brasil, a internet comercial e doméstica começou a ganhar forma em 1995;
  • a massificação real, nos dois casos, veio depois, principalmente entre o fim dos anos 1990 e os anos 2000.

A diferença existia, mas não era um abismo de décadas. Era mais uma defasagem de chegada, infraestrutura, custo e mercado.

No Brasil, isso vinha com um sabor muito específico: revistas de informática, CDs-ROM encartados, provedores locais, tutoriais impressos, disquetes, bancas de jornal, programas compartilhados, patches que vinham na edição seguinte, e a sensação de que baixar qualquer coisa grande era quase ficção científica.

Hoje um arquivo de 100 MB é uma distração. Naquele tempo, 100 MB era um compromisso moral.

Antes da internet doméstica, havia as BBS

Antes da web virar o centro da vida digital, muita gente já “entrava online” por outro caminho: as BBS, ou Bulletin Board Systems.

Uma BBS era, grosso modo, um computador esperando ligações. Você usava um PC com modem, discava para o número telefônico da BBS e, quando a conexão fechava, entrava em um sistema textual com menus, mensagens, arquivos, jogos, áreas de discussão e, às vezes, chat.

Não era a web. Não era internet no sentido doméstico moderno. Era uma rede social artesanal antes das redes sociais, um fórum antes dos fóruns, um repositório antes do GitHub, um clube antes do Discord.

A primeira BBS pública por discagem, a CBBS, apareceu em Chicago em 1978, criada por Ward Christensen e Randy Suess. A ideia era simples e poderosa: permitir que entusiastas de computador trocassem mensagens e informações usando modem e linha telefônica. A partir dali, o modelo se espalhou.

Nos anos 1980 e no começo dos anos 1990, BBS virou uma cultura própria. No Brasil, isso ganhou força especialmente no início e meados dos anos 1990, antes da internet comercial virar comum. Quem tinha modem acessava BBS para baixar arquivos, ler mensagens, participar de fóruns, jogar doors, trocar programas, acompanhar discussões técnicas e fazer parte de comunidades locais.

E “local” aqui importa muito.

Como ligação telefônica custava caro — especialmente interurbano — as BBS eram muito mais regionais. Você ligava para uma BBS da sua cidade ou região, porque ficar horas conectado a uma BBS de outro estado podia destruir a conta telefônica. Isso criava uma internet pré-internet com sotaque local.

A BBS tinha sysop, regras, reputação, áreas fechadas, uploads, downloads, ratio, mensagens privadas, arte ANSI, arquivos .DIZ, telas de boas-vindas, listas de usuários, rankings e aquela mistura deliciosa de informática séria com adolescência digital.

Era lenta, limitada e viva.

A casa, a porta e o protocolo

Uma confusão comum é achar que BBS é sinônimo de Telnet.

Não é.

BBS é o sistema, a casa, a comunidade, o ambiente.

Telnet é uma das portas.

Historicamente, a BBS original nem usava Telnet. O usuário discava diretamente para o modem da BBS. Era:

computador do usuário
  ↓
modem
  ↓
linha telefônica
  ↓
modem da BBS
  ↓
software BBS

Com a popularização da internet, muitas BBS passaram a aceitar acesso por Telnet:

usuário
  ↓
internet
  ↓
telnet
  ↓
software BBS

Mais tarde, BBS modernas começaram a aceitar SSH, WebSocket e até acesso via navegador. Isso não torna a BBS “menos BBS”. Apenas muda o meio de entrada.

A analogia mais simples é:

BBS = a casa
modem = a porta original
Telnet = uma porta velha sem fechadura
SSH = uma porta moderna com fechadura
Web = uma janela pelo navegador

Telnet é um protocolo de terminal remoto. A especificação RFC 854 define o Telnet como uma forma geral, bidirecional e orientada a bytes para conectar terminais e processos remotos. Ele não é telefone. Ele roda sobre rede, normalmente TCP/IP. A associação com telefone vem da época: muitas pessoas acessavam redes usando modem e linha telefônica, mas Telnet em si não discava para ninguém.

A linha telefônica era o caminho físico.

Telnet era o idioma usado depois que você já estava em uma rede.

Transferir arquivos quando tudo era instável

Em BBS, baixar arquivo não era simplesmente clicar em um link.

Você escolhia um arquivo, selecionava um protocolo de transferência e torcia para a conexão não cair. Foi aí que entraram nomes como XMODEM, YMODEM e ZMODEM.

Esses protocolos existiam porque transferir arquivos por modem era frágil. A linha podia ter ruído, a conexão podia cair, o arquivo podia corromper. Então os protocolos dividiam o arquivo em blocos, conferiam se cada parte chegou corretamente e retransmitiam quando algo dava errado.

O XMODEM era simples e antigo. Funcionava, mas era lento e limitado.

O YMODEM melhorou a ideia, permitindo blocos maiores, nome de arquivo automático e envio em lote.

O ZMODEM virou o preferido de muita gente porque era mais rápido, mais robusto e permitia retomar downloads interrompidos. Isso era enorme. Se a conexão caísse no meio de um arquivo grande, você não precisava começar do zero.

Hoje isso parece banal. Na época, era civilização.

ASCII, ANSI e a estética do terminal

BBS não era só texto cru. Havia uma estética.

ASCII era o básico: letras, símbolos, molduras, logos feitos com caracteres. ANSI ia além: cores, posicionamento, telas de abertura, menus coloridos, sombras, caixas, arte textmode. Era uma forma de design gráfico feita dentro das limitações do terminal.

A tela de uma BBS podia ser só um menu simples:

[1] Mensagens
[2] Arquivos
[3] Jogos
[4] Chat
[0] Sair

Mas também podia ser uma pequena obra em ANSI, com logo, bordas, cores e identidade visual.

Esse ponto é importante porque a estética não era apenas decoração. Ela dizia que havia alguém do outro lado. Um sysop. Um grupo. Uma comunidade. Um estilo.

Hoje, quando se fala em recriar algo tipo BBS na web, a tentação é cair na caricatura: caveiras, “ACCESS GRANTED”, verde fluorescente, hacker cosplay. Isso cansa rápido.

O caminho mais interessante é outro: usar ASCII/ANSI como linguagem visual, mas com moderação. Terminal bom precisa ser legível. Se tudo pisca, nada importa.

Para renderizar ANSI hoje no navegador, há ferramentas específicas. xterm.js permite criar terminais completos dentro do browser, funcionando como um front-end de terminal. É ideal para uma experiência interativa: comandos, menus, sessões, WebSocket e respostas em tempo real. Já AnsiLove.js é mais apropriado para renderizar arte ANSI histórica com fidelidade, incluindo formatos de textmode/artscene e detalhes como CP437 e SAUCE.

Em outras palavras:

xterm.js     -> terminal vivo e interativo
AnsiLove.js  -> galeria ANSI fiel
Markdown     -> conteúdo preservável
WebSocket    -> sessão viva no navegador

Essa combinação é muito forte para um site-BBS moderno.

Diskmags, zines executáveis e a revista como software

Outra parte da conversa foi sobre zines em formato executável: as diskmags ou e-zines executáveis.

Hoje isso parece estranho. Por que alguém distribuiria uma revista como .EXE?

A resposta é simples: porque o executável não era só embalagem. Era experiência.

Uma diskmag podia ter menu próprio, música, arte, transições, créditos, artigos, entrevistas, textos técnicos, humor interno, telas secretas e uma identidade visual que nenhum .TXT conseguiria entregar sozinho. A revista virava software. O leitor não abria um documento; ele entrava em um ambiente.

Isso tinha ligação com BBS, demoscene, grupos de crackers, cultura hacker, revistas independentes, computadores domésticos e a lógica de distribuição offline. Você baixava uma vez, guardava, rodava e explorava.

No DOS, isso podia ser feito em Turbo Pascal, C, Assembly, QuickBasic. No Amiga, em Assembly 68000, C, AMOS, Blitz Basic. No Windows, vieram ferramentas como Visual Basic, Delphi, C/C++ e depois outras tecnologias.

Hoje uma diskmag moderna para Windows poderia ser feita em C# com WPF/Avalonia, Godot, Tauri, Electron ou C++ com SDL/raylib. Mas a pergunta real não é a stack. É se existe motivo para ser executável.

Se for apenas um PDF escondido dentro de um .EXE, é pior que PDF.

Mas se o executável entrega um ritual — música, interface, leitura paginada, arte, créditos, navegação e uma edição fechada — aí faz sentido.

A diskmag boa é revista, software e objeto.

O site-BBS moderno

A parte mais interessante da conversa foi imaginar um site próprio com alma de BBS.

Não uma BBS pronta instalada e customizada por cima.

Não um site comum com fonte monoespaçada fingindo ser terminal.

Mas um arquivo editorial em modo texto, acessível por múltiplas entradas:

Web para alcance
SSH para experiência terminal segura
Telnet para ritual retrô
Markdown para preservação
ANSI para alma
SQLite para memória dinâmica

A arquitetura mais elegante seria simples:

Navegador
  ↓
xterm.js
  ↓
WebSocket
  ↓
motor do terminal
  ↓
Markdown / ANSI / SQLite

E, para usuários técnicos:

ssh guest@terminal.seudominio.com -p 2222

Para os nostálgicos:

telnet terminal.seudominio.com 2323

A ideia central: o terminal não deve ser um brinquedo técnico. Ele deve ser uma forma alternativa de leitura e exploração.

Um visitante entraria e veria algo como:

╔════════════════════════════════════════════════════╗
║                  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:~$

O sistema aceitaria tanto menus quanto comandos:

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

Isso é importante. Menu puro fica bobo. Comando puro assusta. O híbrido é o caminho.

O conteúdo deveria viver em Markdown, versionado em Git. O banco guardaria apenas o que muda: guestbook, sessões, logs, mensagens aprovadas. O terminal renderizaria o conteúdo em páginas legíveis. O site normal ofereceria versão HTML/PDF/EPUB para alcance e preservação.

A regra de ouro seria:

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

A tentação do Assembly

Em algum momento surgiu a pergunta: “e um site em Assembly?”

Sim, é possível. Dá para escrever um servidor HTTP em Assembly. Dá para criar um CGI em Assembly que imprime HTML. Dá para usar WebAssembly no navegador.

Mas isso precisa ser colocado no lugar certo.

Assembly como fundação inteira do projeto seria uma prisão técnica. Você passaria tempo demais lidando com socket, buffer, HTTP, encoding, segurança, TLS, parsing, logs e arquivos — e tempo de menos criando o que realmente importa: conteúdo, experiência, estética, arquivo, leitura.

Mas Assembly como sala secreta? Perfeito.

Um endpoint como:

/asm-node

servido por um binário Assembly que responde uma página textual seria um ótimo easter egg técnico:

MURAD ASM NODE
x86_64 / Linux / raw syscalls

Este fragmento foi servido por um binário escrito em Assembly.

Isso é elegante porque não tenta transformar sofrimento técnico em arquitetura principal. Usa a técnica como ritual.

O que tudo isso tem em comum

Internet doméstica, BBS, Telnet, ANSI, diskmags, CDs de revista, downloads impossíveis, patches esperando a próxima edição, Slackware atualizado por mídia física, enciclopédias infantis em CD-ROM, zines executáveis, terminais no navegador, BBS via SSH, WebAssembly, Assembly como easter egg — tudo isso parece uma coleção de assuntos soltos.

Mas não é.

O fio é outro: a internet como lugar.

A web moderna é extremamente eficiente, mas também ficou lisa demais. Ela remove atrito, remove espera, remove borda, remove ruído, remove ritual. Tudo vira feed, card, botão, notificação, recomendação, métrica. A experiência fica polida, mas também descartável.

BBS, Telnet, diskmags e terminais tinham limitações brutais. Eram lentos, feios em alguns aspectos, caros, pouco acessíveis e tecnicamente frágeis. Não faz sentido romantizar tudo. Muita coisa era ruim mesmo.

Mas havia presença.

Você sentia que estava entrando em um sistema feito por alguém. Uma tela tinha estilo. Um menu tinha voz. Um arquivo tinha história. Um guestbook era uma marca humana. Um download exigia escolha. Um zine executável parecia um objeto encontrado. Um CD de revista era uma cápsula.

Talvez o que valha recuperar hoje não seja a limitação técnica em si.

Ninguém precisa voltar a 2400 bps.

O que vale recuperar é o senso de lugar.

Um manifesto discreto

Um site-BBS moderno não precisa competir com a web atual. Ele perderia.

Ele não será mais rápido que uma SPA otimizada. Não será mais prático que um CMS. Não será mais indexável que HTML limpo. Não será mais seguro que um sistema convencional se for malfeito. Não será mais popular que uma rede social.

E tudo bem.

A força dele está em outra coisa.

Um terminal-site pode desacelerar a leitura. Pode transformar navegação em exploração. Pode fazer um arquivo parecer habitado. Pode dar peso a um texto. Pode criar uma relação mais íntima entre pessoa, máquina e conteúdo.

A nostalgia, sozinha, é fraca.

Mas nostalgia combinada com direção editorial, tecnologia simples, preservação e bom gosto pode virar uma linguagem.

Não é sobre fingir que ainda estamos em 1995.

É sobre lembrar que a internet já foi estranha, manual, comunitária e cheia de textura — e usar essa memória para construir algo novo.

Não uma cópia do passado.

Um nó novo, com ecos antigos.

Linha do tempo resumida

1978
  CBBS, uma das primeiras BBS públicas por discagem, entra no ar em Chicago.

Anos 1980
  BBS se espalham entre entusiastas, sysops, grupos locais e comunidades técnicas.

Início dos anos 1990
  BBS vivem um período forte; no Brasil, tornam-se porta de entrada para muita gente antes da internet comercial.

1993/1994
  A internet residencial/comercial começa a se popularizar mais claramente nos Estados Unidos.

1995
  Marco da internet comercial no Brasil; criação do CGI.br; abertura mais ampla ao público.

1995 em diante
  Web, provedores discados, e-mail, IRC, ICQ e portais começam a ocupar o espaço antes dominado por BBS.

Fim dos anos 1990
  Muitas BBS fecham, viram provedores, migram para Telnet ou sobrevivem como nicho.

Anos 2000
  Banda larga, web social e mensageiros consolidam outra internet.

Hoje
  BBS ainda existem como cultura retrô; Telnet sobrevive como nostalgia; SSH e web terminals permitem recriar a experiência com mais segurança; ANSI e diskmags voltam como linguagem estética e arquivo cultural.

Fontes e leituras úteis

Did this resonate?

Related documents