← back to the garden

MD

Cardputer Adv Smallweb Gemini Gopher

Montar um webserver smallweb Gemini/Gopher em um M5Stack Cardputer Adv

Data da pesquisa: 2026-07-02
Foco: viabilidade real de hospedar conteúdo smallweb / low-tech no M5Stack Cardputer Adv, usando Gopher, Gemini e, secundariamente, HTTP mínimo.

Resumo direto

Dá para fazer, mas depende do que você chama de “webserver”.

Gopher no Cardputer Adv: relativamente fácil.
Gemini no Cardputer Adv: possível, mas significativamente mais trabalhoso.
Servidor público 24/7 direto no Cardputer: má ideia, salvo como experimento artístico/nerd.
Servidor local, portátil, de demonstração ou “capsule/zine de bolso”: excelente ideia.
Servidor público sério: melhor usar o Cardputer como terminal/editor/publicador e deixar o servidor real em VPS, Raspberry Pi, mini PC ou outro Linux leve.

Minha conclusão brutal: Gopher é o caminho certo para começar. Gemini é bonito, mas TLS em microcontrolador transforma um projeto poético em projeto de engenharia.

O que é exatamente o Cardputer Adv

O M5Stack Cardputer Adv não é um computador Linux de bolso. Ele é um dispositivo de desenvolvimento baseado em microcontrolador.

Segundo a documentação oficial da M5Stack, ele usa:

  • SoC: ESP32-S3FN8, dual-core Xtensa LX7, até 240 MHz.
  • Flash: 8 MB.
  • Tela: ST7789V2 de 1,14”, 240 × 135 px.
  • Teclado: 56 teclas.
  • Armazenamento externo: slot microSD.
  • Bateria: 1750 mAh.
  • Plataformas de desenvolvimento: Arduino, UiFlow2 e ESP-IDF.
  • Extras: microfone MEMS, codec ES8311, speaker, IMU BMI270, IR, Grove e barramento de expansão.

Fontes:

Implicação prática

Ele não roda Linux, não roda Docker, não roda systemd, não instala Agate/Gophernicus diretamente e não é um servidor Unix normal.

Ele roda firmware. Você escreve um programa em C/C++ com ESP-IDF ou Arduino, grava no dispositivo, e esse programa vira o servidor.

Isso muda tudo.

Protocolos analisados

1. Gopher

Gopher é o mais compatível com a ideia.

O protocolo é extremamente simples:

  1. O cliente abre uma conexão TCP, normalmente na porta 70.
  2. Envia uma linha de texto chamada selector.
  3. O servidor responde com texto, menu ou arquivo.
  4. O servidor fecha a conexão.
  5. Não há estado permanente.
  6. Não há TLS obrigatório.

A RFC 1436 descreve Gopher como um modelo cliente-servidor sobre TCP, usando porta 70, com o cliente enviando um selector e o servidor respondendo e encerrando a conexão.

Fonte:

Por que Gopher combina com ESP32/Cardputer

Porque ele exige pouco:

  • um socket TCP;
  • leitura de uma linha;
  • seleção de conteúdo;
  • envio de texto;
  • fechamento da conexão.

Isso é perfeitamente dentro do que um ESP32-S3 consegue fazer.

Há até uma biblioteca Arduino antiga para Gopher client/server em ESP8266/ESP8285/ESP32, embora ela pareça abandonada e sem releases publicados.

Fonte:

Dificuldade real do Gopher no Cardputer Adv

Nota: 3/10 se for local e estático.
Nota: 5/10 se for público e mais robusto.

Um servidor Gopher mínimo pode ser feito com:

  • Wi-Fi conectado;
  • TCP server escutando em uma porta;
  • conteúdo em strings no firmware ou arquivos .gophermap no microSD;
  • uma função que traduz selectors para arquivos.

O ESP-IDF já tem exemplo oficial de TCP server para ESP32, criando socket, aceitando conexão, recebendo dados e respondendo.

Fonte:

Exemplo de arquitetura Gopher

Cliente Gopher
    ↓ TCP :70 ou :7070
