Moon Flower Society > Análise de Compatibilidade — Ecossistema m15o × runv.club
Quais dos 38 projetos m15o podem incrementar o runv.club, quais não, e por quê.
Posted July 2, 2026. Markdown. Tags: m15o, runv, pubnix, smallweb, gemini, gopher, nex.
Ecossistema m15o (small web) × runv.club (pubnix)
Quais dos 38 projetos m15o podem incrementar o runv, quais não, e por quê. Base: os resumos em m15o/docs/, os manifests de dependências (go.mod / PHP) e a arquitetura conhecida do runv-server.
Data: 2026-07-02 · Escopo: 38 repositórios em m15o/ · Autor upstream: m15o (git.sr.ht / hg.sr.ht)
runv.club é um pubnix Debian — um servidor Unix compartilhado acessado por SSH (headless, sem ambiente gráfico). Serve conteúdo em três protocolos por usuário: HTTP (Apache mod_userdir), Gopher e Gemini (public_html / public_gopher / public_gemini), além de IRC (#runv). O código é Python stdlib puro, o estado vive em arquivos JSON (não há banco SQL), e a experiência é a de uma comunidade tilde: comandos de terminal (runv-who, runv-finger, runv-bulletin, chat), geração estática e site bilíngue.
m15o é o ecossistema da “small web”: 38 repositórios em torno de Gemini, Gopher e Nex, formatos de publicação em HTML puro (HTML Blog / HTML Journal), wikis estáticas, serviços de comunidade auto-hospedáveis e alguns experimentos de linguagens/editores.
Alinhamento filosófico: praticamente perfeito. O m15o é, em grande parte, exatamente o “software de comunidade” que falta ao runv. Vários projetos são multi-protocolo (HTTP+Gemini+Gopher), que é justamente o modelo do runv. A compatibilidade, portanto, quase nunca é uma questão de propósito — é uma questão de modelo de execução e footprint de infraestrutura.
Cada projeto foi avaliado por cinco eixos:
Modelo de execução. Serviço headless (roda em servidor via terminal/daemon) ou app gráfico (precisa de X11/display)? Um pubnix é acessado por SSH e não tem display gráfico; o sshd do runv inclusive desativa X11 forwarding. Apps SDL2/Lazarus não rodam como serviço.
Runtime e footprint. Go compila para um binário estático (fácil de instalar + systemd). PHP exige PHP-FPM; Node exige o runtime Node; C precisa de toolchain de build.
Banco de dados. O runv hoje não usa SQL — estado em JSON. Todos os serviços Go de comunidade usam PostgreSQL (github.com/lib/pq) e os PHP usam MySQL. Adotá-los introduz um servidor de banco — o principal custo operacional e a maior quebra de invariante.
Multiusuário vs pessoal. Serve toda a comunidade, é por-usuário, ou é config pessoal do autor?
Redundância. O runv já faz homepages, quota, diretório de membros, Gemini, Gopher e wiki estática. Projetos que refazem o núcleo do runv com outra stack tendem a conflitar em vez de incrementar.
Legenda dos tiers: A Incorporar já (baixo custo, encaixe perfeito) · B Incorporar com infra extra (BD / LAMP / Node) · C Não incorporar (incompatível ou redundante)
| Projeto | O que é | Stack | Veredito |
|---|---|---|---|
| nex-pfm | Lib do protocolo Nex | Go | A — base do Nex |
| nexd | Daemon Nex (porta 1900) | Go | A — 4º protocolo |
| kinex | Gateway HTTP -> Nex | Go | A — Nex na web |
| rex | Cliente Nex de terminal | ksh (1 linha) | A — vira comando |
| the-neon-kiosk | Agregador de blogs/journals | Go (htmlb/htmlj) | A — descoberta |
| ni | Wiki estática (gemtext) | Go | A — por usuário |
| nini | Wiki estática (HTML) | Go | A — por usuário |
| moka | Wiki client-side (1 HTML) | HTML/JS | A — no skel |
| yon | Wiki/notas client-side | HTML/JS | A — no skel |
| emacs.d | Config Emacs p/ small web | Emacs Lisp | A — config opcional |
| gmi2html | Lib gemtext -> HTML | Go | A — bloco reutilizável |
| htmlb | Parser de HTML Blog | Go | A — dep do kiosk |
| htmlj | Parser de HTML Journal | Go | A — dep do kiosk |
| midnight-pub | Pub social multi-protocolo | Go + PostgreSQL | B — flagship (BD) |
| smol.pub | Journal multi-protocolo | Go + PostgreSQL | B — BD + autocert |
| status | Microblog de status | Go + PostgreSQL | B — BD |
| vpub | Fórum hierárquico | Go + PostgreSQL | B — BD (admin/admin!) |
| owl-report | Leitor de feeds RSS/Atom | Go + PostgreSQL | B — BD |
| riku | Backend de formulários | Go + PostgreSQL | B — BD |
| feed | Parser RSS/Atom | Go | B — dep do owl-report |
| opml | Parser de OPML | Go | B — dep do owl-report |
| html-blog | Validador de HTML Blog | Go | B — nicho |
| html-journal | Validador de HTML Journal | Go | B — nicho |
| lipu.li | Wiki multiusuário | PHP + MySQL | B — LAMP |
| mebo | Fórum | PHP + MySQL | B — LAMP (dup. vpub) |
| piclog | Fotolog JPEG | PHP + MySQL | B — LAMP |
| warp | Cliente Nex no browser | PHP | B — precisa PHP |
| nexy | Proxy Nex -> Gemini | Node.js | B — runtime Node |
| nspace | Ling. de máq. de registradores | C (terminal) | C — curio de terminal |
| 15f | Ling. Forth + gráficos | C + SDL2 | C — gráfico (headless) |
| bitters | Editor gráfico | C + SDL2 | C — gráfico |
| grid | Editor gráfico (ACME) | C + SDL2 | C — gráfico |
| tny | VM de 256 bytes gráfica | C + SDL2 | C — gráfico |
| nova | Cliente Nex GUI | Pascal/Lazarus | C — desktop GUI |
| dotfiles | Config FVWM/X11 pessoal | ksh/X11 | C — desktop |
| ichi | Plataforma de homepages | Go + PostgreSQL + SFTP | C — duplica o runv |
| nightfall-server | Servidor Gemini+HTTP | Go + autocert | C — redundante |
| ichipedia | Enciclopédia estática | gemtext/HTML | C — conteúdo |
Contagem: Tier A = 13 · Tier B = 15 · Tier C = 10.
Encaixam no runv com pouco ou nenhum atrito: são binários Go únicos, arquivos estáticos ou ferramentas de terminal. Nenhum exige banco de dados.
O runv já serve Gopher e Gemini por usuário. Adicionar Nex é o incremento mais natural e barato: espelha o padrão existente e é 100% alinhado com a Nightfall City do m15o.
nex-pfm (Go, lib): base que lista diretórios e serve arquivos Nex. Entra como dependência de nexd/kinex.
nexd (Go, daemon :1900): binário único que depende só de nex-pfm. Poderia servir um ~/public_nex por usuário, exatamente como public_gopher/public_gemini. Instalação: 1 binário + unit systemd.
kinex (Go): gateway HTTP->Nex, expõe Nex no navegador — como o runv já faz Gemini->web.
rex (ksh): cliente Nex de terminal. É literalmente echo $2 | nc $1 1900 | less. Vira um comando em tools/bin (como o chat), custo ~zero.
the-neon-kiosk (Go, usa htmlb/htmlj): agrega blogs/journals HTML recentes. Apontado para os public_html dos membros, vira uma página de descoberta da comunidade — casa direto com o members.json e a geração estática do runv. Sem BD.
ni (gemtext->HTML) e nini (HTML->HTML): geradores de wiki estática com backlinks. Ótimos como ferramenta por-usuário (gera para o public_html/public_gemini). Sem BD.
moka e yon: wikis client-side em um único arquivo HTML (localStorage). Custo zero — basta servir o arquivo ou oferecê-lo no skel do novo usuário.
emacs.d (Emacs Lisp): config com modos para HTML Blog, gemtext, journal e cliente Gopher (elpher). Emacs roda em terminal via SSH — perfeito para pubnix. Oferecer como config opcional/skel.
gmi2html / htmlb / htmlj (Go, libs): blocos de construção reutilizáveis (conversão e parsing). Entram junto dos serviços/geradores que os usam.
Alto valor de comunidade, mas cada um introduz um banco de dados ou runtime novo. Viável no Debian, porém quebra a invariante “estado em JSON, sem SQL” do runv. Recomendação: padronizar PostgreSQL (a maioria dos serviços Go usa lib/pq) e só entrar no mundo PHP/MySQL se realmente quiser os apps PHP.
midnight-pub — pub social multi-protocolo HTTP/Gemini/Gopher. É o candidato a flagship: o modelo multi-protocolo é idêntico ao do runv. Go + PostgreSQL + gmi2html.
smol.pub — journal Web/Gemini/Gopher. Excelente, mas sobrepõe parcialmente ao public_html/gemini/gopher que o membro já tem; e o autocert dele disputa a porta 443/TLS com o Apache/certbot atuais (usar subdomínio próprio).
status — microblog de status curtos (com badges PNG). Integra-se ao vpub. Go + PostgreSQL.
vpub — fórum hierárquico. Atenção: cria admin/admin na 1ª execução — trocar imediatamente.
owl-report — leitor de feeds self-hosted (usa as libs feed + opml). Go + PostgreSQL.
riku — backend de formulários HTML: complemento natural para os sites estáticos dos membros (formulário de contato sem serviço externo). Go + PostgreSQL.
feed / opml (Go, libs): entram só como dependências do owl-report.
html-blog / html-journal (Go): servidores que validam o formato e geram Atom. Nicho — o mais útil é adotar a convenção de formato nos public_html; rodar os validadores é opcional.
lipu.li — wiki multiusuário com backlinks (PHP + MySQL + PHPMailer).
mebo — fórum PHP. Redundante com o vpub — escolher um; não vale subir MySQL só por ele se já houver PostgreSQL.
piclog — fotolog JPEG com perfis e feed (PHP + MySQL).
warp — cliente Nex no browser (PHP, arquivo único). Leve, mas depende de PHP.
nexy — proxy Nex->Gemini (Node.js). Opcional; adiciona o runtime Node só para essa ponte.
Precisam de display gráfico. O runv é acessado por SSH sem X, e o sshd desativa X11 forwarding — logo não rodam como serviço. Fazem sentido na máquina do próprio membro, não no servidor compartilhado.
15f (C + SDL2) — linguagem Forth com gráficos.
bitters (C + SDL2) — editor gráfico estilo Canon Cat.
grid (C + SDL2) — editor gráfico estilo ACME.
tny (C + SDL2) — emulador gráfico de VM de 256 bytes.
nova (Pascal/Lazarus) — cliente Nex com GUI desktop. (Para Nex no servidor, use rex/kinex/warp.)
dotfiles (FVWM/X11) — config de window manager pessoal; nada a rodar num servidor headless (no máximo, aproveitar scripts shell soltos).
ichi (Go + PostgreSQL + SFTP): é, ele próprio, uma plataforma de pubnix — homepages por usuário, quota, índice, editor web. Adotá-lo inteiro seria manter dois pubnixes concorrentes. Serve de inspiração de features (editor web, índice), não de incremento drop-in.
nightfall-server (Go + autocert): servidor Gemini+HTTP. Redundante com a stack atual (Apache + Gemini + certbot); seria uma substituição, e o autocert conflita na 443. Não é incremento.
ichipedia: é conteúdo (enciclopédia gemtext do m15o), não software. Pode ser publicado como conteúdo, mas não “incrementa” o sistema.
Resposta honesta: a maioria sim, mas não todos — e o motivo é estrutural, não de vontade.
~28 projetos são compatíveis como serviço ou ferramenta de servidor (Tiers A e B): o alinhamento small-web é perfeito; o único preço é infraestrutura (banco/PHP/Node) nos de Tier B.
5 projetos gráficos (15f, bitters, grid, tny, nova) não podem rodar num pubnix headless — dependem de SDL2/Lazarus e de um display. Isso é uma barreira de modelo de execução, não de licença ou stack. O caminho para “torná-los compatíveis” é oferecê-los como código-fonte para o membro compilar na própria máquina, não como serviço no runv. (X11 forwarding via SSH seria teoricamente possível, mas o runv o desativa por segurança.)
dotfiles é config de desktop pessoal — não “roda” em lugar nenhum do servidor.
ichi e nightfall-server rodariam tecnicamente, mas duplicam/competem com o núcleo do runv — compatíveis no papel, indesejáveis na prática.
ichipedia é conteúdo, não um componente de sistema.
Conclusão: o ecossistema m15o é um encaixe raro para o runv. O trabalho real não é vencer incompatibilidade de propósito — é decidir quanto de infraestrutura nova (sobretudo um banco de dados) você aceita introduzir, e evitar duplicar o que o runv já faz.
Da menor para a maior fricção:
Banco de dados quebra a invariante do runv. Hoje todo o estado é JSON; qualquer serviço Tier B adiciona PostgreSQL/MySQL, com backup, migrações e hardening próprios.
Conflitos de porta/TLS. Serviços com go-gemini/go-gopher/autocert (midnight-pub, smol.pub, nightfall-server) disputam as portas 1965 (Gemini), 70 (Gopher) e 443 (TLS) com o molly-brown/gophernicus/Apache do runv. Rodar cada um atrás de subdomínio + porta própria ou reverse proxy.
Segurança padrão. vpub cria admin/admin; vários apps PHP usam ativação por e-mail (PHPMailer) — precisam de config SMTP alinhada com o e-mail transacional do runv.
Build e origem. Repos estão em Git e Mercurial; os serviços Go precisam do toolchain Go no servidor (ou build local + deploy do binário). Os PHP precisam de PHP-FPM.
Não duplicar o núcleo. ichi e nightfall-server refazem o que o runv já entrega; adotá-los cria manutenção redundante e confusão de modelo.
Consistência de comunidade. Ao adicionar serviços com login próprio (midnight-pub, vpub, status…), pensar em como se relacionam com a conta Unix do membro — SSO real dá trabalho; no mínimo, alinhar nomes de usuário.
Fim da análise.
View the original Markdown file
Ideas | What changed | RSS | About | Text version
Pablo Murad <pablomurad@pm.me>