Cardputer Adv / ESP32-S3
    ↓
Firmware Gopher Server
    ↓
/microSD/gophermap
/microSD/posts/001.txt
/microSD/about.txt

Conteúdo ideal para Gopher

  • diário técnico;
  • manifesto smallweb;
  • lista de links;
  • status do dispositivo;
  • textos curtos;
  • zines;
  • logs;
  • “guestbook” simples;
  • sensor readings;
  • mini pubnix experimental;
  • página “estou online neste Cardputer”.

2. Gemini

Gemini é mais moderno que Gopher, mas bem menos simples para microcontrolador.

Gemini usa:

  • porta padrão 1965;
  • protocolo request-response;
  • formato de texto próprio, gemtext;
  • TLS obrigatório.

A documentação do projeto Gemini apresenta a especificação, o formato gemtext e guias de TLS/certificados. Outras referências também descrevem Gemini como inspirado em Gopher, mas com modernização via TLS obrigatório.

Fontes:

O problema do Gemini no Cardputer

Gemini não é difícil por causa do texto. Gemtext é simples. O problema é TLS.

O servidor Gemini precisa aceitar uma conexão TLS e só depois ler a URL solicitada pelo cliente. Em servidor Linux isso é trivial com Agate, Molly Brown, Jetforce etc. No ESP32, você precisa trabalhar com mbedTLS/ESP-TLS ou alguma camada SSL disponível.

A Espressif fornece componente oficial de HTTPS server e exemplos de SSL server/WebSocket seguro; a documentação mostra suporte a certificados e seleção de certificado no ESP HTTPS Server. Isso prova que TLS server no ESP32 é tecnicamente suportado, mas o componente oficial é voltado a HTTPS, não Gemini puro.

Fontes:

Gemini não é HTTPS

Isso é importante.

Gemini usa TLS, mas não é HTTP dentro de TLS. Portanto, não basta pegar um servidor HTTPS pronto e servir uma página. Você precisa de algo mais próximo de:

TCP accept
    ↓
TLS handshake
    ↓
ler linha: gemini://host/path\r\n
    ↓
responder: 20 text/gemini\r\n
    ↓
enviar conteúdo gemtext
    ↓
fechar conexão

Ou seja: a parte de rede é parecida com um servidor TLS genérico, não com um servidor web HTTP tradicional.

Dificuldade real do Gemini no Cardputer Adv

Nota: 6/10 a 7/10 para um protótipo local.
Nota: 8/10 para algo público e confiável.

Você provavelmente vai precisar de:

  • ESP-IDF em vez de Arduino puro;
  • mbedTLS/ESP-TLS;
  • certificado autoassinado embutido no firmware ou lido do microSD;
  • parser mínimo de URL Gemini;
  • resposta com códigos Gemini;
  • limitação explícita de concorrência;
  • logs via serial/tela;
  • tratamento de falhas de handshake;
  • watchdog/restart.

O que dá para fazer em Gemini

Dá para fazer:

  • uma capsule estática;
  • uma página /status.gmi gerada pelo firmware;
  • uma página /now.gmi com uptime, IP, bateria, Wi-Fi RSSI;
  • arquivos .gmi no microSD;
  • um mini diário escrito no próprio Cardputer;
  • um “capsule server portátil”.

Não recomendo tentar:

  • múltiplos usuários simultâneos;
  • CGI pesado;
  • upload público;
  • autenticação complexa;
  • conteúdo grande;
  • indexação dinâmica complexa;
  • ficar exposto cru na internet sem proxy/firewall.

3. HTTP smallweb simples

Tecnicamente, HTTP é o mais fácil no ESP32 porque o ecossistema já é maduro. Há servidores HTTP/HTTPS para ESP32, exemplos oficiais, bibliotecas Arduino e muito material.

Mas, filosoficamente, se a ideia é smallweb/Gopher/Gemini, HTTP no Cardputer seria mais um painel local ou fallback do que o projeto principal.

Dificuldade real de HTTP

Nota: 2/10 local.
Nota: 4/10 público básico.

HTTP simples no ESP32 é bem comum. HTTPS já volta a ter o problema de TLS, mas há mais exemplos prontos do que no caso de Gemini.

Fonte:

Comparação honesta

Opção Viabilidade no Cardputer Adv Dificuldade Comentário
Gopher local estático Excelente Baixa Melhor ponto de partida.
Gopher público Boa, mas exige rede/proxy Média O protocolo é fácil; expor é o problema.
Gemini local estático Possível Média/alta TLS complica, mas é viável.
Gemini público Possível, mas chato Alta Exige robustez, proxy, certificados e watchdog.
HTTP local Muito fácil Baixa Menos “smallweb raiz”, mas prático.
HTTP público Possível Média Mais material pronto, mas foge da graça Gopher/Gemini.
Rodar Agate/Gophernicus no Cardputer Não Impossível/praticamente não São servidores para sistemas POSIX/Linux, não firmware ESP32.
Cardputer como editor/publicador para VPS Excelente Baixa/média Melhor arquitetura prática.

Servidores tradicionais: por que não rodam diretamente no Cardputer

Servidores Gemini/Gopher populares normalmente esperam um sistema operacional POSIX/Linux.

Agate

Agate é um servidor Gemini em Rust para servir arquivos estáticos. O projeto diz que ele tem poucos recursos, serve somente arquivos estáticos e usa I/O assíncrono, sendo eficiente até em hardware baixo.

Fonte:

Mas “hardware baixo” aqui significa baixo para Linux/Unix, não um ESP32 sem sistema operacional Linux.

Gophernicus

Gophernicus é um daemon Gopher moderno, full-featured, voltado a sistemas POSIX, rodando sob inetd/xinetd/systemd e compilável com gcc em sistemas POSIX.

Fonte:

De novo: ótimo para VPS, Raspberry Pi, Debian, OpenBSD, pubnix. Não é algo para instalar diretamente no Cardputer.

O maior obstáculo não é o protocolo. É expor na internet.

Dentro da sua rede local, é simples:

Cliente → 192.168.x.x:7070 → Cardputer

Na internet pública, aparecem problemas:

  • NAT do roteador;
  • IP dinâmico;
  • portas bloqueadas por operadora;
  • Wi-Fi caindo;
  • bateria;
  • watchdog;
  • segurança;
  • ausência de firewall decente no dispositivo;
  • dificuldade de rodar túneis TCP diretamente no ESP32;
  • necessidade de DNS apontando corretamente;
  • limitação de conexões simultâneas.

Para HTTP, ferramentas tipo reverse proxy são comuns. Para Gopher/Gemini, você precisa de proxy TCP bruto ou encaminhamento de porta.

Arquiteturas possíveis

Arquitetura A — Local apenas

Notebook / celular na mesma rede
    ↓
Cardputer Adv:7070 Gopher

Dificuldade: baixa.
Recomendado para: brincar, testar, demonstrar, usar em eventos, arte low-tech.

Arquitetura B — Cardputer atrás de roteador com port forwarding

Internet
    ↓ porta 70/1965
Roteador
    ↓ port forward
Cardputer Adv

Dificuldade: média/alta.
Problema: IP dinâmico, portas bloqueadas, segurança fraca, Wi-Fi instável.

Arquitetura C — VPS como relay TCP

Internet
    ↓
VPS pública
    ↓ túnel/reverse TCP
Rede local
    ↓
Cardputer Adv

Dificuldade: média/alta.
Recomendado se: você faz questão de o conteúdo “sair” do Cardputer, mas quer DNS público estável.

O detalhe chato: normalmente o cliente do túnel roda em Linux. Então não é o Cardputer que vai rodar frpc/cloudflared/tailscale; seria outro host na mesma rede.

Arquitetura D — Cardputer como editor, VPS como servidor real

Cardputer Adv
    ↓ escreve .gmi/.gophermap
VPS / Raspberry Pi / mini PC
    ↓ Agate ou Gophernicus
Internet

Dificuldade: baixa/média.
Recomendação: melhor opção prática.

Aqui o Cardputer vira uma máquina smallweb portátil: você escreve no teclado dele, salva no microSD, sincroniza para a VPS, e a VPS serve com Agate/Gophernicus.

Essa arquitetura mantém o charme sem lutar contra as limitações erradas.

Stack recomendada por cenário

Cenário 1 — Quero fazer o projeto funcionar rápido

Use Gopher local.

Stack:

  • Arduino IDE ou PlatformIO;
  • WiFi.h;
  • WiFiServer;
  • microSD;
  • servidor TCP na porta 7070 ou 70;
  • conteúdo .txt e gophermap.

Por que porta 7070?

Porque em muitos ambientes porta 70 pode exigir permissões especiais no host cliente/proxy, pode ser bloqueada ou simplesmente ser mais chata para testes. Em microcontrolador não há a mesma restrição de portas privilegiadas que em Linux, mas para desenvolvimento 7070 evita conflito e facilita teste.

Depois você mapeia publicamente se quiser.

Cenário 2 — Quero Gemini porque é mais elegante

Use ESP-IDF, não comece por Arduino.

Stack:

  • ESP-IDF;
  • sockets TCP;
  • mbedTLS/ESP-TLS;
  • certificado autoassinado;
  • parser Gemini mínimo;
  • conteúdo .gmi no microSD;
  • log serial;
  • limite de 1 conexão por vez inicialmente.

Comece sem microSD, servindo uma string fixa:

# Cardputer Capsule

Hello from an ESP32-S3.

=> /status Status

Depois adicione microSD.

Cenário 3 — Quero algo público e usável

Não sirva direto do Cardputer.

Use:

  • VPS Debian;
  • Agate para Gemini;
  • Gophernicus para Gopher;
  • Cardputer como editor ou publicador;
  • rsync/git/API simples para publicar.

Essa é a escolha racional.

Roadmap recomendado

Fase 1 — Gopher local mínimo

Objetivo: provar que o Cardputer consegue servir conteúdo.

Funcionalidades:

  • conectar no Wi-Fi;
  • mostrar IP na tela;
  • escutar na porta 7070;
  • responder selector vazio com menu;
  • servir /about.txt;
  • servir /status.txt dinâmico.

Teste:

nc IP_DO_CARDPUTER 7070

Envie uma linha vazia ou um selector.

Fase 2 — Conteúdo no microSD

Objetivo: transformar em zine/servidor editável.

Estrutura:

/sd/gopher/gophermap
/sd/gopher/about.txt
/sd/gopher/posts/001.txt
/sd/gopher/posts/002.txt

Fase 3 — Interface no Cardputer

Objetivo: administrar pelo próprio teclado.

Funções:

  • tela inicial com IP, SSID, uptime;
  • editor simples de texto;
  • botão para reiniciar servidor;
  • lista de arquivos do SD;
  • contador de acessos;
  • modo “read only” para segurança.

Fase 4 — Gemini experimental

Objetivo: provar TLS + gemtext.

Funcionalidades:

  • TLS handshake;
  • certificado autoassinado;
  • servir / e /status.gmi;
  • uma conexão por vez;
  • conteúdo em string fixa.

Só depois coloque microSD.

Fase 5 — Publicação híbrida

Objetivo: tornar útil.

Opção racional:

  • Cardputer gera conteúdo;
  • envia para VPS;
  • VPS serve Gemini/Gopher publicamente.

Riscos técnicos

1. Memória

TLS consome memória. O ESP32-S3 aguenta TLS, mas isso não significa que ele aguente várias conexões simultâneas, certificados grandes, buffers grandes e leitura de arquivos grandes do microSD ao mesmo tempo.

A própria FAQ da Espressif fala de otimizações de memória para mbedTLS, como buffers dinâmicos e liberação de certificados/chaves após uso.

Fonte:

2. Concorrência

Comece com uma conexão por vez.

A ambição errada aqui é querer fazer “servidor de verdade”. O Cardputer deve ser tratado como servidor poético/experimental, não como infraestrutura.

3. Energia

A bateria de 1750 mAh é boa para uso portátil, não para uptime sério. Wi-Fi + servidor + tela ligada drenam bateria. Para 24/7, use USB ligado e aceite que o dispositivo não foi feito para ser datacenter de bolso.

4. microSD

microSD é perfeito para conteúdo estático, mas não abuse de escrita constante. Para logs e contador de acesso, grave pouco ou use cache em RAM e flush eventual.

5. Segurança

Gopher não tem TLS. Gemini tem TLS, mas isso não resolve todos os problemas:

  • firmware pode travar;
  • parser malfeito pode quebrar;
  • não há isolamento de processo;
  • não há usuário sem privilégios;
  • não há sistema de permissões real como em Linux;
  • qualquer bug é bug no firmware inteiro.

Não exponha uma interface de escrita pública no Cardputer sem autenticação forte e sem proxy externo.

Minha recomendação final

Melhor projeto para começar

Faça um servidor Gopher no Cardputer Adv.

Nome de projeto sugerido:

  • PocketGopher
  • CardGopher
  • TinyBurrow
  • Gopherputer
  • Pocket Hole
  • Cardputer Burrow

O firmware ideal:

  • mostra IP na tela;
  • serve Gopher na porta 7070;
  • lê conteúdo do microSD;
  • tem /status dinâmico;
  • permite editar textos no próprio Cardputer;
  • exporta/sincroniza para uma VPS quando conectado.

Melhor projeto “bonito”

Faça uma Gemini capsule experimental no Cardputer, mas só depois do Gopher.

Nome de projeto sugerido:

  • Pocket Capsule
  • Card Capsule
  • Gemini Deck
  • Tiny Capsule
  • Capsuleputer

Melhor projeto público e útil

Use o Cardputer como terminal/editor e publique em uma VPS com Agate/Gophernicus.

Essa arquitetura é a menos idiota e a mais durável.

Você ganha:

  • charme do Cardputer;
  • estabilidade da VPS;
  • DNS público real;
  • TLS melhor;
  • logs melhores;
  • systemd;
  • backups;
  • menos sofrimento.

Veredito final

É fácil montar um servidor smallweb/Gopher no Cardputer Adv?
Sim, se for Gopher estático/local. É um projeto muito viável.

É fácil montar Gemini?
Não exatamente. É possível, mas TLS torna o projeto bem mais trabalhoso.

É uma boa ideia hospedar publicamente direto nele?
Como experimento: sim. Como infraestrutura: não.

O melhor caminho?
Comece por Gopher. Depois faça Gemini. Para uso público sério, publique em uma VPS e use o Cardputer como ferramenta de criação/publicação.

A frase curta é:

O Cardputer Adv é perfeito para um “servidor smallweb de bolso”, mas não para fingir que é um mini servidor Linux. Use as limitações como estética, não como obstáculo.

Fontes principais

  1. M5Stack Docs — Cardputer Adv
    https://docs.m5stack.com/en/core/Cardputer-Adv

  2. M5Stack Store — Cardputer Adv
    https://shop.m5stack.com/products/m5stack-cardputer-adv-version-esp32-s3

  3. RFC 1436 — The Internet Gopher Protocol
    https://datatracker.ietf.org/doc/html/rfc1436

  4. ncmreynolds/gopher — Arduino Gopher library for ESP8266/ESP32
    https://github.com/ncmreynolds/gopher

  5. ESP-IDF TCP Server Example
    https://github.com/espressif/esp-idf/blob/master/examples/protocols/sockets/tcp_server/README.md

  6. ESP-IDF HTTPS Server documentation
    https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/esp_https_server.html

  7. ESP-IDF HTTPS Server Simple Example
    https://github.com/espressif/esp-idf/tree/master/examples/protocols/https_server/simple

  8. Espressif ESP-FAQ — mbedTLS memory optimization
    https://docs.espressif.com/projects/esp-faq/en/latest/software-framework/protocols/mbedtls.html

  9. Gemini protocol documentation
    https://gemini.flounder.online/docs/

  10. Agate Gemini Server
    https://github.com/mbrubeck/agate

  11. Gophernicus
    https://www.gophernicus.org/